OpenStack CI/CD Zuul 持續集成與交付 九州雲

編者按：據統計，在上周結束的OpenStack溫哥華峰會中，關於CI/CD持續集成和交付的議題超過40個，CI/CD成為了整場峰會最熱門的話題之一。而Zuul作為CI/CD模塊中耀眼的明星，被大家所熟知，在本次峰會上更是引起了業界高度關註。在這裏小編將簡單介紹下Zuul，包括Zuul 的CI簡單流程圖、組件及架構等。

什麽是Zuul

隨著OpenStack持續集成的推廣，基於OpenStack開源項目的性質，項目大，全球各地的開發人員多，變更提交頻繁。Jenkins不能解決並發多、單依賴的問題，拉長了問題反饋時間。為解決該問題，源於OpenStack開源社區的基於ZUUL框架的 CI方案出現在我們的視線中。

CI簡單流程圖

Zuul組件及工作流程

為了更好的理解什麽是Zuul和Zuul到底是怎麽工作的，需要介紹一下Zuul有哪些組件。

Zuul整體架構

Zuul-server

Zuul-server是Zuul的主要的服務，zuul-server是作為zuul的scheduler，zuul-server從gerrit接收消息，一旦消息被接收到，zuul-server就建立工作流程，並把處理結果返回給gerrit Zuul-server跟gerrit組件交流是通過執行“gerrit stream-events”，然後等待gerrit返回的信息，另外，zuul-server也與Gearman進行通訊。

Gearman

Jenkins的設計初衷並不用於並行執行，它設計中某些點使用到了全局鎖，因此在Jenkins的slave節點增加到一定數量後（大約100臺），Jenkins的master節點就會出現問題而成為瓶頸。同時master節點是單點部署，無法完成HA等處理。為了擴展Jenkins而引入了Gearman。

簡單來說，Gearman是一個用來擴展Jenkins的一種協議，而且Gearman一開始並不是專門為Zuul開發的，但是Gearman很好的符合了Zuul的需求，因此OpenStack采用Gearman來擴展Zuul對Jenkins的調度。 在配置的時候可以選擇單獨創建Gearman-server或者是使用Zuul來部署Gearman，具體在/etc/zuul/zuul.conf裏面進行配置：

1 [gearman_server]
2 listen_address = 127.0.0.1
3 log_config = /etc/zuul/gearman-logging.conf
4 start = true
5

把start改成true，zuul服務就會啟動並管理Gearman進程。

Zuul-merger

這裏不要被這個組件的名字所誤導了，這個組件並不是當代碼全部通過測試後用來merge到主幹的。當開發者提交一個change後，zuul-merger把這個change merge到一個本地forked repository中 ，這樣就可以進行下一步的測試了。

可以把zuul-merger單獨部署在一臺服務器上也可以進行高可用部署，即部署在多臺服務器上組成zuul-merger的集群。

在zuul的配置文件 /etc/zuul/zuul.conf下可以對zuul-merger進行配置，在 [merger] section下面：
1 [merger]
2 git_dir = /var/lib/zuul/git
3 log_config = /etc/zuul/merger-logging.conf
4 pidfile = /var/run/zuul-merger/zuul-merger.pid
5 zuul_url = 127.0.0.1
6

git_dir是zuul對Git repository的一個copy
Log_config是配置zuul-merger的log目錄
zuul_url是zuul server的url，這個url可能有多個（zuul集群的情況下）
Zuul-cloner
Zuul-cloner不像其他組件，它沒有Damon，只有一個client，用來創建job的workspace
Zuul Workflow
下圖解釋了當一個patch提交給gerrit的時候zuul的workflow是怎麽樣的：

Gerrit

用戶的patch是提交給Gerrit的，也可以是一個新的commit，一旦這個patch被提交上來，Gerrit就會publish一個event，通知其他服務來處理這個event，如Zuul、Jenkins等。

Zuul Server

Zuul-server根據zuul.conf的配置來啟動相應的關聯進程，Zuul server會先起一個進程叫GerritWatcher，用來listen從Gerrit那邊傳過來的event（步驟3），在註冊好所有的連接後，zuul-server會起一個Gearman，zuul-server同時會啟動Gearman和Scheduler。

當一個Gerrit的event被publish後，GerritWatcher就會通知scheduler，scheduler先會去檢查這個event是否合法（根據layout.yaml裏面定義的規則），如果通過，便會觸發一個trigger event（步驟4）。

Scheduler接著處理這個event，並把這個event添加到一個相關的pipeline裏面（步驟5，也是根據layout.yaml裏面定義的規則），接下去就是pipeline來處理這個event了，scheduler也會去檢查這個event是否依賴於其他的event。

Zuul Merger

當scheduler觸發完成trigger event後，把整個代碼克隆下來，並把更改的代碼並入主幹的工作是由zuul-merger來完成的。在步驟6中，merger會從gearman那邊獲得一個“merge job”的信息，裏面包括項目的名稱，分支信息，change number和ref等信息。第一步merger需要確認這個commit是不是重復的，如果是，那麽就返回已經發生的commit，如果不是，那麽繼續下一步工作。

HEAD ref重置完成後，如果ref指向了一個不可用的分支，那麽zuul就會自動選擇第一個可用的分支，然後merger會通過“git fetch”來update repo，再checkout。

接下來merger嘗試merge更改到repo上，如果merge成功，那麽就會在zuul-server中創建一個新的reference到repo中，最後，merger會返回一個動作完成的信息。
Gearman & Jenknis
現在repo已經準備完成，在上面merger的工作完成之後，現在需要測試這個代碼的更改。這步操作其實是scheduler來做的，但是需要配合Gearman來執行。Scheduler發送給Gearman，scheduler也會發送一些變量給Gearman，一般是 ‘ZUUL_’ 開頭的。

Gearman接著把數據發送給Jenkins，Jenkins可能是一個集群，Jenkins在測試完成後會把結果返回給zuul，zuul再去通知gerrit是否去merge這個更改。

是否必須使用Jenkins

OpenStack社區考慮過不再使用Jenkins，只使用Zuul來代替，但是如果你的CI系統跟Jenkins強綁定的話，系統中使用了很多Jenkins的plugin，那麽再去轉換到non-Jenkins的環境中會有比較大的困難。當然可以慢慢利用Zuul來替換Jenkins，但是如果一定要使用Jenkins的話，那麽就需要“Jenkins Gearman”這個plugin來提供支持。

Pipelines

Pipelines是Zuul重要的組成部分，每一個gerrit的change都會由一個或者多個Pipelines來進行處理。

Upsteam

非Openstack核心團隊的人員可以在評審代碼後作出+1（好）、0（無評價）、-1（不建議合並）的評價。核心團隊的成員可以給出非核心成員可給出的所有評價，此外還可以給出+2（好，approved）、-2評價（不要提交）。