本文首發於：Jenkins 中文社群
在我們正在進行的 Kubernetes FAQ 系列中，我們回答了社群中一些常見的問題，本週我們將討論在選擇 CI/CD 工具時需要考慮什麼。
目前已經有大量的 CI/CD 工具可供選擇-開源解決方案和商業解決方案。在這裡，我們重點介紹在設定持續交付流水線時要考慮的一些最重要的注意事項。
在這篇文章中你將學到：
- 為什麼需要自動化流水線
- 部署典型流水線的元件
- CD 流水線功能需要考慮
- 如何合併 GitOps
為什麼要建立自動化 CI/CD 流水線？
自動化 CI/CD 流水線有許多好處：
- 將您的上線時間從數週或數月減少到數天或數小時。通過自動化流水線，開發團隊可以提高發布的速度以及程式碼的質量。以小增量連續新增的新功能和修復可以使產品具有更少的缺陷。
- 一個強大的開發團隊。由於交付流水線的所有階段都可供團隊中的任何人檢查、改進和驗證，因此可以建立對構建的所有權，從而鼓勵整個組織的強大團隊合作和協作能力。
- 降低軟體開發的風險和成本。自動化鼓勵開發人員在繼續前進之前分階段驗證程式碼更改，從而減少了缺陷最終出現在生產中的機會。
- 減少進展中的工作量。CD 流水線提供從開發到客戶的快速反饋迴圈。這個迭代週期不僅可以幫助您構建正確的產品，而且還允許開發人員更快地進行產品改進，從而減少正在進行的工作。
典型的部署流水線
CD 流水線由幾個不同的階段組成; 一個工具不能滿足所有這些步驟。
以下是構成大多數自動化流水線的步驟：
- 在膝上型電腦上編寫程式碼，將其推入原始碼倉庫(如 Git)。
- 程式碼通過單元、整合和其他自動化測試。如果測試通過，將構建成新的 Docker 映象。
- 將映象推送到映象倉庫。
- 將新映象推送到叢集中。
思考 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 作為事實源，可以比較和警告所需的狀態和當前狀態。這不僅可以確保叢集保持最新，而且還可以在叢集崩潰時提供從災難中快速恢復的方法。
譯者：史彥軍
