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

背景

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

使用 GitLab SaaS 的現實挑戰

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

為什么選擇遷移

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

核心挑戰

遷移過程中，我們面臨幾個關鍵挑戰：

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

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

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

confusion diagram

我們的方法

我們采用了以下方法來解決這些挑戰：

1. 動態 Runner 配置：設計了一個系統，讓 GitLab CI 檢查現有的 Runner 管理器，并在必要時注冊新的 Runner。

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

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

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

GitLab 的改進建議

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

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

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

結論

遷移到 Kubernetes 的過程雖然充滿挑戰，但也帶來了擴展性和基礎設施目標的實現。然而，由于缺乏指導和頻繁的破壞性變更，這一過程變得不必要地痛苦。對于計劃進行遷移的團隊來說，雖然可能會遇到困難，但只要準備好適應和嘗試，遷移是可行的。

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