設定 CI/CD，以儲存 Terraform 程式碼即設定

本教學課程說明如何使用熱門的 GitOps 方法，透過 Terraform 和 Cloud Build 以程式碼的形式管理基礎架構。GitOps 一詞最初是由 Weaveworks 所提出，其主要概念是使用 Git 存放區儲存所需的環境狀態。Terraform 是 HashiCorp 的開放原始碼工具，可讓您透過程式碼，以可預測的方式建立、變更及改善雲端基礎架構。在本教學課程中，您將使用Cloud Build (持續整合服務) 自動將 Terraform 資訊清單套用至環境。 Google Cloud

本教學課程適用於正在尋找一流的策略，以便以可預測的方式變更基礎架構的開發人員和操作人員。本文假設您熟悉 Google Cloud和 Linux。

《DevOps 現狀》報告指出，有幾項能力可提升軟體推送效能。本教學課程將協助您瞭解下列功能：

• 版本管控
• 持續整合
• 持續推送軟體更新
• 持續測試

架構

本教學課程會運用 GitOps 做法管理 Terraform 執行作業。請注意，這個範例使用 Secure Source Manager 分支版本 dev 和 prod 代表實際環境。這些環境分別由Google Cloud 專案中的虛擬私有雲 (VPC) 網路 dev 和 prod 定義。

將 Terraform 程式碼推送至 dev 或 prod 分支時，程序就會啟動。在這個情境中，Cloud Build 會觸發並套用 Terraform 資訊清單，在相應環境中達成所需狀態。另一方面，當您將 Terraform 程式碼推送至任何其他分支版本 (例如功能分支版本) 時，Cloud Build 會執行 terraform plan，但不會套用至任何環境。

理想情況下，開發人員或營運商必須向開發或功能分支機構提出基礎架構提案，然後透過提取要求提交提案。如此一來，您就可以在系統將變更合併至基本分支版本之前先和協作者討論及審查可能的變更，以及加入後續修訂版本。

如果沒有任何問題，請先將變更合併至 dev 分支版本。這項合併作業會觸發基礎架構部署至dev環境，方便您測試這個環境。測試完成並確認部署內容後，您必須將 dev 分支合併至 prod 分支，觸發基礎架構安裝程序，將內容部署至正式環境。

目標

• 設定 Secure Source Manager 執行個體和存放區。
• 設定 Terraform，將狀態儲存在 Cloud Storage bucket 中。
• 將權限授予您的 Cloud Build 服務帳戶。
• 將 Cloud Build 連結至 Secure Source Manager 存放區。
• 在功能分支版本中變更您的環境設定。
• 將變更推行至開發環境。
• 將變更推送至正式環境。

費用

在本文件中，您將使用下列 Google Cloud計費元件：

• Cloud Build
• Cloud Storage
• Compute Engine

您可以使用 Pricing Calculator，根據預測用量估算費用。

初次使用 Google Cloud 的使用者可能符合免費試用期資格。

完成本文所述工作後，您可以刪除建立的資源，避免繼續計費，詳情請參閱「清除所用資源」。

事前準備

登入 Google Cloud 帳戶。如果您是 Google Cloud新手，歡迎 建立帳戶，親自體驗產品的實際應用成效。新客戶還能獲得價值 $300 美元的免費抵免額，能用於執行、測試及部署工作負載。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. 在 Google Cloud 控制台中啟用 Cloud Shell。

   啟用 Cloud Shell

   Google Cloud 控制台底部會開啟 Cloud Shell 工作階段，並顯示指令列提示。Cloud Shell 是已安裝 Google Cloud CLI 的殼層環境，並已設定適用於您目前專案的值。工作階段可能要幾秒鐘的時間才能初始化。

2. 在 Cloud Shell 中，取得您剛剛選取的專案的 ID：

   gcloud config get-value project

   如果這個指令未傳回專案 ID，請設定 Cloud Shell 使用您的專案。將 PROJECT_ID 替換為專案 ID。

   gcloud config set project PROJECT_ID

3. 啟用所需的 API：

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   這個步驟可能需要幾分鐘才能完成。
4. 如果您從未在 Cloud Shell 中使用過 Git，請使用您的姓名和電子郵件地址進行設定：

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   日後您在 Cloud Shell 建立修訂版本時，Git 會使用這些資訊指出您是作者。

設定 Secure Source Manager 存放區

在本教學課程中，您將使用單一 Secure Source Manager 存放區定義雲端基礎架構。您可透過對應不同環境的不同分支，協調這項基礎架構：

• dev 分支版本包含套用至開發環境的最新變更。
• prod 分支版本包含套用至正式環境的最新變更。
• 類似 feature_x 的功能分支版本可用於進行變更，然後再推送至 dev 或 prod 分支版本。

有了這個基礎架構，您隨時可以參考存放區，瞭解每個環境預期的設定，並先將新變更合併至 dev 環境，藉此提出新變更。接著，您將 dev 分支版本合併至後續的 prod 分支版本，藉此推送變更。

1. 建立空的 Secure Source Manager 存放區，但請勿初始化存放區。

2. 執行下列指令，將 Secure Source Manager 驗證輔助程式新增至全域 git config：

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   使用 Secure Source Manager 執行 Git 指令時，驗證輔助程式會透過 gcloud CLI 擷取您的Google Cloud 憑證。

3. 如要在初始憑證設定後重新驗證，請執行下列 gcloud CLI 指令：

   gcloud auth login
   

4. 將 solutions-terraform-cloudbuild-gitops 存放區複製到本機殼層或工作環境：

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. 將 Secure Source Manager 存放區新增為上游。

   git remote add google HTTPS_REPO_URL
   

   其中 HTTPS_REP_URL 是 Secure Source Manager 存放區的 HTTPS 網址。您可以在 Secure Source Manager 網頁介面的存放區頁面頂端找到網址。

6. 建立並切換至 dev 分支。

   git checkout dev
   

7. 使用下列指令，將複製的存放區推送至您的存放區：

   git push -u google --all
   

8. 對 prod 分支重複執行前兩個步驟。

這個存放區中的程式碼結構如下：

• environments/ 資料夾包含代表環境的子資料夾，例如 dev 和 prod，分別在成熟度、開發和生產的不同階段，提供工作負載之間的邏輯分隔。雖然建議盡可能讓這些環境相似，但每個子資料夾都有自己的 Terraform 設定，確保可以視需要使用專屬設定。

• modules/ 資料夾包含內嵌 Terraform 模組。這些模組代表相關資源的邏輯群組，可用於跨不同環境共用程式碼。

• cloudbuild.yaml 檔案是建構設定檔，內含 Cloud Build 的操作說明，例如如何根據一組步驟執行工作。這個檔案會根據 Cloud Build 擷取程式碼的來源分支版本來指定條件式執行作業，例如：

  • 對於 dev 和 prod 分支，系統會執行下列步驟：

    1. terraform init
    2. terraform plan
    3. terraform apply

  • 如果是任何其他分支版本，系統會執行以下步驟：

    1. 所有 environments 子資料夾的 terraform init
    2. 所有 environments 子資料夾的 terraform plan

為確保建議的變更適用於所有環境，系統會針對所有 environments 子資料夾執行 terraform init 和 terraform plan。合併提取要求前，您可以查看計畫，確保未經授權的實體不會取得存取權。

修改建構設定檔

如要讓範例建構設定檔與 Secure Source Manager 搭配運作，請進行下列編輯：

• 新增複製存放區的步驟。
• 新增步驟以取得分支名稱，並指派給變數。

編輯 dev 分支版本中的建構設定檔：

1. 切換至 dev 分支版本：

   git checkout dev
   

2. 開啟 cloudbuild.yaml 檔案，並將內容替換為下列程式碼：

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. 確認檔案已修改。

   git status
   

4. 修訂並推送變更：

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. 開啟提取要求，即可快速將變更升級至 prod 分支。

   1. 在 Secure Source Manager 網頁介面中，前往存放區。
   2. 按一下「提取要求」分頁標籤。
   3. 按一下 [New pull request] (新的提取要求)。
   4. 在「merge into:」欄位中，選取 prod 分支版本。
   5. 在「pull from:」(從以下位置提取) 欄位中，選取 dev 分支。
   6. 檢查變更，然後按一下「New pull request」(新提取要求)。
   7. 按一下「建立提取要求」。
   8. 按一下「Merge pull request」(合併提取要求)。

   9. 再次點選「Merge pull request」。

      變更會合併至 prod 分支版本。

設定 Terraform，將狀態儲存在 Cloud Storage bucket

根據預設，Terraform 會將狀態儲存在本機名為 terraform.tfstate 的檔案中。這個預設設定可能會讓團隊難以使用 Terraform，尤其是在許多使用者同時執行 Terraform 時，每部電腦對目前基礎架構的瞭解程度不盡相同。

為避免這類問題，本節會設定指向 Cloud Storage bucket 的遠端狀態。遠端狀態是後端的一項功能，在本教學課程中，您會在 backend.tf 檔案中設定這項功能，例如：

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

在下列步驟中，您將建立 Cloud Storage bucket，並變更幾個檔案，指向新的 bucket 和 Google Cloud 專案。

1. 在 Cloud Shell 中建立 Cloud Storage bucket：

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

2. 啟用物件版本管理功能，保留部署作業的歷史記錄：

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

   啟用物件版本管理功能會增加儲存費用，但您可以設定物件生命週期管理功能，刪除舊版狀態版本，藉此降低費用。

3. 建立新的 cloud-storage-bucket 分支版本，以便進行變更：

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. 在 terraform.tfvars 和 backend.tf 檔案中，將 PROJECT_ID 預留位置替換為專案 ID：

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   在 OS X 或 macOS 上，您可能需要在 sed -i 後方加上兩個引號 ("")，如下所示：

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. 檢查是否已更新所有檔案：

   git status
   

   輸出如下所示：

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. 修訂並推送變更：

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   新的 cloud-storage-bucket 分支版本會推送至存放區。

7. 開啟並提交各分支版本的合併要求，將 cloud-storage-bucket 變更合併至 dev 和 prod 分支版本。

將權限授予 Cloud Build 服務帳戶

如要允許 Cloud Build 服務帳戶執行 Terraform 指令碼來管理 Google Cloud 資源，您必須授予該帳戶適當的專案存取權。為求簡化，本教學課程會授予專案編輯者存取權。在正式環境中，請遵循公司的 IT 安全性最佳做法，通常是提供最小權限存取權。

注意： 用於執行建構作業的 Cloud Build 預設服務帳戶即將變更。建議您指定自己的服務帳戶來執行建構作業。詳情請參閱「Cloud Build 服務帳戶異動」一文。

1. 如要找出 Cloud Build 服務帳戶電子郵件，請前往 Cloud Build 頁面，然後前往「Settings」(設定)。

   前往 Cloud Build 設定

2. 複製「服務帳戶電子郵件地址」的值。

3. 將所需的存取權授予您的 Cloud Build 服務帳戶：

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   更改下列內容：

   • PROJECT_ID 為您的專案 ID。
   • CLOUDBUILD_SA 替換為 Cloud Build 服務帳戶電子郵件地址。

連結至 Cloud Build

如要在推送至任何分支版本時觸發 Cloud Build，請設定 Secure Source Manager Webhook。建構設定檔會檢查分支名稱，判斷是否需要變更 dev 或 prod 環境。

1. 在專案中啟用及設定 Cloud Build。

2. 在 Google Cloud 控制台中開啟「Triggers」(觸發條件) 頁面。

   開啟「Triggers」(觸發條件) 頁面

3. 從頁面頂端的專案選取器下拉式選單中，選取您的專案。

4. 按一下「開啟」。

5. 按一下「建立觸發條件」。

6. 輸入下列觸發條件設定：

   • Name (名稱)：trigger-on-push

   • Region (區域)：選取觸發條件的區域。如果與觸發條件相關聯的建構設定檔指定了私人集區，則為觸發條件選取的區域必須與私人集區的區域相符。

     注意： 如果使用私人集區，必須指派外部 IP，私人集區才能存取公開網際網路。詳情請參閱「建立新的私人集區」。

     如果您選取 global 做為區域，Cloud Build 會使用建構設定檔中指定的區域執行建構作業。如果您在建構設定檔中指定私人集區，這可以是私人集區的區域；如果您未指定私人集區，則可以是全域預設集區。

   • 「說明」 (選用)：輸入觸發條件的說明。

   • 「Event」(事件)：選取「Webhook event」(Webhook 事件)，做為叫用觸發條件的存放區事件。

     如果未安裝 Secret Manager，系統會提示您啟用 Secret Manager。

   • Webhook 網址：選取下列其中一個選項：

     • 如要使用 Cloud Build 產生新的密鑰，請使用新的密鑰。按一下「建立密鑰」來建立密鑰。
     • 如要使用現有密鑰，請參閱「使用現有密鑰或自行建立」一節。在下拉式選取方塊中，輸入密鑰和版本。

     如果使用現有密鑰，您可能需要手動將「Secret Manager 密鑰存取者」角色授予 Cloud Build 服務代理 [e-mail]。

     詳情請參閱「將角色授予 Cloud Build 服務代理」。

7. 按一下「顯示網址預覽」，然後記下網址。您需要這個網址，才能在 Secure Source Manager 中設定 Webhook。

   • 「Configuration」(設定)：「Type」(類型) 請選取「Cloud Build configuration file (YAML or JSON)」(Cloud Build 建構設定檔 (YAML 或 JSON))，「Location」(位置) 請選取「Inline」(內嵌)。

8. 按一下「開啟編輯器」按鈕，編輯建構設定檔。

9. 將 cloudbuild.yaml 檔案的內容複製到編輯器。

   如先前所述，這個管道會根據要擷取的分支版本而有不同的行為。建構作業會檢查 ${branch} 變數是否與任何環境資料夾相符。如果是，Cloud Build 會為該環境執行 terraform plan。否則，Cloud Build 會針對所有環境執行 terraform plan，確保建議的變更適用於所有環境。如果其中任何一項計畫無法執行，建構作業就會失敗。

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   terraform apply 指令會針對環境分支版本執行，但在其他情況下會完全忽略。

10. 按一下「+ Add variable」(+ 新增變數)，然後新增下列兩個替代變數：

    • 變數：_REPO_URL，值：$(body.repository.clone_url)
    • 變數：_REF，值：$(body.ref)

11. 點選「建立」。

在 Secure Source Manager 中設定 Webhook

建立 Webhook，在推送至 dev 或 prod 分支版本時觸發建構作業。

1. 在 Secure Source Manager 網頁介面中，前往要建立 Webhook 的存放區。
2. 按一下「設定」。
3. 按一下「Webhooks」，然後點選「Add webhook」。

4. 在「Hook ID」欄位中，輸入 Webhook 的 ID。

   注意： Hook ID 必須遵循資源命名慣例。只能使用小寫英文字母、數字或破折號，開頭必須是英文字母，且建立 Webhook 後即無法變更。

5. 在「Target URL」(目標網址) 欄位中，輸入您在 Cloud Build 設定 Webhook 觸發條件時複製的 Webhook 網址。

   如何找出 Webhook 網址：

   1. 在 Google Cloud 控制台中開啟「Triggers」(觸發條件) 頁面。

      開啟「觸發條件」頁面

   2. 按一下觸發條件。

   3. 在「Webhook 網址」部分中，按一下「顯示網址預覽」，然後複製網址。

6. Webhook 網址包含您在建立 Cloud Build 自動建構觸發條件時輸入的金鑰和密鑰值。為避免洩漏這些值，請從目標網址結尾移除這些值，然後複製到「敏感查詢字串」欄位。

   如要在 Webhook 網址中找出金鑰和密鑰，請尋找以 key= 開頭的文字

   舉例來說，假設有以下網址： https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   複製並移除「Target URL」(目標網址) 欄位中以問號 ?key=... 開頭的部分。然後移除開頭的問號，並將剩餘部分 key=... 移至「Sensitive Query String」(機密查詢字串) 欄位。

7. 按一下 [Add Webhook]。

8. 網頁掛鉤會顯示在「Webhooks」頁面。

   注意： 新增或編輯 Webhook 時，Sensitive Query String 的長度可能與輸入的長度不一致，這是正常現象，因為系統會使用預留位置字串來確保安全性。

在新的功能分支版本中變更環境設定

1. 確認您位於 dev 分支：

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. 提取最新變更：

   git pull
   

3. 建立 bug-fix 分支版本，變更環境設定。

   git checkout -b bug-fix
   

4. 開啟 modules/firewall/main.tf 進行編輯。

5. 在第 30 行，修正 target_tags 欄位中的 "http-server2" 錯字。

   此值必須是 "http-server"。

6. 修訂並推送變更：

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. 在 Google Cloud 控制台中，開啟 Cloud Build 的「History」(記錄) 頁面：

   開啟「歷史記錄」頁面

8. 按一下「建構」即可查看更多資訊，包括 terraform plan 的輸出內容。

請注意，Cloud Build 工作執行了 cloudbuild.yaml 檔案中定義的管道。如先前所述，這個管道會根據要擷取的分支版本而有不同的行為。建構作業會檢查 ${branch} 變數是否與任何環境資料夾相符。如果是，Cloud Build 會為該環境執行 terraform plan。否則，Cloud Build 會針對所有環境執行 terraform plan，確保建議的變更適用於所有環境。如果其中任何一項計畫無法執行，建構作業就會失敗。

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

同樣地，terraform apply 指令會針對環境分支執行，但會完全忽略任何其他情況。在本節中，您已將程式碼變更提交至新分支版本，因此沒有任何基礎架構部署作業套用至 Google Cloud 專案。

- id: 'tf apply' name: 'hashicorp/terraform:1.0.0' entrypoint: 'sh' args: - '-c' - | branch=$(basename "$_REF") if [ -d "environments/${branch}/" ]; then cd environments/${branch} terraform apply -auto-approve else echo "***************************** SKIPPING APPLYING *******************************" echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

將變更推行至開發環境

現在可以將所需狀態套用至 dev 環境。

1. 在 Secure Source Manager 網頁介面中，前往存放區。
2. 按一下「新增提取要求」
3. 在「merge into:」欄位中，選取 dev 分支版本。
4. 在「pull from:」欄位中，選取 bug-fix 分支版本。
5. 按一下 [New pull request] (新的提取要求)。
6. 按一下「建立提取要求」。
7. 按一下「Merge pull request」(合併提取要求)，然後再次按一下「Merge pull request」(合併提取要求)。

8. 檢查是否已觸發新的 Cloud Build：

   前往 Cloud Build 頁面

9. 開啟版本並檢查記錄檔。

   當該版本完成後，您會看到如下的內容：

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. 複製 EXTERNAL_IP_VALUE，然後在網路瀏覽器中開啟該位址。

    http://EXTERNAL_IP_VALUE
    

    這項佈建作業可能需要幾秒鐘才能啟動 VM 並傳播防火牆規則。最後，網頁瀏覽器會顯示「Environment: dev」。

11. 前往 Cloud Storage：

    前往 Cloud Storage 頁面

12. 選取專案。

13. 按一下 Terraform 狀態儲存空間 bucket。值區名稱應如下所示：

    PROJECT_ID-tfstate
    

14. 依序點選「env」和「dev」，即可查看 Terraform 狀態檔案。

將變更推送至正式環境

開發環境已完成完整測試，現在可以將基礎架構程式碼推送至正式環境。

1. 在 Secure Source Manager 網頁介面中，前往存放區。
2. 按一下「提取要求」分頁標籤。
3. 按一下 [New pull request] (新的提取要求)。
4. 在「merge into:」部分，選取存放區 prod 分支版本。
5. 在「pull from:」部分，選取存放區 dev 分支版本。
6. 按一下 [New pull request] (新的提取要求)。
7. 在「title」部分輸入標題，例如「Promoting networking changes」，然後按一下「建立提取要求」。

8. 查看建議的變更，然後按一下「Merge pull request」(合併提取要求)。

   系統會在註解欄位中加入日期和存放區網址。

9. 再次點選「合併提取要求」確認。

10. 在 Google Cloud 控制台中開啟「建構記錄」頁面，查看變更是否已套用至正式環境：

    前往「Cloud Build」頁面

11. 等待版本完成，然後檢查記錄檔。

    在記錄檔的末尾，您會看到如下的內容：

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. 複製 EXTERNAL_IP_VALUE，然後在網路瀏覽器中開啟該位址。

    http://EXTERNAL_IP_VALUE
    

    這項佈建作業可能需要幾秒鐘才能啟動 VM 並傳播防火牆規則。最後，網路瀏覽器會顯示「Environment: prod」。

13. 前往 Cloud Storage：

    前往 Cloud Storage 頁面

14. 選取專案。

15. 按一下 Terraform 狀態儲存空間 bucket。Bucket 名稱如下所示：

    PROJECT_ID-tfstate
    

16. 依序點選「env」和「prod」，查看 Terraform 狀態檔案。

您已成功在 Cloud Build 中設定無伺服器基礎架構即程式碼管道。日後，您可以嘗試以下做法：

• 針對不同的用途新增部署。
• 建立其他環境以反映您的需求。
• 針對每個環境使用一個專案，而不是針對每個環境使用一個虛擬私人雲端。

清除所用資源

完成教學課程後，請清除在Google Cloud 建立的資源，以免日後產生費用。

刪除專案

警告：刪除專案會出現以下結果：

• 專案中的所有內容都會遭到刪除。如果使用現有專案來進行本文中的任務，刪除專案將一併移除當中已完成的其他任務'。
• 自訂專案 ID 會消失。當您之前建立這個專案時，可能建立了想要在日後使用的自訂專案 ID。如要保留使用該專案 ID 的網址 (例如 appspot.com 網址)，請刪除在該專案中選取的資源，而不是刪除整個專案。

如果打算探索多種架構、教學課程或快速入門導覽課程，重複使用專案可避免超出專案配額限制。

1. 前往 Google Cloud 控制台的「Manage resources」(管理資源) 頁面。

   前往「Manage resources」(管理資源)

2. 在專案清單中選取要刪除的專案，然後點選「Delete」(刪除)。
3. 在對話方塊中輸入專案 ID，然後按一下 [Shut down] (關閉) 以刪除專案。

後續步驟

• 建議使用 Cloud Cloud Foundation Toolkit 範本，在Google Cloud中快速建構可重複使用的企業級基礎環境。
• 觀看 2019 年 Next 大會的這部影片 Google Cloud ，瞭解如何運用 Cloud Build 基礎架構即程式碼管道，大規模建立可重複使用的環境，並參考本教學課程中說明的 GitOps 工作流程。
• 請參閱「使用 Cloud Build，以 GitOps 模式持續推送軟體更新」教學課程。
• 進一步瞭解 Cloud Build 進階功能：設定建構步驟的順序、建構、測試及部署構件，以及建立自訂建構步驟。
• 請參閱網誌文章「Ensuring scale and compliance of your Terraform Deployment with Cloud Build」(使用 Cloud Build 確保 Terraform 部署作業的規模和法規遵循)。
• 參閱DevOps相關資源。
• 進一步瞭解本教學課程相關的開發運作能力：
  • 版本管控
  • 持續整合
  • 持續推送軟體更新
  • 持續測試
• 進行開發運作快速檢驗，瞭解貴機構在業界的表現。