iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 28
0
DevOps

誤入 DevOps 叢林的後端工程師系列 第 28

Day28 - 透過 Cloud Build 自動部署到 GKE

前一篇我們已經完成 75% 的前置動作,就差 cloud build 幫我們把最新的映像檔部署到 GKE 服務對吧,這部分也非常簡便,我們在建構步驟中,加一段 kubectl 的 deploy 指令就可以了。

呼叫 kubectl 來更新部署資源的步驟

語法

steps:
  - name: 'gcr.io/cloud-builders/kubectl'
    args:
    - set
    - image
    - deployment
    - [DEPLOYMENT-NAME]
    - [CONTAINER]=gcr.io/[PROJECT-ID]/[IMAGE]:[TAG]
    env:
    - 'CLOUDSDK_COMPUTE_ZONE=[COMPUTE-ZONE]'
    - 'CLOUDSDK_CONTAINER_CLUSTER=[CLUSTER]'

上面有五個變數要依據實際情況替換掉

  • PROJECT-ID:GCP 專案的專案 ID
  • IMAGE,映像檔的名稱及 TAG
  • CLUSTER:叢集名稱,例如 k8s-cluster
  • COMPUTE-ZONE:指定的區域,例如 asia-east1-a
  • DEPLOYMENT-NAME:部署資源名稱,例如api-deployment

實際使用情況

steps:
  - name: 'gcr.io/cloud-builders/kubectl'
    args:
      - set
      - image
      - deployment
      - api-deployment
      - api-server=gcr.io/$PROJECT_ID/api-server:ci-$_NODE_ENV-$SHORT_SHA
    env:
      - 'CLOUDSDK_COMPUTE_ZONE=asia-east1-a'
      - 'CLOUDSDK_CONTAINER_CLUSTER=k8s-cluster'

如果專案是走 github flow 的開發模式,只有一條 master 分支,通常你不會希望程式碼 merge 進 master 就觸發自動部署的程序。又或者 production 環境的建置步驟跟 beta 環境的建構步驟差異太大,我們可以直接維護兩份檔案,例如 cloudbuild-beta.yamlcloudbuild-prod.yaml。cloudbuild-beta.yaml 設定下面這段自動部署的步驟,cloudbuild-prod.yaml 的部分則不設定也是可以。

如果專案是走 git flow 的開發模式的話,就更簡單控制,共用 cloudbuild.yaml 一個觸發點設定在 master 分支更新時,另一個觸發點設定在 develop 分支更新時,就可以了。基本上步驟 (steps) 都可以你的實用情境自行調整,這部分有很大的彈性。

資料來源 / 延伸閱讀


上一篇
Day27 - 用 Cloud Build 實作 CI 部分
下一篇
Day29 - GCP 與 MongoDB Cloud
系列文
誤入 DevOps 叢林的後端工程師30

尚未有邦友留言

立即登入留言