隨著 GitLab 宣布不再支持 Docker+Machine 執(zhí)行器，許多團(tuán)隊開始尋求替代方案。對于需要擴(kuò)展性和靈活性的團(tuán)隊來說，遷移到 Kubernetes 是一個自然的選擇。然而，這個過程并不像看起來那么簡單。在這篇文章中，我們將分享我們在遷移過程中遇到的挑戰(zhàn)、解決方案，以及對 GitLab 指導(dǎo)的改進(jìn)建議。

背景

GitLab 的 Docker+Machine 是 Docker Machine 的一個分支，而 Docker 已在 2021 年停止維護(hù)該技術(shù)。GitLab 計劃在 2027 年前停止 Docker+Machine 的維護(hù)，促使團(tuán)隊在此之前進(jìn)行遷移。雖然 GitLab 推薦使用自動擴(kuò)展器作為替代方案，但在實(shí)際操作中，遷移過程充滿復(fù)雜性，尤其對大型團(tuán)隊而言。

使用 GitLab SaaS 的現(xiàn)實(shí)挑戰(zhàn)

GitLab 是一個優(yōu)秀的產(chǎn)品，能夠簡化開發(fā)工作流。然而，對于使用其 SaaS 服務(wù)的團(tuán)隊來說，體驗常常未能達(dá)到預(yù)期。作為平臺工程師，我們的目標(biāo)是通過改善工作流來賦能開發(fā)者，加快交付速度，減少摩擦。然而，我們卻花費(fèi)了大量時間在不明確的文檔上摸索配置最佳實(shí)踐，并處理頻繁的破壞性變更。尤其是大規(guī)模設(shè)置 Runner，感覺更像是試錯而非明確的工程過程。

為什么選擇遷移

我們是一家電子商務(wù)零售商，技術(shù)部門有約 1000 名員工，其中超過 400 名是活躍的 GitLab 用戶。每月運(yùn)行近 100 萬個 CI 任務(wù)。雖然我們的規(guī)模不算特別大，但工具和工作流中的低效問題對我們影響顯著。Docker+Machine 執(zhí)行器曾經(jīng)很好用，但隨著其被棄用，我們轉(zhuǎn)向 Kubernetes，尤其是因為我們的基礎(chǔ)設(shè)施已經(jīng)以 Kubernetes 為中心。

核心挑戰(zhàn)

遷移過程中，我們面臨幾個關(guān)鍵挑戰(zhàn)：

1. Runner 注冊和管理：Docker+Machine 中 Runner 是自動注冊的，但 GitLab 的最近更新增加了復(fù)雜性。我們需要探索多種配置才能找到適合我們的方案。

2. 處理 Runner 令牌：Kubernetes 需要 Helm charts 來部署 Runner，但如何安全地存儲和檢索注冊令牌卻沒有明確的指導(dǎo)。我們最終選擇使用 AWS Systems Manager (SSM) Parameter Store。

3. Helm Chart 更新：每次 GitLab 升級都會破壞我們的 Helm 部署流程，迫使我們在每次版本更新后重寫部分管道。

confusion diagram

我們的方法

我們采用了以下方法來解決這些挑戰(zhàn)：

1. 動態(tài) Runner 配置：設(shè)計了一個系統(tǒng)，讓 GitLab CI 檢查現(xiàn)有的 Runner 管理器，并在必要時注冊新的 Runner。

2. 令牌檢索工作流：在部署過程中動態(tài)從 AWS SSM 獲取令牌，確保安全存儲和重用。

3. 管道韌性：將 Helm chart 邏輯封裝在腳本中，驗證配置變更后再應(yīng)用，并進(jìn)行全面的端到端測試。

4. 自定義輔助鏡像：創(chuàng)建定制的 GitLab 輔助鏡像，以增強(qiáng) CI/CD 管道的安全性和效率。

GitLab 的改進(jìn)建議

1. 提供遷移專用的文檔。

2. 提供清晰的 Kubernetes 工作流示例。

3. 確保版本升級不會不必要地破壞 Runner 注冊和其他工作流。

結(jié)論

遷移到 Kubernetes 的過程雖然充滿挑戰(zhàn)，但也帶來了擴(kuò)展性和基礎(chǔ)設(shè)施目標(biāo)的實(shí)現(xiàn)。然而，由于缺乏指導(dǎo)和頻繁的破壞性變更，這一過程變得不必要地痛苦。對于計劃進(jìn)行遷移的團(tuán)隊來說，雖然可能會遇到困難，但只要準(zhǔn)備好適應(yīng)和嘗試，遷移是可行的。

GitLab 需要更加關(guān)注開發(fā)者體驗，提供更清晰的文檔和更少的破壞性變更，幫助團(tuán)隊更好地完成工作流。