GitLab Auto DevOps 環境建置步驟

前言

感謝各位讀者購買《和艦長一起30天玩轉GitLab》（第二版），在本書第六章我們要來牛刀小試 GitLab Auto DevOps。

由於 GitLab 近年改版迅速，為幫助讀者能跟上最新版本進度，順利開始嘗試 Auto DevOps，因此特別將「GitLab Auto DevOps 環境建置步驟」獨立公開於此網頁。本網頁會根據 GitLab 版本更新狀況，適度修正內容。

如果你按著本網頁的步驟操作，仍無法正常使用 Auto DevOps，還請透過艦長的 Facebook 粉專或 Google 線上表單與我聯繫，方便我了解你遭遇的狀況，以便能對此網頁內容作出修正，謝謝

操作步驟

Auto DevOps 將會使用到 Kubernetes (K8s)，但自架 K8s 有著並非每位工程師都能立即負擔的技術學習門檻，因此以下步驟我們會直接採用雲端供應商提供的現成 K8s 服務。

以下步驟，我們皆會在 gitlab.com 上完成，如果你尚未有 gitlab.com 的帳號，可以先完成帳號註冊，再繼續以下的步驟。

安裝 kubectl & helm

在後續的步驟中，我們會使用到 kubectl 與 helm 這兩項 K8s 相關的工具，你可以考慮安裝在你的 local 環境（例如你的 mac 電腦），或是自行準備另一個乾淨的環境，並在其中安裝這些工具，以備後續步驟使用。

建立 K8s Cluster 並取得足夠的權限

（如果你已經很熟悉 kubectl，也知道如何設置 kubeconfig 連接並操作 K8s，可以跳過這個章節的步驟。）

  1. 請選擇任何一家你熟習的雲端供應商，並建立一組你能擁有最高管理權限的 K8s Cluster。下面我就以價格平易近人的雲端供應商 DigitalOcean 提供的 Kubernetes 服務為例。

  2. 在 DigitalOcean 我們直接啟用一組最小規模的 K8s。

    （用上方的捷徑，選擇 Create Kubernetes）

    （只是 DEMO，所以我就只開一個 Node，但還是給予一定數量的 vCPUs 與 RAM。）

  3. 當 K8s Cluster 建立完畢之後，即可取得現成可用的 kubeconfig。

    （需要等待一段時間，K8s 才能建立完畢。）

    （接著就可以自行下載 kubeconfig。）

  4. 將 kubeconfig 提供給 kubectl 使用。

    （如果你沒有使用其他的 K8s Cluster，那可以如上圖，在 Terminal 中，直接把剛下載的 kubeconfig 檔案，搬家並改名 ~/.kube/config，這是 kubectl 預設會讀取的 Config 路徑及檔名；記得把權限改小一些，畢竟這是一個重要的檔案。）

  5. 嘗試在 Terminal 執行指令 kubectl get pods --all-namespaces，如果能出現類似下圖的結果，就代表你能正常連接並操作 K8s。

    （執行指令，確認你是否能順利連接並操作 K8s。你也可以試試其他的 kubectl 指令，像是 kubectl get nodes。）

建立 GitLab Group

  1. 在 gitlab.com 建立一個乾淨的 Group，可以取一個短一點的名稱，例如 demo。

    （因為太多人的 Group 都叫做 demo，因此上圖的 Group URL 會被自動補上數字，變成不與他人重複的值 demo1727，你可以自己改一個唯一值。）

    （如果 Group URL 重複，會出現上圖這樣的提示。）

註冊 GitLab K8s Agent

  1. 在我們建好的 Group demo 內，建立一個空白的 Project k8s。

    （如上圖，Project 要建立在前述的 Group 內，因此在 Project URL 這裡，要選擇正確的 Namespace，以我們的範例即是 demo1727。）

  2. 在 Project 內建立 K8s Agent 所需的 Config 檔案 .gitlab/agents/k8s-agent/config.yaml；檔案的內容先維持空白即可。（k8s-agent/config.yaml，這一段代表我們要建立的是名為 k8s-agent 的 K8s Agent。）

    （你可以直接使用 GitLab 的 Web IDE 建立檔案。）

    （直接輸入完整的路徑與檔名，會連同資料夾一併建立。）

    （直接在 Web IDE 送出 Commit 到 main branch。）

  3. 下一步我們要註冊 K8s Agent。

    （從左側的選單，前往 Infrastructure > Kubernetes clusters，接著按下 Connect a cluster；找到我們剛才產生的 K8s Agent k8s-agent，最後按下 Register。）

  4. 執行 UI 上顯示的 helm 指令，完成 K8s Agent 與 K8s Cluster 之間的 Connect。

    （雖然有提供其他的 Connect 方式，但 gitlab.com 也建議你使用 helm 來處理這件事。）

    （執行 helm 指令，會得到類似上圖的結果。）

    （當 helm 指令執行完畢後，如果你再次查詢 K8s 上的 pods，應該會多出一個 gitlab-agent-k8s-agent。）

在 K8s 上自動架設 ingress、cert-manager、prometheus

  1. 再次於同一個 Group demo 內建立另一個 Project manifests。

    （這次要用 Create from template，選用名為 GitLab Cluster Management 的 Project template。）

    （注意 Project URL，此 Project 要確實放在同一個 Group 內。確定無誤就讓它完成 Project 的建立。）

  2. 回到上一個 Project k8s，修改 .gitlab/agents/k8s-agent/config.yaml，我們要透過 GitLab 的 CI/CD Tunnel 功能分享 KUBECONFIG。

    在 .gitlab/agents/k8s-agent/config.yaml 內加入以下的內容，記得一樣要 Commit 到 main branch。

    ci_access:
  groups:
   - id: demo1727
   # demo1727 請改成最前面你建立的 Group 之 namespace

    （如圖，我依然是使用 Web IDE 來修改檔案。總之這個步驟是在設定 CI/CD Tunnel 功能，它可以將 KUBECONFIG 分享給整個 Group 使用。）

  3. 接著我們要前往 Group demo，設置 2 個後續 CI/CD 需要的 Variables，分別是 KUBE_CONTEXT 與 KUBE_NAMESPACE。

    （進入 Group demo 的 Settings > CI/CD > Variables。）

    按下 Add variable 後建立第一個 Variable KUBE_CONTEXT。Value 要輸入的是我們要使用哪一個 K8s Agent，它完整的寫法如下

    <Project namespace>/<Project name>:<Agent Name>

    因此以我的示範為例即是 demo1727/k8s:k8s-agent。

    • <Project namespace> = demo1727
    • <Project name> = k8s
    • <Agent Name> = k8s-agent

    因此組合起來就如下圖這樣填寫。

    第二個 Variable 是 KUBE_NAMESPACE。這個 Value 就可以隨意取名，例如 my-app。

  4. 下一步，再回到 Project manifests，一樣進入 Web IDE，我們要修改 helmfile.yaml，修改完畢將 Commit 送進 master branch。（因為是用 Project template 建立的，因此跟著 Template 源頭仍使用 master 而非 main branch。）

    （將第 19、20、22 行的註解取消，即是我們希望能在 K8s 上架設 ingress、cert-manager 與 prometheus。）

  5. 查看 Project manifests 的 CI/CD > Pipelines，驗證是否有正確執行 Pipeline。

    （正常來說，Job diff 會自動執行完畢，且是綠燈的狀態。）

    接著按下 Job sync 的 Play。

    （按下 Play，確實透過 Pipeline 自動幫我們在 K8s Cluster 上架設 ingress、cert-manager 與 prometheus。）

    當 Pipeline 跑完後，你可以在 Terminal 執行指令 kubectl get pods --all-namespaces，會發現多了幾個新的 Pods。

    （應該會出現帶有 ingress、certmanager、prometheus 名稱的 Pods）

取得 EXTERNAL-IP 並設置 Base domain

  1. 執行下述指令，取得後續需要的 EXTERNAL-IP。

    kubectl --namespace gitlab-managed-apps get services -o wide -w ingress-ingress-nginx-controller

    （應該會如上圖，可以取得 ingress 的資訊，其中有我們需要的 EXTERNAL-IP。）

  2. 回到 Group demo，一樣去 Settings > CI/CD > Variables 設置 1 個新的 Variable。

    Variable KUBE_INGRESS_BASE_DOMAIN。

    這裡我們使用 nip.io 來當作我們的 Base domain，因此 Value 請輸入 EXTERNAL-IP + .nip.io。

    （如圖，我們使用免費的 nip.io 來當我們的 Base domain。nip.io 是一個當你想要做 DEMO 或 Labs，但又不想自己先採購與設定網域時，可以利用的免費服務，詳情你可以參閱 nip.io 的網站說明。）

開始試玩 Auto DevOps

當你完成前面的所有步驟之後，你就順利在 Group demo 內準備了一個可以開始牛刀小試 Auto DevOps 的環境。

接下來請繼續參閱《和艦長一起 30 天玩轉 GitLab》（第二版）的第六章，書中會帶著讀者使用 GitLab 官方準備好的 Project Template 建立 Project，並為 Project 啟用 Auto DevOps。

要特別注意的是，任何你想要跟著第六章試用 Auto DevOps 的 Project，都必須歸屬在 Group demo 之下，因為只有在這個 Group 內的 Project 才能透過 CI/CD Tunnel 及 K8s Agent，順利 Connect K8s 完成 Auto DevOps Pipeline 中的各項 Job。

← GitLab CI Lab 環境建置步驟
GitLab 15.7 用 VS Code 取代舊有的 Web IDE，大幅影響本書 3-3-5 →