1 面臨的DevOps需求

隨著客戶要求迭代速度的加快，公司的項目管理、交付管理面臨了來自公司內(nèi)外部的巨大挑戰(zhàn)。

公司目前需要管理很多客戶項目和自身迭代產(chǎn)品項目，產(chǎn)品使用Go、Java、NodeJS等多種技術(shù)棧的多個分支的代碼項目。而且每周需要交付多個測試版本進行持續(xù)驗證。同時，還要應對客戶現(xiàn)場的緊急版本修復、客戶定制版本交付等場景。

解決上述問題的核心就是要提升效率，加快交付速度。

2 CI/CD規(guī)劃概覽

2.1 架構(gòu)總覽

結(jié)合 Kubernetes 的一些基礎理念和特性，綜合考慮容器 PaaS 平臺、微服務治理平臺在 DevOps 的需求，并融合企業(yè)內(nèi)部已有的 CI/CD 等工具，自主實現(xiàn)了一套更適合于云原生應用平臺的 DevOps 服務體系?；镜募夹g(shù)架構(gòu)及實現(xiàn)方式如下圖所示：

上圖中，代碼倉庫中的代碼會被Job 創(chuàng)建在構(gòu)建節(jié)點上的 Pod 的容器拉取，并執(zhí)行編譯、單元測試、掃描、打包，制作鏡像、 Push 鏡像等操作后，這個Pod 就會被銷毀。容器日志會被節(jié)點的 Agent 發(fā)送到日志服務中心，可以提供容器被銷毀后的日志查詢。也可以使用 CronJob 執(zhí)行定時任務。

該方案具備以下優(yōu)勢：

不需要單獨部署復雜的高可用 CI/CD 服務，比如 Jenkins 集群等，簡化了部署管理的復雜度。

構(gòu)建任務均通過鏡像進行封裝，并在容器中進行，接口更加標準、透明。

對構(gòu)建任務的資源、限額、日志、監(jiān)控、告警、計費等諸多能力可以直接利用 PaaS 平臺，而無需重復開發(fā)，PaaS 未來的能力也可以直接為 DevOps 服務。

可以通過容器 PaaS，讓構(gòu)建任務具備更高級的調(diào)度能力。

PaaS 層對底層資源的彈性伸縮也可以為 DevOps 服務，對構(gòu)建資源進行伸縮策略的定義，實現(xiàn)構(gòu)建資源的彈性。

對 DevOps 平臺的管理運維可以同容器 PaaS 一致，沒有額外的學習成本。

通過容器、鏡像等標準概念，對構(gòu)建任務進行封裝，并快速實現(xiàn) DevOps 的構(gòu)建模版，使得 DevOps 平臺通過自定義模版具備更好的擴展能力。

2.2 關(guān)鍵技術(shù)

2.2.1 技術(shù)要點

這種架構(gòu)模式下，可以把每一個構(gòu)建任務通過Pod Spec來進行描述，相關(guān)的構(gòu)建任務能力可以通過以下方式映射到Pod Spec中。

同樣道理，結(jié)合上層的Job/CronJob，我們就可以控制構(gòu)建的執(zhí)行策略，比如構(gòu)建任務期望的并?執(zhí)?的最? Pod 數(shù)量，期望的成功完成的 Pod 數(shù)量，從 Job 創(chuàng)建到活躍狀態(tài)的超時時間(默認 12 ?時)，標記 Job 為失敗前的最?重試次數(shù)，默認 = 6;以及通過Cron 格式的任務計劃定義，Job 執(zhí)?的并?策略，是否暫停后續(xù)執(zhí)?，保留運?成功/失敗的歷史 Job 的數(shù)量。

2.2.2 實踐舉例

這里舉兩個例子，來說明時速云 DevOps 平臺中每個構(gòu)建任務的工作原理：

構(gòu)建Docker鏡像，也就是我們經(jīng)常使用的從代碼生成鏡像的任務模版，其基本工作方式如下：

每個構(gòu)建任務都是一個Job，會按照用戶傳遞的信息組裝成Job的結(jié)構(gòu)，并由K8s調(diào)度并執(zhí)行，有DevOps Manager管理Job的運行情況。其中使用了InitContainer、Volume、Secret等多種K8s資源。

服務持續(xù)部署，平臺提供了鏡像部署、應用模版部署、Spinnaker、時速云 DevOps 平臺集成、應用包部署、服務狀態(tài)檢查等多種持續(xù)部署相關(guān)模版，通過靈活組合使用，可以滿足幾乎所有場景下的持續(xù)部署需求。如下圖所示的基本工作流程，我們會把不同部署方式封裝成對應的鏡像，并提供可視化配置界面供用戶使用。

同樣，我們也提供了忽略某個構(gòu)建任務的執(zhí)行，某個構(gòu)建任務失敗時速云 DevOps 平臺繼續(xù)執(zhí)行，指定構(gòu)建節(jié)點，自定義構(gòu)建任務所需資源，當然也支持構(gòu)建任務使用GPU資源，進行機器學習相關(guān)的時速云 DevOps 平臺處理能力。

2.3 總結(jié)

借助 Kubernetes 自動編排、自動回收資源的機制，減少了人工干預。結(jié)合Kubernetes 提供的豐富的資源類型，CI/CD 解決方案也有了更多的選項和思路。仿佛 Kubernetes 是為 CI/CD 專門定做的。

3 CI/CD工具及實踐

3.1 工具及流程概覽

我們的DevOps工具鏈有Jira, Gitlab, 時速云 DevOps 平臺，Sonarqube, TestLink, Harbor

Jira: 項目管理;

Gitlab: 代碼托管、在線Review;

時速云 DevOps 平臺：基于 Kubernetes 的代碼拉取，編譯，代碼掃描，單元測試，打包，構(gòu)建鏡像、持續(xù)部署，審批，郵件;

Sonarqube：代碼靜態(tài)掃描;

TestLink: 測試管理;

Harbor: 鏡像托管，鏡像安全掃描;

流程如下：

3.2 實踐說明

3.2.1 需求/缺陷管理

需求和缺陷管理我們使用功能強大的Jira工具，以兩周一迭代方式進行敏捷式開發(fā)。

3.2.2 代碼 Review/Merge

聊天工具集成 gitlab，PR提交后Reviewer及時看到提交信息，進行Review和Merge。

3.2.3 Gitlab觸發(fā)自動化構(gòu)建

時速云 DevOps 平臺自動生成Gitlab項目的webhook, 當gitlab有事件發(fā)生，把事件信息發(fā)送到時速云 DevOps 平臺，時速云 DevOps 平臺根據(jù)條件觸發(fā)自動執(zhí)行構(gòu)建。

3.2.4 時速云 DevOps 平臺

3.2.4.1 流程簡介

時速云 DevOps 平臺基于Kubernetes和Docker運行具體任務，由 Kubernetes調(diào)度、執(zhí)行完后銷毀。每一個任務模板最終生成Kubernetes的Job，Job會生成Pod運行任務, 并管理生命周期。

每個任務模板鏡像都有為自身任務的最小化工具。比如maven任務鏡像只有maven客戶端命令工具，容器被job生成時，會通過進入點運行maven命令，運行結(jié)束后將結(jié)束容器。代碼掃描任務會有sonar-scanner客戶端工具，Docker構(gòu)建任務可以運行Docker build命令構(gòu)建鏡像和Push鏡像到Harbor。

鏡像推送到Harbor后會使用平臺持續(xù)部署任務模板更新服務。

@

持續(xù)部署成功后服務會被升級到最新版本。

3.2.4.2 任務模板

時速云 DevOps 平臺的任務模板是為執(zhí)行任務的鏡像和數(shù)據(jù)集合。

sonar掃描任務為例，sonar掃描任務執(zhí)行就是容器化運行 sonar-scanner。

下圖為sonar掃描任務的Dockerfile, 就是把代碼和sonar掃描配置文件拷貝到指定目錄，運行sonar-scanner命令。

執(zhí)行結(jié)果以Rest API方式發(fā)送到平臺，平臺記錄執(zhí)行結(jié)果，并根據(jù)設置執(zhí)行下一步任務或失敗退出。

3.2.5 集成測試

測試有測試用例，測試用例有測試結(jié)果，如果測試結(jié)果與期待結(jié)果不符，同步到 Jira, 再執(zhí)行編碼的步驟，形成一個閉環(huán)。

測試用例和測試版本的測試結(jié)果使用TestLink工具管理。

集成測試是人工測試和基于Selenium的python腳本的自動化測試共同完成。

3.2.6 Harbor 同步

測試人員進行測試通過以后，使用Harbor鏡像同步功能，同步到運維環(huán)境Harbor。

3.2.7 Harbor 鏡像更新后通過觸發(fā)設置觸發(fā)執(zhí)行部署任務

harbor的common/config/registry/config.yml設置notification屬性為時速云 DevOps 平臺 webhook地址和認證方式，時速云 DevOps 平臺可以根據(jù) payload 信息觸發(fā)執(zhí)行 CI/CD。

3.2.8 部署運維服務

時速云 DevOps 平臺被觸發(fā)執(zhí)行后，與上面部署一樣會根據(jù)新的鏡像更新部署新的服務。

3.2.9 自動標記 Jira

集成測試結(jié)束以后，通過 Jira API , 把 gitlab 中的大括號里相應的 Jira issue 為關(guān)閉狀態(tài)，添加部署版本說明

3.2.10 保障代碼和最終交付產(chǎn)物的源頭一致性

如下圖，在代碼構(gòu)建時把代碼的版本信息一同寫入鏡像可以做到最終交付產(chǎn)物和代碼源頭的一致性比較。

git rev-parse --short HEAD > .gitversion

git log --pretty=oneline HEAD...$PREVIOUS_COMMIT_ID > .gitdiff

4 CI/CD流程總結(jié)

⑴ Jira, Gitlab, TestLink, Harbor 等工具的集成、 Kubernetes 特性和各組件的靈活使用、自動化構(gòu)建流程使得 CI/CD 流程縮短了交付時間。而且從代碼到最終交付產(chǎn)物的可驗證性，需求到代碼和Bug 到代碼的可追溯性，提高了效率。

⑵ 于公司服務器的計算資源也使得因 Kubernetes 的機制發(fā)揮到優(yōu)先資源下靈活應用，讓各個團隊避免了因為計算資源不夠等待資源的情況。

⑶ Kubernetes 的良好機制，使得公司有限服務器資源下靈活應用，讓各個團隊避免了因為計算資源不夠等待資源的情況。

⑷ 時速云 DevOps 平臺任務模板容易擴張、可以快速集成其他第三方工具，也為管理、測試、研發(fā)團隊快速提供需要的工具集成。

⑸ 時速云 DevOps 平臺任務模板的最小化，節(jié)省了資源，節(jié)省了費用。

⑹ 對部分開源項目的修改和貢獻也提高了工作的效率。比如修改 Harbor 的用戶賬戶體系和驗證方式與平臺一致，減少了用戶在交付中鏡像賬號的額外管理。修改 TestLink 源碼，實現(xiàn)一鍵創(chuàng)建 Jira Bug ，自動使 Jira 項目管理與測試管理工具互相追蹤，方便查看與管理。

當然我們的 CI/CD 流程還有很多不足，比如缺少 ChatOps 等更方便的功能、對已有流程復盤并優(yōu)化、還需要集成更多 CI/CD工具等。

5 未來規(guī)劃

⑴ 隨著Kubernetes 的版本升級，提供了更多的功能，這些功能是否能讓我們的 CI/CD 更靈活。比如Node、Pod 的親和性設置，部署容器啟動先后順序設置等。

⑵ 提供ChatOps功能，通過集成提供 API 的聊天工具。

⑶ 與更多的 DevOps 工具集成，包括 GitInspector等。

⑷ 對開源工具的優(yōu)化，以及對開源社區(qū)的貢獻。比如 TestLink 等還有很多缺陷，集成時會遇到需要解決的問題等。

⑸ 持續(xù)增強DevOps前期項目管理、產(chǎn)品管理的功能模塊，例如立項管理、路線圖、需求管理、版本管理、發(fā)布物、產(chǎn)品運營、里程碑、迭代計劃、測試管理等功能方向，有助于奠定項目/產(chǎn)品的基石。

⑹ 持續(xù)增強DevOps后期度量與優(yōu)化功能模塊，例如質(zhì)量、效率、進度、APM、問題庫、自愈等功能方向，幫助項目/產(chǎn)品后期更好的運營。

（免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。
任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）