帶你解讀蘇研openstack持續集成實踐

持續集成

持續集成(Continuous Integration，簡稱CI)是指軟體開發過程中個人研發的部分向軟體整體部分交付，頻繁進行集成以便更快地發現其中的錯誤。

持續集成核心價值

持續集成中的任何一個環節都是自動完成的，無需太多的人工干預，有利於減少重複過程以節省時間、費用和工作量。

蘇研Openstack持續集成背景簡介

在未搭建CI環境之前，openstack研發組代碼質量基本都由代碼評審人員review，但是人工review無法驗證最新的代碼是否能完成環境部署，涉及的功能點是否能測試通過，並且無法保證某個模塊的修改對其它模塊是否會產生影響。

因此我們決定引入openstack社區CI環境，但是社區的CI環境是根據source code通過devstack完成openstack單節點環境部署，不滿足蘇研的需求。經過和研發同事的討論決定模擬生產環境的部署方式，將source code打包成rpm包放入yum repo，通過蘇研自動化部署工具完成一套openstack集群環境部署。

蘇研Openstack持續集成流程

組件工作流程

Gerrit

Gerrit主要負責代碼的管理

Zuul

Zuul通過捕獲Gerrit事件，找到對應的pipeline進行後續處理，而pipeline中定義了需要執行哪些Jenkins任務，這些都是在Zuul的配置文件layout.yaml中定義的，如下為一個check pipeline的片段：

從中我們可以看到check這個pipeline由gerrit的patchset-created/change-restored或comment-added(如：recheck)觸發，成功後會返回verified：1消息給gerrit，失敗返回verified：-1。

以上是check pipeline of cinder project需要執行的任務。

引入Zuul而不是直接使用Gerrit觸發Jenkins的原因是：Jenkins job每次只能執行一個任務，如果一個測試需要執行1小時，每天只能執行24次測試，只能對24個修改做出驗證，通過引入Zuul使Jenkins並發測試成為可能。

Zuul同時還可以很好的處理具有複雜依賴關係的多個patch，它也能監控正在執行的任務。

Gearman

在原來的實現中，Zuul完成"事件-pipeline-任務"的匹配後，就可以調用Jenkins執行具體的任務開始實際的測試了。

Jenkins用的是master/slave架構，一台master管理所有slave節點，但是在Jenkins的slave節點增加到一定數量後(大約100台)，Jenkins的master節點就會出現問題而成為瓶頸。

同時master節點是單點部署，無法完成HA，為了擴展Jenkins而引入了Gearman。

加入Gearman後，Zuul不再與Jenkins直接交互，而是提交執行任務的請求給Gearman伺服器，由Gearman伺服器完成任務的分發(因為蘇研openstack項目每天代碼提交量不是很大，jenkins只部署了一台)。

測試節點通過註冊到Gearman伺服器，使得Gearman獲知其可用，並被分配任務。

Jenkins Master節點通過Gearman的插件連接到Gearman伺服器並獲得任務。

以下是通過gearman命令查詢jenkins job可以使用的slave節點

nodepool

可用於CI環境中虛擬機資源的彈性管理，可以提高測試環境中虛擬機的使用效率：需要測試的時候創建虛擬機，測試完成後刪除虛擬機，目前nodepool管理的虛擬機都是通過對接的openstack環境來維護。

蘇研CI測試運行方式

根據openstack研發組實際的情況，現在CI測試運行方式分為以下2種：

Check

Check用於驗證每個對Gerrit提交的patch，它是對提交的patch單獨進行測試。

例如：A修改了nova某一行代碼，部署環境時nova項目的rpm包來自於A的源碼打包，而其他項目的rpm包來自於CI自己維護的yum repo。

Post

對merge的代碼進行打包，併合入到CI自己維護的yum repo。

環境部署

對於單元測試可能不需要實際的Openstack環境去執行，而對於集成測試則需要一整套的Openstack組件。

對於這些測試Jenkins任務會根據蘇研的自動化部署工具搭建一套完整的Openstack集群環境：

3個控制節點，2個計算節點， nova/neutron/cinder/glance/rabbitmq/mysql等等服務都是採用高可用方案，neutron採用openvswitch+vxlan模式，glance和cinder對接的是預先安裝好的ceph集群。

部署所需的機器全部來自nodepool創建的虛擬機。

執行測試

1.Style測試

嚴格的pep8要求檢查

2.單元測試、代碼覆蓋率統計

3.功能測試

實際執行的測試用例也是在Jenkins的任務中定義，通過調用Tempest去實現。

Tempest是一整套Openstack集成測試框架，它的實現基於python的unittest2測試框架和nose測試框架，Tempest對Openstack終端發起一系列API請求，並且對終端的響應進行驗證。Tempest通過config文件來描述整個測試環境，包括compute API端點，Keystone server以及Glance server安裝的鏡像的UUID等信息。

測試的主要模塊有如下幾部分：

api主要測試OpenStack API部分的功能

scenario主要根據一些複雜場景進行測試

整個CI過程瀏覽

開發者提交了一個patch

Zuul狀態監控

CI執行過程中日誌

自動匹配jira工單

測試結果輸出

Gerrit上自動添加測試結果

Hygieia儀錶盤

通過Hygieia我們能實時看到jira工單的狀態，對應jenkins job每天執行情況，以及單元測試結果和代碼覆蓋率統計結果。

總結

搭建一套CI環境需要考慮的問題有很多，以下列舉了幾個重要的問題：

問題

1.CI整個過程中日誌收集，CI整個流程完成後資源回收

2.部署失敗或者測試失敗等等異常情況處理

3.搭建自己的pip源(蘇研openstack代碼基於kilo版本開發，因為該版本社區已經不維護了，導致CI過程中需要的某些python包官網已經沒有了)

4.維護自己的tempest項目(如：社區測試時虛擬機都是採用本地虛擬機，而蘇研現在大多採用卷虛擬機)

5.nodepool對接的openstack環境改造/性能調優/運維

END

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！