新手也能懂的Cloud Build教學：10 分鐘上手第一個自動化部署流程

在現代軟體開發的生命週期中，持續整合（Continuous Integration, CI）與持續部署（Continuous Deployment, CD）是提升開發效率、確保程式碼品質與加速產品交付的核心實踐。然而，維護一套穩定、高效能的CI/CD系統往往需要投入大量的時間與資源來設定、管理和擴展底層的建置伺服器infrastructure。

為了解決這個痛點，Google Cloud推出了Cloud Build——一個全代管、無伺服器（Serverless）的CI/CD平台。它讓開發團隊可以完全專注於撰寫程式碼，而將建構、測試、打包與部署等繁瑣的自動化部署流程任務交由Google Cloud強大且穩定的基礎設施來處理。無論您是想將您的應用程式容器化、執行單元測試、掃描安全漏洞，或是自動部署到Cloud Run、Google Kubernetes Engine (GKE) 等環境，Cloud Build都能提供極大的彈性與便利性。

本篇文章將帶您從零開始，深入淺出地探索Cloud Build的強大功能。我們將從最基礎的本地端手動觸發開始，逐步引導您建立一套由Git事件驅動、完全自動化的CI/CD工作流，並解析其背後的運作原理與最佳實踐。

Cloud Build 核心概念與優勢

在深入實作之前，讓我們先了解Cloud Build為何能成為雲端原生開發中不可或缺的工具。其核心優勢可歸納如下：

優勢	說明
無伺服器與可擴展性	Cloud Build是一個完全無伺服器的服務，您無須預先配置、管理或升級任何建置機器。它會根據您的建置需求自動擴展與縮減資源，並行處理數百個建置任務也輕而易舉。
原生生態系整合	與Google Cloud生態系完美整合，可輕易部署至Cloud Run、GKE、App Engine、Cloud Functions等服務。同時原生支援GitHub、GitLab、Bitbucket與Cloud Source Repositories等主流原始碼託管服務（包含企業版）。
企業級安全性與AI	內建強大的安全功能，可自動掃描容器映像檔和語言套件中的安全漏洞。支援SLSA Level 3法規遵循，產生可驗證的建構來源證明，防止軟體供應鏈攻擊。搭配Binary Authorization，可確保只有受信任且經過驗證的映像檔能在您的環境中部署。AI技術也逐漸融入，提升安全性分析的精準度。
高效能建置	運用Google的全球高速網路與高效能虛擬機（VM），大幅縮短建置時間。支援快取常用的原始碼、映像檔或其他依賴項（例如儲存在Google Cloud Storage），進一步提升建置速度。
靈活的建置環境	提供預設集區 (Default Pools) 讓建置作業在安全的託管環境中執行，並可存取公開網際網路。同時提供私有集區 (Private Pools)，讓您在自己的VPC私有網路中執行建置，存取內部資源，並滿足更高的法規遵循與安全性需求。

初試啼聲：從本地端手動觸發建置

萬事起頭難，讓我們先從最簡單的情境開始：在您的本機電腦上，透過gcloud指令工具手動觸發一次Cloud Build建置任務，來建立一個Hello World範例。

事前準備

1. 安裝Google Cloud SDK：確保您的開發環境已安裝並設定好gcloud指令列工具。
2. 建立GCP專案：在Google Cloud控制台中建立一個新的專案，並記下您的專案ID (Project ID)。
3. 啟用必要的API：在您的專案中，務必啟用Cloud Build API和Artifact Registry API。Artifact Registry是Google Cloud建議用來儲存及管理容器映像檔等建構產物的服務。

步驟一：準備原始碼與Dockerfile

首先，我們在本機建立一個簡單的專案資料夾，並包含一個shell腳本和一個Dockerfile。

1. 建立一個名為gcp-build-test的資料夾並進入該目錄。
2. 新增一個名為quickstart.sh的檔案，內容如下：
   sh #!/bin/sh echo “Hello, Cloud Build! The time is $(date).”
3. 賦予此quickstart.sh腳本執行權限：
   bash chmod +x quickstart.sh
   這個chmod x quickstart.sh指令非常重要，確保了腳本在容器內是可執行的。
4. 新增一個名為Dockerfile的檔案，內容如下：
   dockerfile # 使用輕量的 Alpine Linux 作為基礎映像檔 FROM alpine # 將 quickstart.sh 複製到映像檔的根目錄 COPY quickstart.sh / # 設定容器啟動時要執行的命令 CMD [“/quickstart.sh“]

步驟二：建立 Artifact Registry 存放庫

我們需要一個地方來存放由Cloud Build建置好的容器映像檔。執行以下指令來建立一個Docker格式的存放庫：

gcloud artifacts repositories create my-docker-repo \
    --repository-format=docker \
    --location=asia-east1 \
    --description="My first Docker repository"

• –location: 指定存放庫所在的地理區域，例如asia-east1 (台灣)。

步驟三：執行建置任務

Cloud Build提供兩種主要的手動觸發方式：

方法一：直接使用Dockerfile進行建置

如果您的建置流程很單純，只有一個Dockerfile，可以直接執行以下指令：

# 請將 [PROJECT_ID] 替換為您自己的專案 ID
gcloud builds submit --tag asia-east1-docker.pkg.dev/[PROJECT_ID]/my-docker-repo/quickstart-image:v1 .

• –tag: 指定建置完成後映像檔的完整名稱與標籤(tag)。其格式為：LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME:TAG，這也常被寫為region-docker.pkg.dev。
• .: 代表使用目前所在目錄作為建置的上下文(context) of the source code。

Cloud Build會將您本地的檔案打包上傳，在雲端執行Docker build，並將名為quickstart-image:v1的映像檔推送到您指定的Artifact Registry存放庫。

方法二：使用 cloudbuild.yaml 設定檔

對於更複雜的建置流程（例如：包含測試、多步驟建置），使用cloudbuild.yaml設定檔是更靈活、更標準的做法。

1. 在專案根目錄下，建立一個名為cloudbuild.yaml的檔案，這是一個YAML檔案：

   “`yaml
   steps:

   第一個步驟：執行 Docker build

   • name: ‘gcr.io/cloud-builders/docker’
     args: [ ‘build’, ‘-t’, ‘asia-east1-docker.pkg.dev/$PROJECT_ID/my-docker-repo/quickstart-image:v2’, ‘.’ ]

   建置完成後，要推送到 Artifact Registry 的映像檔列表

   images:
   – ‘asia-east1-docker.pkg.dev/$PROJECT_ID/my-docker-repo/quickstart-image:v2’
   “`

   • steps: 定義了一系列的建置步驟。每個步驟都會在一個獨立的容器環境中執行。
   • name: 指定了這個步驟要使用的建置工具(Builder)，gcr.io/cloud-builders/docker是Google提供的官方Docker建置工具。
   • args: 傳遞給建置工具的參數，這裡就是docker build …的指令參數。
   • $PROJECT_ID: 這是Cloud Build提供的內建替代變數，執行時會自動替換為您的專案ID。
   • images: 告訴Cloud Build在所有步驟成功後，將哪些映像檔推送到Artifact Registry。例如gcr.io/project_id/quickstart-image這樣的格式。
2. 執行建置：

   bash gcloud builds submit –config cloudbuild.yaml .

步驟四：驗證成果

前往Google Cloud控制台，您可以在Cloud Build > 記錄頁面看到剛剛兩次建置的詳細日誌。在Artifact Registry > 存放庫頁面，點擊my-docker-repo，您會看到quickstart-image以及v1和v2兩個標籤，代表映像檔已成功儲存。

邁向自動化：打造解構式 CI/CD 工作流

手動建置雖然簡單，但真正的威力在於自動化。接下來，我們將設計一個更進階、更貼近實務的自動化部署流程：將建置（Build）和部署（Deploy）階段分離。當開發者推送程式碼到GitHub時，自動觸發「建構」流程；當新的映像檔建置完成後，再自動觸發「部署」流程。

為何要分離建置與部署？

將CI (建置/測試)和CD (部署)分離成兩個獨立的流程，可以帶來許多好處：

好處	說明
流程清晰，職責分離	每個階段專注於單一職責，讓整個工作流更清晰、更容易管理與除錯。
提升安全性	可以在兩個階段之間加入手動審批步驟（例如在Pull Request中），或針對部署階段設定更嚴格的權限控管。
可擴展性與可重用性	建置好的產物（映像檔）可以被多個不同的部署流程使用，例如部署到開發、預備、生產等多個環境。
獨立測試與調試	可以獨立測試建置流程或部署流程，而不會互相影響，簡化了問題排查的複雜度。

流程架構

我們的自動化工作流架構如下：

1. 開發者 將程式碼變更push到GitHub的main分支。
2. Cloud Build Trigger (Build) 監聽到push事件，觸發build.cloudbuild.yaml。
3. Cloud Build Job (Build) 執行建置、測試，並將新的容器映像檔推送到Artifact Registry。
4. Artifact Registry 自動發布一則訊息到一個名為gcr的Pub/Sub主題(Topic)。
5. Cloud Build Trigger (Deploy) 訂閱了gcr主題，收到新映像檔的訊息後，觸發deploy.cloudbuild.yaml。
6. Cloud Build Job (Deploy) 執行部署指令，將新的映像檔部署到Cloud Run服務。

階段一：自動化建置與推送 (Git Trigger)

1. 連結GitHub儲存庫：
   • 在Cloud Build控制台的觸發器頁面，連接您的GitHub帳號並授權Google Cloud存取您的儲存庫。
2. 建立 build.cloudbuild.yaml：
   在您的專案中建立此檔案，內容專注於建置與推送。

   “`yaml

   build.cloudbuild.yaml

   steps:

   可以在這裡加入單元測試、程式碼風格檢查等步驟

   – name: ‘…’

   args: [‘npm’, ‘test’]

   步驟：建置容器映像檔

   • name: ‘gcr.io/cloud-builders/docker’
     id: ‘Build Docker Image’
     args:
     • ‘build’
     • ‘-t’
     • ‘asia-east1-docker.pkg.dev/PROJECT_ID/my-docker-repo/my-app:{SHORT_SHA}’
     • ‘.’

   步驟完成後，要推送的映像檔

   images:
   – ‘asia-east1-docker.pkg.dev/PROJECT_ID/my-docker-repo/my-app:{SHORT_SHA}’

   選項：可以為建置任務指定更高的 CPU 或記憶體

   options:
   machineType: ‘E2_HIGHCPU_8’
   “`

   • id: 為步驟指定一個唯一的ID，方便在日誌中識別。
   • ${SHORT_SHA}: 另一個內建替代變數，代表觸發這次建置的Git commit SHA值（短版），非常適合用來當作映像檔的唯一標籤。
   • options.machineType: 您可以選擇不同的機器規格來加速建置。
3. 建立建置觸發器：
   • 在Cloud Build控制台建立一個新的觸發器。
   • 事件: 選擇推送至分支。
   • 來源: 選擇您剛連結的GitHub儲存庫。
   • 分支: 輸入^main$ (使用正規表示式精確匹配main分支)。
   • 設定: 選擇Cloud Build設定檔，並將路徑指向build.cloudbuild.yaml。

現在，只要有任何程式碼合併到main分支，使用Cloud Build的觸發器就會自動執行建置流程。

階段二：事件驅動的自動化部署 (Pub/Sub Trigger)

1. 了解 gcr Pub/Sub 主題：
   當您在專案中啟用Artifact Registry API時，GCP會自動建立一個名為gcr的Pub/Sub主題。每當有任何映像檔被推送、標記或刪除時，Artifact Registry都會向此主題發布一則包含詳細資訊的JSON訊息。這是實現事件驅動部署的關鍵。
2. 建立 deploy.cloudbuild.yaml：
   此檔案專注於部署任務。

   “`yaml

   deploy.cloudbuild.yaml

   steps:
   – name: ‘gcr.io/google.com/cloudsdktool/cloud-sdk’
   id: ‘Deploy to Cloud Run’
   entrypoint: gcloud
   args:
   – ‘run’
   – ‘deploy’
   – ‘my-serverless-app’ # 您的 Cloud Run 服務名稱
   – ‘–image=${_IMAGE_NAME}’ # 從觸發器傳入的變數
   – ‘–region=asia-east1’
   – ‘–project=${PROJECT_ID}’
   – ‘–allow-unauthenticated’
   “`

   • gcr.io/google.com/cloudsdktool/cloud-sdk: 這是包含了gcloud, kubectl, gsutil等工具的官方建置器。
   • entrypoint: 覆寫預設的進入點，直接使用gcloud指令。
   • IMAGENAME: 這是一個使用者自定義的替代變數。我們將在觸發器設定中，從Pub/Sub訊息裡提取映像檔名稱並賦值給它。
3. 建立部署觸發器：
   • 再次建立一個新的觸發器。
   • 事件: 選擇Pub/Sub訊息。
   • 訂閱: 選擇gcr主題。GCP會為您自動建立一個訂閱。
   • 設定: 指向deploy.cloudbuild.yaml。
   • 替代變數(最關鍵的一步):
     • 新增一個變數_IMAGE_NAME，其值設為$(body.jsonPayload.name)。這會從Pub/Sub訊息的JSON內文的data中，提取name欄位的值。
   • 篩選器(Filter): 為了避免映像檔被刪除時也觸發部署，我們需要加入篩選條件。
     • body.jsonPayload.action == “INSERT”
       這條規則使用CEL (Common Expression Language)語法，確保只有在action為INSERT (即新映像檔推送)時，才執行此觸發器。

完成以上設定後，您就擁有了一套完整、解構且自動化的CI/CD工作流。

常見問題 (FAQ)

Q1: Cloud Build的費用如何計算？

A: Cloud Build提供了一個相當慷慨的免費方案，每月包含2,500分鐘的免費建置時間。超出免費額度的部分，會根據您使用的機器類型和建置時間（以分鐘為單位）來收費。建置任務在佇列中等待的時間不計費。

Q2: 如何提升Cloud Build的建置速度？

A: 有多種方法可以加速建置：

1. 快取(Caching): 對於不常變動的依賴項（如Node.js的node_modules或Java的.m2），可以將其快取到Google Cloud Storage，下次建置時直接取用。
2. 選擇高效能機器: 在cloudbuild.yaml的options中，將machineType設定為E2_HIGHCPU或N1_HIGHCPU系列的VM。
3. 使用私有集區: 私有集區可以提供更高的並行建置數量，並減少因等待公用資源而產生的延遲。

Q3: Cloud Build和Jenkins或GitLab CI有什麼不同？

A: 最大的不同在於Cloud Build是全代管的無伺服器平台，您完全不需要管理底層主機。這大大降低了維運成本。而Jenkins或GitLab CI通常需要自行架設和維護，但相對地可能提供更深度的客製化彈性。Cloud Build的另一大優勢是與GCP生態系的深度整合。

Q4: 我必須使用Docker才能用Cloud Build嗎？

A: 完全不用。雖然Cloud Build在容器化工作流中非常普及，但它本質上是一個通用的任務執行器。您可以透過gcr.io/cloud-builders/*系列的建置工具來執行幾乎任何指令，例如使用npm來打包前端專案、使用gcloud來部署無伺服器功能，或使用terraform來管理基礎設施即程式碼(IaC)，整個過程可以完全不涉及Docker。

Q5: Artifact Registry和Container Registry有什麼關係？

A: Artifact Registry是Google Cloud推薦的下一代建構產物管理服務，可視為Container Registry的進化版。Container Registry僅支援Docker映像檔，而Artifact Registry則支援多種格式（如Docker, Maven, npm, Python等），並提供更強大的功能，如區域性存放庫、更細緻的IAM權限控管。新專案應優先考慮使用Artifact Registry。

總結

Cloud Build不僅僅是一個建置工具，它是一個強大且靈活的自動化平台，是實踐DevOps文化、加速軟體交付週期的利器。透過本文的引導，我們從最基礎的本地端指令，一路探索到結合Git、Pub/Sub與Cloud Run的全自動化、事件驅動的CI/CD流程。我們理解了分離建置與部署的優勢，並學會了如何利用觸發器、替代變數與篩選器來客製化我們的自動化邏輯。

這套架構不僅具備高擴展性，還能輕易地加入更多功能，例如在部署到生產環境前，先自動部署到預備環境進行整合測試；或是在建置流程中整合SonarQube進行靜態程式碼分析等。Cloud Build為您的團隊提供了無限的可能性，讓您能更專注於創造商業價值，而非耗費心力在維運工作上。

資料來源

• Google Cloud Build 教學(一) — 透過本地端完成GCP …
• 使用Cloud Build 打造無伺服器服務的自動化部署流程
• Cloud Build serverless CI/CD platform