應該使用什麼 CI/CD 工具？

本文首發於：Jenkins 中文社區

在咱們正在進行的 Kubernetes FAQ 系列中，咱們回答了社區中一些常見的問題，本週咱們將討論在選擇 CI/CD 工具時須要考慮什麼。

目前已經有大量的 CI/CD 工具可供選擇-開源解決方案和商業解決方案。在這裏，咱們重點介紹在設置持續交付流水線時要考慮的一些最重要的注意事項。

在這篇文章中你將學到：

• 爲何須要自動化流水線
• 部署典型流水線的組件
• CD 流水線功能須要考慮
• 如何合併 GitOps

爲何要建立自動化 CI/CD 流水線？

自動化 CI/CD 流水線有許多好處：

• 將您的上線時間從數週或數月減小到數天或數小時。經過自動化流水線，開發團隊能夠提升發佈的速度以及代碼的質量。以小增量連續添加的新功能和修復可使產品具備更少的缺陷。
• 一個強大的開發團隊。因爲交付流水線的全部階段均可供團隊中的任何人檢查、改進和驗證，所以能夠建立對構建的全部權，從而鼓勵整個組織的強大團隊合做和協做能力。
• 下降軟件開發的風險和成本。自動化鼓勵開發人員在繼續前進以前分階段驗證代碼更改，從而減小了缺陷最終出如今生產中的機會。
• 減小進展中的工做量。CD 流水線提供從開發到客戶的快速反饋循環。這個迭代週期不只能夠幫助您構建正確的產品，並且還容許開發人員更快地進行產品改進，從而減小正在進行的工做。

典型的部署流水線

CD 流水線由幾個不一樣的階段組成; 一個工具不能知足全部這些步驟。

如下是構成大多數自動化流水線的步驟：

1. 在筆記本電腦上編寫代碼，將其推入源代碼倉庫(如 Git)。
2. 代碼經過單元、集成和其餘自動化測試。若是測試經過，將構建成新的 Docker 鏡像。
3. 將鏡像推送到鏡像倉庫。
4. 將新鏡像推送到集羣中。

思考 CD 流水線的特性

建立流水線的困難之一是成功地將您想要使用的工具粘合在一塊兒。這些是爲流水線選擇工具時要考慮的主要功能：

• 端到端的安全性
• 可以使用徹底可重現的審計跟蹤進行回滾
• 內置可觀察性和警報功能
• 平均快速部署時間以及平均快速恢復時間
• 簡單的開發人員經驗和工做流程

流水線端到端的安全性

在市場上的 CI/CD 工具中，有些工具將 CI 和 CD 部分合併爲一個工具。或者更糟糕的是，那些負責建立 CI/CD 流水線的人將組裝一系列手工鍛造的腳本，這些腳本能夠在一個方向上經過流水線推送代碼，或執行被稱爲CIOP 流水線。

出於多種緣由，您不但願這樣作。這是一種反模式，由於集羣安全和其餘憑據不在集羣以外，這多是不安全的。建議的方法是使用實​​現 Kubernetes Operator 的工具。

部署到集羣的 Kubernetes Operator 能夠監視倉庫中的新鏡像。更進一步，若是您的整個集羣狀態（經過聲明性清單）都保存在 Git 中，那麼「diff alert」能夠成爲從倉庫中「提取」新鏡像並將其部署到集羣的動力。這不只是一種更安全的部署方法，並且還爲開發人員提供了一種更簡單的方法來應用和回滾生產環境的更改。

具有完整審計跟蹤回滾

跟蹤差別歷史記錄，以及在團隊中處理大型應用程序時管理新舊部署的回滾可能具備挑戰性。您須要一個能夠輕鬆處理此類方案的工具。若是您擁有一個徹底可審計的路徑，它能夠幫助您瞭解什麼時候什麼時候執行了哪些操做，這也有助於 SOC 2合規性規定的增長。

可觀察性和警報

將可觀察性歸入您的流水線意味着什麼？

爲了提升你的速度，你的流水線須要結合可觀察性來回答這些問題：

若是自動發佈更改，我怎麼知道它是否有效？ 在複雜的分佈式系統中，我如何理解問題、診斷問題並管理事件 - 尤爲是當您須要回滾時？ 將持續交付與實時可觀察性相結合，使您的開發團隊可以在部署新功能以前作出更好的決策。

新功能和補丁被推送到 Git 並觸發部署流水線，當它們準備好發佈時，理想狀況下應該對正在運行的集羣實時監控。這容許開發人員根據反饋作出決策。能夠將它們返回到流水線的起點，或將更新後的鏡像部署到生產集羣中。

更快的平均部署和恢復時間

除了可以頻繁可靠地部署以外，還須要考慮考慮一個重要場景，是在集羣宕機時的恢復。這須要快速、平滑，而且可能由可能不是由 Kubernetes 專業的開發人員來執行。

簡單的開發人員經驗和 Git 工做流程

爲了在當今的雲原生世界中快速發展，開發人員必須從端到端控制流水線。提交憑據等待人來回復的時期已經沒有了。從開發人員一直使用的工具構建流水線是有意義的。像 Git 這樣的工具。

使用 GitOps，有三個基本原則：

＃1.全部能夠描述的內容都必須存儲在 Git 中

經過使用 Git 做爲事實源，能夠觀察集羣並將其與所需的狀態進行比較。目標是描述全部內容：策略、代碼、配置，甚至監控事件和版本控制。將全部內容保持在版本控制之下，能夠加強收斂性，若是最初它們沒有成功，則能夠從新應用更改。

＃2.不要直接使用 kubectl

通常來講，使用命令行工具 kubectl 直接部署到集羣不是一個好主意。許多人讓他們的 CI 工具推進部署，可是這樣作可能會對生產環境遭受更容易被攻擊的風險。

＃3.使用遵循操做符模式的 Kubernetes Operator

使用遵循操做符模式的 Kubernetes Operator，您的集羣始終經過其簽入 Git 的配置文件與「事實源」保持同步。因爲集羣的所需狀態保存在 Git 中，所以還能夠觀察到與正在運行的集羣的差別。

將 GitOps 工做流程應用於流水線

經過採用 GitOps，開發人員能夠經過提取請求管理基礎架構配置和軟件部署以及回滾。當真實來源與集羣中運行的不一樣時，集羣會自動與 Git 中保存的內容同步。

Weave Cloud 的部署代理在集羣內部運行。這意味着容器映像註冊表和集羣 API 的憑據永遠不會離開集羣的域。經過使用 Git 做爲事實源，能夠比較和警告所需的狀態和當前狀態。這不只能夠確保集羣保持最新，並且還能夠在集羣崩潰時提供從災難中快速恢復的方法。

譯者：史彥軍