使用 Cloud Build 打造無伺服器服務的自動化部署流程

#GCP手把手教學

本篇文章將帶您來看如何自動建置、推送和部署無伺服器服務至 Cloud Run。

首先，您已經準備好將一個嶄新的應用程式部署到雲端。經過一番研究，您決定使用無伺服器 (Serverless) 的服務 Cloud Run 和 Cloud Build 來建置 (Build) 並推送 (Push) 容器化的應用程式至 Artifact Registry。利用 Dockerfile 和 Cloud Build 設定檔，您在以下這三個步驟中建置您的容器映象檔 (container image)、將其推送至 Artifact Registry，再部署到 Cloud Run。以下是 cloudbuild.yaml 之範例：

YAML 設定檔範例（一）：建置、推送、部署步驟結合

1steps:
2# Build the container image
3- name: 'gcr.io/cloud-builders/docker'
4  args: ['build', '-t', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '.']
5
6# Push the container image to Artifact Registry
7- name: 'gcr.io/cloud-builders/docker'
8  args: ['push', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app']
9
10# Deploy container image to Cloud Run
11- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
12  entrypoint: gcloud
13  args: ['run', 'deploy', 'my-serverless-app', '--image', 'us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app', '--region', 'us-central1']
14
15images:
16- us-central1-docker.pkg.dev/my-project/my-app-repo/shiny-new-app

以上的範例將建置、推送和部署步驟結合成一個 Cloud Build 工作。

本文將首先介紹手動部署無伺服器服務的流程，隨後說明如何將其發展成自動部署的流程，作為更複雜解決方案的起點。我們將使用到 Google Cloud 的 Cloud Build、Artifact Registry、Pub/Sub 和 Cloud Run 服務。

手動部署流程

圖（一）：手動部署流程圖

讓我們先檢視如何手動部署容器化應用程式到 Cloud Run：

首先，需要對應用程式原始碼進行更改並將其合併到您的儲存庫 (Repository) 的主分支 (main branch) 中。
當應用程式變更合併後，使用 Cloud Build 建立一個新的容器映象檔。
建置成功後，Cloud Build 將新建立的容器映象檔推送到 Artifact Registry。
更新 Cloud Run 的配置以指向新的容器映象檔。
Cloud Run 部署服務的新版本，便完成新原始碼的部署。

每當應用程式原始碼有更改時，您都需要進行這些步驟。這對於一個需要持續更新原始碼的團隊來說並不可行，也可能變成後勤團隊的噩夢。更不用提多個環境中的分段部署、整合系統化測試 (systematic testing) 或增量部署 (incremental rollouts) 所增加的複雜度。

讓我們將這個部署流程自動化，並將其視為兩部分：建置和部署。

建置自動化

圖（二）：建置自動化流程圖

為了自動化您的部署流程中的「建置」步驟，Cloud Build 將會在您提交 (commit) 原始碼的更動至儲存庫時，自動進行建置和推送。

以下是需要完成的步驟：

將您的 GitHub 儲存庫與 Cloud 專案連接起來：當您將 GitHub 儲存庫連接至專案後，Cloud Build 就可以使用儲存庫事件來觸發 Cloud Build Trigger。Cloud Build 支援多種常見的儲存庫事件，例如推送至特定分支、推送新的 tag 或建立 pull request。
在您的儲存庫中加入 Cloud Build 的 YAML 設定檔：您可以使用建置設定檔 (config file) 來設定 Cloud Build 工作，這個 YAML 檔案可以提供任務級別的指示給 Cloud Build。這個檔案可以和您的應用程式 Dockerfile 放在一起，或者在儲存庫的其他目錄中。在自動建置時，您的設定檔會告訴 Cloud Build 建立容器映像並將其推送至 Artifact Registry。
建立 Cloud Build Trigger：當您的主分支有新的更動被推送時，Cloud Build Trigger 就會被觸發。您需要設定這個 Trigger：提供要連接至 Google Cloud 專案的 GitHub 儲存庫、指定分支名稱以及 步驟2. 中建立之 Cloud Build 設定檔的路徑。您也可以指定要包含或忽略的檔案和目錄，使得只有特定檔案發生更改時才會啟動新的建置。

YAML 設定檔範例（二）：建置、推送步驟

1steps:
2  # Docker Build 
3  - name: 'gcr.io/cloud-builders/docker'
4    args: 
5      - 'build'
6      - '-t'
7      - '${_REGION}-docker.pkg.dev/${PROJECT_ID}/content-api/content-api:${_IMAGE_TAG}'
8
9# Default to us-central1
10substitutions:
11  _REGION: us-central1
12  _IMAGE_TAG: $SHORT_SHA
13
14# Store in Artifact Registry
15images:
16  - '${_REGION}-docker.pkg.dev/${PROJECT_ID}/content-api/content-api:${_IMAGE_TAG}'

這些下底線 (_) 前綴的變數可以使用配置 Cloud Build Trigger 時提供的值。在上面的範例中，_REGION 可以被覆蓋，即使容器庫移動到新的位置，也無須更改此設定檔。沒有下底線的替換變數（如 $PROJECT_ID）是內建的，其值由 Cloud Build 提供。您可以參考內建的替換變數列表。

若您需要使用單個 Cloud Build 設定檔，建立多個具有相似功能的 Trigger，使用這些變數將會非常方便。

部署自動化

圖（三）：部署自動化流程圖

自動化的部署流程中，我們希望 Cloud Run 服務可以自動更新。因此，需要有一種方法告知 Cloud Run 新的建置版本已經可用，才能實現自動化更新。本段落將透過 Pub/Sub 和另一個 Cloud Build Trigger，實現自動化更新。

以下是需要完成的步驟：

1. “gcr” Pub/Sub 主題 (Topic)

如果您在您的 Google Cloud 專案建立名為 “gcr” 的 Pub/Sub 主題，Artifact Registry 將會發布儲存庫的相關變更至 “gcr” Pub/Sub 主題：當每次推送、標記或刪除映像檔到儲存庫時，就會發布一個訊息。這些訊息可以透過相應的 Pub/Sub 訂閱 (Subscription) 傳送到您的應用程式，或是在本文的案例中，觸發 Cloud Build Trigger。

2. 創建另一個 Cloud Build Trigger

設定另一個 Cloud Build Trigger，以部署 Cloud Run 服務的新版本。除了能被儲存庫事件觸發以外，Cloud Build Trigger 也能被 Pub/Sub 事件觸發。您可以選擇 “gcr” Pub/Sub 主題作為觸發事件，當 Artifact Registry 向 Pub/Sub 發布訊息時，您的 Cloud Run 服務就會自動更新。

雖然您可以只用一個單獨的 Cloud Build Trigger 來建置、推送和部署。但將部署與建置、推送獨立出來，可以讓每個階段運行於獨立的 Cloud Build 工作，並且更容易獨立開發流程中的每個部分。

YAML 設定檔範例（三）：建置、推送、部署步驟結合

1steps:
2  # Print the full Pub/Sub message for debugging.
3  - name: gcr.io/cloud-builders/gcloud
4    entrypoint: /bin/bash
5    args:
6      - '-c'
7      - |
8        echo ${_BODY}
9  # Cloud Run Deploy
10  - name: gcr.io/cloud-builders/gcloud
11    args:
12      - run
13      - deploy
14      - ${_SERVICE}
15      - --image=${_IMAGE_NAME}
16      - --region=${_REGION}
17      - --revision-suffix=${_REVISION}
18      - --project=${_TARGET_PROJECT}
19      - --allow-unauthenticated

上面這個設定檔再次使用了變數，這些變數的值將由配置 Trigger 時的替換變數設定提供，如下圖（四）。特定變數的值，例如 _BODY、_IMAGE_NAME 和 _REVISION，是使用從 “gcr” Pub/Sub 主題收到的訊息指定的，而其他值則是於替換變數中設定：

圖（四）：Trigger 配置之替換變數設定

結語

這個自動化流程的價值不僅在於它的簡單性，更在於它能被進一步開發以支援更多功能。例如在不同的 Google Cloud 專案中標記變更、加入每次應用程式變更的自動化測試，或者在 Cloud Run 服務中進行增量佈署等。這些都可以透過加入額外的 Cloud Build Trigger 和 Pub/Sub 主題實現。

另外，Cloud Deploy 近期也開始支援 Cloud Run，可完整佈署到 Cloud Run 的目標，並包括 Rollback、Approval、Audit 和 Delivery metrics 等功能。

文章編譯：Elsie Juan／ Interested in application and infrastructure modernization

本文改寫自此篇文章：Building an automated serverless deployment pipeline with Cloud Build | Google Cloud Blog