1 面臨的DevOps需求
隨著客戶要求迭代速度的加快，公司的項目管理、交付管理面臨了來自公司內(nèi)外部的巨大挑戰(zhàn)。
公司目前需要管理很多客戶項目和自身迭代產(chǎn)品項目，產(chǎn)品使用Go、Java、NodeJS等多種技術(shù)棧的多個分支的代碼項目。而且每周需要交付多個測試版本進行持續(xù)驗證。同時，還要應(yīng)對客戶現(xiàn)場的緊急版本修復(fù)、客戶定制版本交付等場景。
解決上述問題的核心就是要提升效率，加快交付速度。
2 CI/CD規(guī)劃概覽
2.1 架構(gòu)總覽
結(jié)合 Kubernetes 的一些基礎(chǔ)理念和特性，綜合考慮容器 PaaS 平臺、微服務(wù)治理平臺在 DevOps 的需求，并融合企業(yè)內(nèi)部已有的 CI/CD 等工具，自主實現(xiàn)了一套更適合于云原生應(yīng)用平臺的 DevOps 服務(wù)體系?；镜募夹g(shù)架構(gòu)及實現(xiàn)方式如下圖所示：
上圖中，代碼倉庫中的代碼會被Job 創(chuàng)建在構(gòu)建節(jié)點上的 Pod 的容器拉取，并執(zhí)行編譯、單元測試、掃描、打包，制作鏡像、 Push 鏡像等操作后，這個Pod 就會被銷毀。容器日志會被節(jié)點的 Agent 發(fā)送到日志服務(wù)中心，可以提供容器被銷毀后的日志查詢。也可以使用 CronJob 執(zhí)行定時任務(wù)。
該方案具備以下優(yōu)勢：
不需要單獨部署復(fù)雜的高可用 CI/CD 服務(wù)，比如 Jenkins 集群等，簡化了部署管理的復(fù)雜度。
構(gòu)建任務(wù)均通過鏡像進行封裝，并在容器中進行，接口更加標(biāo)準(zhǔn)、透明。
對構(gòu)建任務(wù)的資源、限額、日志、監(jiān)控、告警、計費等諸多能力可以直接利用 PaaS 平臺，而無需重復(fù)開發(fā)，PaaS 未來的能力也可以直接為 DevOps 服務(wù)。
可以通過容器 PaaS，讓構(gòu)建任務(wù)具備更高級的調(diào)度能力。
PaaS 層對底層資源的彈性伸縮也可以為 DevOps 服務(wù)，對構(gòu)建資源進行伸縮策略的定義，實現(xiàn)構(gòu)建資源的彈性。
對 DevOps 平臺的管理運維可以同容器 PaaS 一致，沒有額外的學(xué)習(xí)成本。
通過容器、鏡像等標(biāo)準(zhǔn)概念，對構(gòu)建任務(wù)進行封裝，并快速實現(xiàn) DevOps 的構(gòu)建模版，使得 DevOps 平臺通過自定義模版具備更好的擴展能力。
2.2 關(guān)鍵技術(shù)
2.2.1 技術(shù)要點
這種架構(gòu)模式下，可以把每一個構(gòu)建任務(wù)通過Pod Spec來進行描述，相關(guān)的構(gòu)建任務(wù)能力可以通過以下方式映射到Pod Spec中。
同樣道理，結(jié)合上層的Job/CronJob，我們就可以控制構(gòu)建的執(zhí)行策略，比如構(gòu)建任務(wù)期望的并?執(zhí)?的最? Pod 數(shù)量，期望的成功完成的 Pod 數(shù)量，從 Job 創(chuàng)建到活躍狀態(tài)的超時時間(默認(rèn) 12 ?時)，標(biāo)記 Job 為失敗前的最?重試次數(shù)，默認(rèn) = 6;以及通過Cron 格式的任務(wù)計劃定義，Job 執(zhí)?的并?策略，是否暫停后續(xù)執(zhí)?，保留運?成功/失敗的歷史 Job 的數(shù)量。
2.2.2 實踐舉例
這里舉兩個例子，來說明時速云 DevOps 平臺中每個構(gòu)建任務(wù)的工作原理：
構(gòu)建Docker鏡像，也就是我們經(jīng)常使用的從代碼生成鏡像的任務(wù)模版，其基本工作方式如下：
每個構(gòu)建任務(wù)都是一個Job，會按照用戶傳遞的信息組裝成Job的結(jié)構(gòu)，并由K8s調(diào)度并執(zhí)行，有DevOps Manager管理Job的運行情況。其中使用了InitContainer、Volume、Secret等多種K8s資源。
服務(wù)持續(xù)部署，平臺提供了鏡像部署、應(yīng)用模版部署、Spinnaker、時速云 DevOps 平臺集成、應(yīng)用包部署、服務(wù)狀態(tài)檢查等多種持續(xù)部署相關(guān)模版，通過靈活組合使用，可以滿足幾乎所有場景下的持續(xù)部署需求。如下圖所示的基本工作流程，我們會把不同部署方式封裝成對應(yīng)的鏡像，并提供可視化配置界面供用戶使用。
同樣，我們也提供了忽略某個構(gòu)建任務(wù)的執(zhí)行，某個構(gòu)建任務(wù)失敗時速云 DevOps 平臺繼續(xù)執(zhí)行，指定構(gòu)建節(jié)點，自定義構(gòu)建任務(wù)所需資源，當(dāng)然也支持構(gòu)建任務(wù)使用GPU資源，進行機器學(xué)習(xí)相關(guān)的時速云 DevOps 平臺處理能力。
2.3 總結(jié)
借助 Kubernetes 自動編排、自動回收資源的機制，減少了人工干預(yù)。結(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, 當(dāng)gitlab有事件發(fā)生，把事件信息發(fā)送到時速云 DevOps 平臺，時速云 DevOps 平臺根據(jù)條件觸發(fā)自動執(zhí)行構(gòu)建。
3.2.4 時速云 DevOps 平臺
3.2.4.1 流程簡介
時速云 DevOps 平臺基于Kubernetes和Docker運行具體任務(wù)，由 Kubernetes調(diào)度、執(zhí)行完后銷毀。每一個任務(wù)模板最終生成Kubernetes的Job，Job會生成Pod運行任務(wù), 并管理生命周期。
每個任務(wù)模板鏡像都有為自身任務(wù)的最小化工具。比如maven任務(wù)鏡像只有maven客戶端命令工具，容器被job生成時，會通過進入點運行maven命令，運行結(jié)束后將結(jié)束容器。代碼掃描任務(wù)會有sonar-scanner客戶端工具，Docker構(gòu)建任務(wù)可以運行Docker build命令構(gòu)建鏡像和Push鏡像到Harbor。
鏡像推送到Harbor后會使用平臺持續(xù)部署任務(wù)模板更新服務(wù)。
@
持續(xù)部署成功后服務(wù)會被升級到最新版本。
3.2.4.2 任務(wù)模板
時速云 DevOps 平臺的任務(wù)模板是為執(zhí)行任務(wù)的鏡像和數(shù)據(jù)集合。
sonar掃描任務(wù)為例，sonar掃描任務(wù)執(zhí)行就是容器化運行 sonar-scanner。
下圖為sonar掃描任務(wù)的Dockerfile, 就是把代碼和sonar掃描配置文件拷貝到指定目錄，運行sonar-scanner命令。
執(zhí)行結(jié)果以Rest API方式發(fā)送到平臺，平臺記錄執(zhí)行結(jié)果，并根據(jù)設(shè)置執(zhí)行下一步任務(wù)或失敗退出。
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ā)設(shè)置觸發(fā)執(zhí)行部署任務(wù)
harbor的common/config/registry/config.yml設(shè)置notification屬性為時速云 DevOps 平臺 webhook地址和認(rèn)證方式，時速云 DevOps 平臺可以根據(jù) payload 信息觸發(fā)執(zhí)行 CI/CD。
3.2.8 部署運維服務(wù)
時速云 DevOps 平臺被觸發(fā)執(zhí)行后，與上面部署一樣會根據(jù)新的鏡像更新部署新的服務(wù)。
3.2.9 自動標(biāo)記 Jira
集成測試結(jié)束以后，通過 Jira API , 把 gitlab 中的大括號里相應(yīng)的 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 到代碼的可追溯性，提高了效率。
⑵ 于公司服務(wù)器的計算資源也使得因 Kubernetes 的機制發(fā)揮到優(yōu)先資源下靈活應(yīng)用，讓各個團隊避免了因為計算資源不夠等待資源的情況。
⑶ Kubernetes 的良好機制，使得公司有限服務(wù)器資源下靈活應(yīng)用，讓各個團隊避免了因為計算資源不夠等待資源的情況。
⑷ 時速云 DevOps 平臺任務(wù)模板容易擴張、可以快速集成其他第三方工具，也為管理、測試、研發(fā)團隊快速提供需要的工具集成。
⑸ 時速云 DevOps 平臺任務(wù)模板的最小化，節(jié)省了資源，節(jié)省了費用。
⑹ 對部分開源項目的修改和貢獻也提高了工作的效率。比如修改 Harbor 的用戶賬戶體系和驗證方式與平臺一致，減少了用戶在交付中鏡像賬號的額外管理。修改 TestLink 源碼，實現(xiàn)一鍵創(chuàng)建 Jira Bug ，自動使 Jira 項目管理與測試管理工具互相追蹤，方便查看與管理。
當(dāng)然我們的 CI/CD 流程還有很多不足，比如缺少 ChatOps 等更方便的功能、對已有流程復(fù)盤并優(yōu)化、還需要集成更多 CI/CD工具等。
5 未來規(guī)劃
⑴ 隨著Kubernetes 的版本升級，提供了更多的功能，這些功能是否能讓我們的 CI/CD 更靈活。比如Node、Pod 的親和性設(shè)置，部署容器啟動先后順序設(shè)置等。
⑵ 提供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)品后期更好的運營。
（免責(zé)聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準(zhǔn)確性及可靠性，但不保證有關(guān)資料的準(zhǔn)確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負(fù)責(zé)。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負(fù)任何法律責(zé)任。
任何單位或個人認(rèn)為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。 ）
