知乎容器化構建系統：從0到1支撐日近萬次構建部署

知乎應用平臺團隊基於Jenkins Pipeline和Docker打造了一套持續集成系統。Jenkins Master和Slave基於Docker部署，每次構建也是在容器中進行。目前有三千個Jenkins Job，支撐著整個團隊每日近萬次的構建和部署量。

整個系統的設計目標是具備以下的能力：

• 較低的應用接入成本，較高的定製能力：寫一個構建系統配置文件成本要儘可能簡單方便，或者可以通過模板一鍵創建，但又要能滿足應用的各種定製化的需求。

• 具備語言開放性和部署多樣性：平臺需要能支撐業務技術選型上的多語言，同時，要能滿足應用不同的部署類型，如單純的打包發佈，或者進一步部署到物理機、容器、離線任務平臺等。

• 構建快和穩定，復現問題成本低：每次構建都在乾淨的容器中，減少非應用本身問題帶來的構建異常。同時，如果構建出現問題，在權限控制的前提下，要能方便開發者自己調試和排查。

• 推動業界標準以及最佳實踐，同時在代碼合併之前就能更好把控住質量。

• 整個集群高可用，可擴展，以及具備較低的運維成本。

一、背景

知乎選用Jenkins作為構建方案，因其強大和靈活，且有非常豐富的插件可供使用和擴展。

早期，應用數量較少時，每個開發者都手動創建並維護著幾個Job，各自編寫Jenkins Job的配置，以及手動觸發構建。隨著服務化以及業務類型，開發者以及Jenkins Job數量的增加，我們面臨了以下的問題：

• 每個開發者都需要去理解Jenkins的基本配置和觸發邏輯，使得配置創建和維護成本高。

• 構建在物理機上進行，每個應用可能有著不同的版本依賴，構建時會遇到版本衝突，甚至上線之後發現行為不一致導致故障等。

• 構建一旦失敗，需要開發者能登錄Jenkins Slave所在的物理機進行調試，權限控制成為了一個問題。

於是，一個能方便應用接入構建部署的系統，成為了必須。

二、完整的生命週期

知乎的構建工作流主要是以下兩種場景：

• 只有Master分支的代碼可以用於線上部署，但支持指定任意的分支進行構建。

• 所有對Master分支的修改必須通過Merge Request來進行。為了避免潛在代碼衝突導致測試結果不準的情況，對Merge Request上的代碼進行構建前，會模擬跟Master分支的代碼做一次合併。

一個Commit從提交到最後部署，會經歷以下的環節：

• 開發者提交代碼到GitLab。

• GitLab通過Webhook通知到ZAE（Zhihu App Engine，知乎的私有云平臺）。

• ZAE將構建的上下文信息，如GitLab倉庫ID，ZAE應用信息給到構建系統Lavie。目前只處理用戶提交MR以及合併到Master分支的事件。

• 構建系統Lavie讀取應用倉庫中的配置文件後生成配置，觸發一個構建。在構建過程中獲取動態生成的Jenkinsfile，生成Dockerfile構建出應用的鏡像，並跑起容器，在容器中執行構建，測試等應用指定的步驟。

• 測試成功之後，分別往物理機部署平臺，容器部署平臺，離線任務平臺上傳Artifact，註冊待發布版本的信息，並Slack通知用戶結果。

• 構建結束，用戶在ZAE上可以進行後續操作，如選擇一個候選版本進行部署。

每個應用的拉取代碼，準備數據庫，處理測試覆蓋率，發送消息，候選版本的註冊等通用的部分，都會由構建系統統一處理，而接入構建系統的應用，只需要在代碼倉庫中包含一個約定格式的配置文件。

三、達到的目標以及中間遇到的問題

1、低接入成本，高定製能力

構建系統去理解應用要做的事情靠的是約定格式的yaml配置文件，而我們希望這個配置文件能足夠簡單，聲明上必要的部分，如環境、構建、測試步驟就能開始構建。

同時，也要有能力提供更多的定製功能讓應用可以使用，如選擇系統依賴和版本，緩存的路徑，是否需要構建系統提供MySQL以及需要的MySQL版本等，以及可以根據應用的類別自動生成配置文件。

一個最簡單的應用場景：

base_image: python2/jessie

build:

- buildout

test:

unittest:

- bin/test --cover-package=pin --with-xunit --with-coverage --cover-xml

一個更多定製化的場景：

base_image: py_node/jessie

deps:

- libffi-dev

build:

- buildout

- cd admin && npm install && gulp

test:

deps:

- mysql:5.7

unittest:

- bin/test --cover-package=lived,liveweb --with-xunit --with-coverage

coverage_test:

report_fpath: coverage.xml

post_build:

scripts:

- /bin/bash scripts/release_sentry.sh

artifacts:

targets:

- docker

- tarball

cache:

directories:

- admin/static/components

- admin/node_modules

為了儘可能滿足多樣化的業務場景，我們主要將配置文件分為三部分：聲明環境和依賴、構建相關核心環節、聲明Artifact類型。

聲明環境和依賴：

• image，基礎鏡像，需要指明已提前準備好的語言鏡像。

• deps，dependencies的簡寫，聲明使用的系統依賴以及對應的版本。

構建相關核心環節：

• build，構建的步驟，如buildout、npm install、或者執行一個腳本。

• test，測試環節，應用需要聲明構建的步驟，也可以在這裡定製使用的MySQL以及對應的版本。構建系統會每次為其創建新的數據庫，將關鍵信息export為環境變量。

• post build，最後一個環節，如發包、發Slack、郵件通知、或發佈一個Sentry release等。

聲明Artifact類型：

artifact，用於選擇部署的類型，目前支持的有：

• tarball：構建系統會將整個應用Workspace打包上傳到HDFS用於後續的物理機部署。

• docker：鏡像會被push到私有的Docker Registry用於容器部署。

• static：應用指定的路徑打包後會被上傳到HDFS，用於後續的靜態資源部署。

• offline：應用指定的文件會被上傳到離線平臺，用於離線任務的執行。

2、語言開放性

早期所有的構建都在物理機上進行，構建之前需要提前在物理機上安裝好對應的系統依賴，而如果遇到所需要的版本不同時，調度和維護的成本就高了很多。

隨著團隊業務數量和種類的增加，技術選型的演進，這樣的挑戰越來越大。於是構建系統整體的優化方向由物理機向Docker容器化前進。

如今，所有構建都容器中進行，基礎的語言鏡像由應用自己選擇。目前鏡像管理的方式是：

• 我們會事先準備好系統的基礎鏡像。

• 在系統鏡像的基礎上，會構建出不同的語言鏡像供應用使用，如Python，Golang，Java，Node，Rust的各種版本以及混合語言的鏡像。

• 在應用指定的image語言鏡像之上，會安裝上deps指定的系統依賴，再構建出應用的鏡像，應用會在這個環境裡面進行構建測試等。

語言這一層的Dockerfile會被嚴格review，通過的鏡像才能被使用，以更好了解和支持業務技術選型和使用場景。

3、減少不穩定構建，降低問題復現成本

緩存的設計

最開始構建的緩存是落在對應的Jenkins Slave上的，隨著Slave數量的增多，應用構建被分配到不同Slave帶來的代價也越來越大。

為了讓Slave的管理更加靈活以及構建速度和Slave無關，我們最後將緩存按照應用使用的鏡像和系統依賴作為緩存的標識，上傳到HDFS。在每次構建前拉取，構建之後再上傳更新。

針對鏡像涉及到的語言，我們會對常見的依賴進行緩存，如eggs、node_modules，.ivy2/cache、.ivy2/repository。應用如果有其他的文件想要緩存，也支持在配置文件中指定。

依賴獲取穩定性

在對整個構建時間的開銷和不穩定因素的觀察中，我們發現拉取外部依賴是個非常耗時且失敗率較高的環節。

為了讓這個過程更加穩定，我們做了以下的事情：

• 完善內部不同語言的源。

• 在不同語言的基礎鏡像中放入優先使用內部源的配置。

• 搭建HTTP Proxy，提供給以上覆蓋不到的場景。

更低的排查錯誤的成本

本地開發和構建環境存在明顯的差異，可能會出現本地構建成功但是在構建系統失敗的情況。

為了讓用戶能夠快速重現，我們在項目docker-ssh的基礎上做了二次開發，支持直接ssh到容器進行調試。由於容器環境與其他人的構建相隔離，我們不必擔心ssh權限導致的各種安全問題。構建失敗的容器會多保留一天，之後便被回收。

4、規範和標準的落地抓手

我們希望能給接入到構建系統的提高效率的同時，也希望能推動一些標準或者好的實踐，比如完善測試。

圍繞著測試和測試覆蓋率，我們做了以下的事情：

• 配置文件中強制要有測試環節。

• 應用測試結束之後，取到代碼覆蓋率的報告並打點。在提交的Merge Request評論中會給出現在的值和主分支的值的比較，以及最近主分支代碼覆蓋率的變化趨勢。

• 在知乎有應用重要性的分級，對於重要的應用，構建系統會對其要求有測試覆蓋率報告，以及更高的測試覆蓋率。

對於團隊內或者業界的基礎庫，如果發現有更穩定版本或者發現有嚴重問題，構建系統會按照應用的重要性，從低到高提示應用去升級或者去掉對應依賴。

5、高可用和可擴展的集群

Job調度策略

Jenkins Master只進行任務的調度，而實際執行是在不同的Jenkins Node上。

每個Node會被賦予一些label用於任務調度，比如：mysql:5.6, mysql:5.7, common等。構建系統會根據應用的類型分配到不同的label，由Jenkins Master去進一步調度任務到對應的Node上。

高可用設計

集群的設計如下，一個Node對應的是一臺物理機，上面跑了Jenkins Slave（分別連Master和Master Standby），Docker Deamon和MySQL（為應用提供測試的MySQL）。

Slave連接Master等待被調度，而當Jenkins Slave出現故障時，只需摘掉這臺Slave的label，後續將不會有任務調度調度上來。

而當Jenkins Master故障時，如果不能短時間啟動起來時，集群可能就處於不可用狀態了，從而影響整個構建部署。為了減少這種情況帶來的不可用，我們採用了雙Master模型，一臺作為Standby，如果其中一臺出現異常就切換到另一臺健康的Master。

監控和報警

為了更好監控集群的運行狀態，及時發現集群故障，我們加了一系列的監控報警，如：

• 兩個Jenkins Master是否可用，當前的排隊數量情況。

• 集群裡面所有Jenkins Node的在線狀態，Node被命中的情況。

• Jenkins Job執行時間，是否有不合理的過長構建或卡住。

• 以及集群機器的CPU、內存、磁盤使用情況。

四、後續的計劃

在未來我們還希望完善以下的方面：

• Jenkins Slave能更根據集群的負載情況進行動態擴容。

• 一個節點故障時能自動下掉並重新分配已經在上面執行的任務。一個Master down掉能被主動探測到併發生切換。

• 在Merge Request的構建環節推動更多的質量保證標準實施，如更多的接口自動化測試，減少有問題的代碼被合併到主分支。

參考

• Jenkinsfile 相關文檔 ：

  https://jenkins.io/doc/book/pipeline/jenkinsfile/

• <Jenkins Logo>：

  https://jenkins.io/

• <Docker Logo>：Brand Guidelines

作者：Amyyyyy

來源：https://zhuanlan.zhihu.com/p/45694823

dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]

近期熱文

再有人問你分佈式鎖，就把這個丟給他！

適合中小企業，解鎖不同場景X86服務器虛擬化方案

數十個SQL審核項目後，我總結出了這樣一套經驗

當數據庫扼住系統性能咽喉，直接分庫分表能解決嗎？

為什麼不搞集群服務也能實現Redis高可用？