Terraform 構成コードを保存するように CI/CD を構成する

このチュートリアルでは、一般的な GitOps 手法を使用して、Terraform と Cloud Build により、Infrastructure as Code を管理する方法について説明します。GitOps という用語は、最初に Weaveworks によって造られました。その主なコンセプトは、Git リポジトリを使用して必要な環境状態を保存することです。Terraform は、コードを使用してクラウド インフラストラクチャを予想どおりに作成、変更、改善できる HashiCorp オープンソース ツールです。このチュートリアルでは、 Google Cloud 継続的インテグレーション サービスである Cloud Build を使用して、Terraform マニフェストを環境に自動的に適用します。

このチュートリアルは、インフラストラクチャを予想どおりに変更するための洗練された戦略を探している開発者とオペレーターを対象としています。この記事は、 Google Cloudと Linux に精通していることを前提としています。

State of DevOps で、ソフトウェア デリバリーのパフォーマンスを向上させると認められた機能が報告されています。このチュートリアルは、次の機能について説明します。

• バージョン管理
• 継続的インテグレーション
• 継続的デリバリー
• 継続的なテスト

アーキテクチャ

このチュートリアルでは、Terraform の実行を管理するための GitOps プラクティスを適用します。Secure Source Manager ブランチ dev と prod を使用して、実際の環境を表していることに留意してください。これらの環境は、Google Cloud プロジェクト内の Virtual Private Cloud（VPC）ネットワーク（それぞれ dev と prod）によって定義されます。

Terraform コードを dev または prod ブランチに push すると、プロセスが開始されます。このシナリオでは、Cloud Build がトリガーし、Terraform マニフェストを適用して、それぞれの環境で必要な状態を実現します。一方、Terraform コードを他のブランチ（機能ブランチなど）に push すると、Cloud Build が実行され、terraform plan が実行されますが、どの環境にも適用されません。

理想的には、開発者またはオペレーターのいずれかが、開発ブランチまたは機能ブランチに対してインフラストラクチャの提案を行い、pull リクエストを通じてそれらを提出する必要があります。このようにして、潜在的な変更を共同編集者と話し合ってレビューし、変更がベースブランチにマージされる前にフォローアップ commit を追加できます。

懸念事項が発生しない場合は、最初に変更を dev ブランチにマージする必要があります。このマージにより、dev 環境へのインフラストラクチャ デプロイメントがトリガーされ、この環境をテストできます。テストを行い、デプロイした内容について確認した後、dev ブランチを prod ブランチにマージして、本番環境へのインフラストラクチャのインストールをトリガーする必要があります。

目標

• Secure Source Manager インスタンスとリポジトリを設定します。
• Cloud Storage バケットに状態を保存するように Terraform を構成します。
• Cloud Build サービス アカウントに権限を付与します。
• Cloud Build を Secure Source Manager リポジトリに接続します。
• 機能ブランチで環境構成を変更します。
• 開発環境への変更を促進します。
• 本番環境への変更を促進します。

費用

このドキュメントでは、課金対象である次の Google Cloudコンポーネントを使用します。

• Cloud Build
• Cloud Storage
• Compute Engine

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

新規の Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

このドキュメントに記載されているタスクの完了後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

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 (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 (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. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

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 を構成します。

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

   Git はこの情報を使用して、Cloud Shell で作成する commit の作成者を識別します。

Secure Source Manager リポジトリを設定する

このチュートリアルでは、単一の Secure Source Manager リポジトリを使用してクラウド インフラストラクチャを定義します。異なる環境に対応するさまざまなブランチを持つことで、このインフラストラクチャをオーケストレートします。

• dev ブランチには、開発環境に適用される最新の変更が含まれています。
• prod ブランチには、本番環境に適用される最新の変更が含まれています。
• feature_x と同様の機能ブランチは、dev ブランチまたは prod ブランチに push する前に変更を行うために使用されます。

このインフラストラクチャを使用すると、常にリポジトリを参照してそれぞれの環境で必要とされる構成の内容を把握し、最初に 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 URL です。URL は、Secure Source Manager ウェブ インターフェースのリポジトリ ページの上部にあります。

6. dev ブランチを作成して切り替えます。

   git checkout dev
   

7. 次のコマンドを使用して、クローンされたリポジトリをリポジトリに push します。

   git push -u google --all
   

8. prod ブランチに対して前の 2 つの手順を繰り返します。

このリポジトリのコードは次のように構成されています。

• environments/ フォルダには、dev や prod などの環境を表すサブフォルダが含まれています。これらはそれぞれ、成熟、開発、および運用のさまざまな段階でワークロードを論理的に分離します。これらの環境はできる限り類似した構成にすることをおすすめしますが、各サブフォルダには独自の Terraform 構成があり、必要に応じて一意の設定ができるようになっています。

• modules/ フォルダには、インライン Terraform モジュールが含まれています。これらのモジュールは、関連リソースの論理グループを表し、異なる環境でコードを共有するために使用されます。

• cloudbuild.yaml ファイルは、一連の手順に基づいてタスクを実行する方法など、Cloud Build に関する手順を含むビルド構成ファイルです。このファイルは、Cloud Build がコードを取得するブランチに応じて、条件付き実行を指定します。たとえば、

  • dev と prod ブランチの場合は、次の手順が実行されます。

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

  • その他のブランチの場合は、次の手順が実行されます。

    1. terraform init（すべての environments サブフォルダ）
    2. terraform plan（すべての environments サブフォルダ）

提案された変更がすべての環境に適していることを確認するために、terraform init と terraform plan はすべての environments サブフォルダで実行されます。たとえば、pull リクエストをマージする前にプランを確認することで、承認されていないエンティティにアクセス権が付与されていないことを保証できます。

ビルド構成ファイルを変更する

サンプル ビルド構成ファイルを 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. 変更を commit して push します。

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

5. pull リクエストを開いて、変更を prod ブランチにすばやく昇格させます。

   1. Secure Source Manager ウェブ インターフェースで、リポジトリに移動します。
   2. [Pull requests] タブをクリックします。
   3. [New pull request] をクリックします。
   4. [merge into:] フィールドで、prod ブランチを選択します。
   5. [pull from:] フィールドで、dev ブランチを選択します。
   6. 変更内容を確認し、[New pull request] をクリックします。
   7. [Create pull request] をクリックします。
   8. [Merge pull request] をクリックします。

   9. [Merge pull request] をもう一度クリックします。

      変更が prod ブランチにマージされます。

Cloud Storage バケットに状態を保存するように Terraform を構成する

デフォルトでは、Terraform はローカルの terraform.tfstate という名前のファイルに状態を保存します。多くのユーザーが Terraform を同時に実行していて、各マシンが現在のインフラストラクチャを独自に理解している場合は特に、このデフォルト構成が原因でチームでの Terraform の使用が難しくなる場合があります。

このような問題を回避するために、このセクションでは、Cloud Storage バケットを指すリモート状態を構成します。リモート状態はバックエンドの機能であり、このチュートリアルでは、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 バケットを作成し、新しいバケットと　 Google Cloud 　プロジェクトを指すようにいくつかのファイルを変更します。

1. Cloud Shell で、Cloud Storage バケットを作成します。

   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 の後に 2 つの引用符（""）の追加が必要な場合があります。

   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. 変更を commit して push します。

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

   新しい cloud-storage-bucket ブランチがリポジトリに push されます。

7. 各ブランチのマージ リクエストを開いて送信し、cloud-storage-bucket の変更を dev ブランチと prod ブランチにマージします。

Cloud Build サービス アカウントに権限を付与します。

Cloud Build サービス アカウントが Google Cloud リソースを管理する目的で Terraform スクリプトを実行できるようにするには、プロジェクトへの適切なアクセス権を付与する必要があります。説明をわかりやすくするため、このチュートリアルではプロジェクト エディタへのアクセス権が付与されています。本番環境では、通常は最小限のアクセス権を付与する、会社の IT セキュリティに関するベスト プラクティスに従います。

注: ビルドの実行に使用される Cloud Build のデフォルト サービス アカウントが変更されます。ベスト プラクティスとして、独自のサービス アカウントを指定してビルドを実行することをおすすめします。詳細については、Cloud Build サービス アカウントの変更をご覧ください。

1. Cloud Build サービス アカウントのメールアドレスを確認するには、Cloud Build ページで [設定] に移動します。

   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 に接続する

任意のブランチへの push で Cloud Build をトリガーするには、Secure Source Manager Webhook を設定します。ビルド構成ファイルは、ブランチ名を確認して、dev 環境または prod 環境に変更を加える必要があるかどうかを判断します。

1. プロジェクトで Cloud Build を有効にして設定します。

2. Google Cloud コンソールで [トリガー] ページを開きます。

   [トリガー] ページを開く

3. ページの上部にあるプロジェクト セレクタのプルダウン メニューからプロジェクトを選択します。

4. [開く] をクリックします。

5. [トリガーを作成] をクリックします。

6. 次のトリガー設定を入力します。

   • 名前: trigger-on-push

   • リージョン: トリガーのリージョンを選択します。トリガーに関連付けられたビルド構成ファイルでプライベート プールが指定されている場合、トリガーに選択するリージョンがプライベート プールのリージョンと一致する必要があります。

     注: プライベート プールを使用する場合は、プライベート プールが公共のインターネットにアクセスできるように、外部 IP を割り当てる必要があります。詳細については、新しいプライベート プールを作成するをご覧ください。

     リージョンとして global を選択した場合、Cloud Build はビルド構成ファイルで指定されたリージョンを使用してビルドを実行します。ビルド構成ファイルでプライベート プールを指定した場合はプライベート プールのリージョンになりますが、プライベート プールを指定しない場合はグローバル デフォルト プールになります。

   • 説明（省略可）: トリガーの説明を入力します。

   • イベント: トリガーを呼び出すリポジトリ イベントとして [Webhook イベント] を選択します。

     Secret Manager がインストールされていない場合は、Secret Manager を有効にするよう求められます。

   • Webhook URL: 次のいずれかを選択します。

     • Cloud Build を使用して新しいシークレットを生成する場合は、[新しいシークレットを使用する] を選択します。[シークレットの作成] をクリックして、シークレットを作成します。
     • 既存のシークレットを使用する場合は、[既存のシークレットを使用するか独自のシークレットを作成する] を選択します。プルダウン選択ボックスにシークレットとバージョンを入力します。

     既存のシークレットを使用する場合は、Secret Manager シークレット アクセサーのロールを Cloud Build サービス エージェント [e-mail] に手動で付与する必要があります。

     詳細については、Cloud Build サービス エージェントへのロールの付与をご覧ください。

7. [URL プレビューを表示] をクリックして、URL を記録します。この URL は、Secure Source Manager で Webhook を設定するために必要です。

   • 構成: [タイプ] で [Cloud Build 構成ファイル（YAML または JSON）] を選択し、[ロケーション] で [インライン] を選択します。

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. [+ 変数を追加] をクリックして、次の 2 つの置換変数を追加します。

    • 変数: _REPO_URL、値:$(body.repository.clone_url)
    • 変数: _REF、値:$(body.ref)

11. [作成] をクリックします。

Secure Source Manager で Webhook を設定する

dev ブランチまたは prod ブランチへの push でビルドをトリガーする Webhook を作成します。

1. Secure Source Manager ウェブ インターフェースで、Webhook を作成するリポジトリに移動します。
2. [設定] をクリックします。
3. [Webhook] をクリックし、[Webhook を追加] をクリックします。

4. [フック ID] フィールドに、Webhook の ID を入力します。

   注: フック ID は、リソースの命名規則に従う必要があります。英小文字、数字、ダッシュのみを使用する必要があります。先頭は英字にする必要があります。Webhook の作成後に変更することはできません。

5. [ターゲット URL] フィールドに、Cloud Build で Webhook トリガーを設定したときにコピーした Webhook URL を入力します。

   Webhook URL を確認するには:

   1. Google Cloud コンソールで [トリガー] ページを開きます。

      [トリガー] ページを開く

   2. トリガーをクリックします。

   3. [Webhook URL] セクションで、[URL プレビューを表示] をクリックして URL をコピーします。

6. Webhook URL には、Cloud Build トリガーの作成時に入力したキーとシークレットの値が含まれています。これらの値が漏洩しないように、ターゲット URL の末尾から削除して、[機密性の高いクエリ文字列] フィールドにコピーします。

   Webhook URL でキーとシークレットを見つけるには、key= で始まるテキストを探します。

   たとえば、次の URL があるとします。 https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

   [Target URL] フィールドから、疑問符 ?key=... で始まる部分をコピーして削除します。次に、最初の疑問符を削除し、残りの部分 key=... を [機密性の高いクエリ文字列] フィールドに移動します。

7. [Add webhook] をクリックします。

8. Webhook が [Webhook] ページに表示されます。

   注: ウェブフックを追加または編集すると、Sensitive Query String の長さが入力した長さと一致しないことがあります。これは、セキュリティを確保するためにプレースホルダ文字列が使用されるためです。

新機能ブランチで環境構成を変更する

1. dev ブランチにいることを確認します。

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

2. 最新の変更を pull します。

   git pull
   

3. bug-fix ブランチを作成して、環境構成を変更します。

   git checkout -b bug-fix
   

4. modules/firewall/main.tf を開いて編集します。

5. 30 行目の [target_tags] フィールドで "http-server2" のタイプミスを修正します。

   値は "http-server" を指定してください。

6. 変更を commit して push します。

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

7. Google Cloud コンソールで Cloud Build の [履歴] ページを開きます。

   [履歴] ページを開く

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. [New pull request] をクリックします。
3. [merge into:] フィールドで、dev ブランチを選択します。
4. [pull from:] フィールドで、bug-fix ブランチを選択します。
5. [New pull request] をクリックします。
6. [Create pull request] をクリックします。
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 状態ストレージ バケットをクリックします。バケット名は次のようになります。

    PROJECT_ID-tfstate
    

14. [env]、[dev] の順にクリックして、Terraform 状態ファイルを表示します。

本番環境の変更の促進

開発環境をすべてテストしたため、インフラストラクチャ コードを本番環境にプロモートさせることができます。

1. Secure Source Manager ウェブ インターフェースで、リポジトリに移動します。
2. [Pull requests] タブをクリックします。
3. [New pull request] をクリックします。
4. [merge into:] で、リポジトリの prod ブランチを選択します。
5. [pull from:] で、リポジトリの dev ブランチを選択します。
6. [New pull request] をクリックします。
7. タイトルには、「Promoting networking changes」などのタイトルを入力し、[Create pull request] をクリックします。

8. 提案された変更を確認し、[Merge pull request] をクリックします。

   コメント フィールドに日付とリポジトリの URL が追加されます。

9. [Merge pull request] をもう一度クリックして確定します。

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 状態ストレージ バケットをクリックします。バケット名は次のようになります。

    PROJECT_ID-tfstate
    

16. [env]、[prod] の順にクリックして、Terraform 状態ファイルを表示します。

Cloud Build でサーバーレスのコード パイプラインとしてのインフラストラクチャの構成が正常に終了しました。今後、次のことをお試しください。

• 個別のユースケースのデプロイメントを追加します。
• ニーズを反映する追加の環境を作成します。
• 環境ごとの VPC ではなく、環境ごとのプロジェクトを使用します。

クリーンアップ

チュートリアルが終了したら、Google Cloud で作成したリソースについて料金が発生しないようにクリーンアップします。

プロジェクトの削除

注意: プロジェクトを削除すると、次のような影響があります。

• プロジェクト内のすべてのものが削除されます。このドキュメントのタスクで既存のプロジェクトを使用した場合、それを削除すると、そのプロジェクトで行った他の作業もすべて削除されます。
• カスタム プロジェクト ID が失われます。このプロジェクトを作成したときに、将来使用するカスタム プロジェクト ID を作成した可能性があります。そのプロジェクト ID を使用した URL（たとえば、appspot.com）を保持するには、プロジェクト全体ではなくプロジェクト内の選択したリソースだけを削除します。

複数のアーキテクチャ、チュートリアル、クイックスタートを実施する予定がある場合は、プロジェクトを再利用すると、プロジェクトの割り当て上限の超過を回避できます。

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

• Cloud Foundation Toolkit テンプレートを使用して、再現可能なエンタープライズ対応の基盤をGoogle Cloudで迅速に構築することを検討してください。
• このチュートリアルで説明されている GitOps ワークフローを確認する。Cloud Build Infra-As-Code パイプラインによる再現可能な大規模な Google Cloud 環境（Cloud Next '19）をご覧ください。
• Cloud Build を使用した GitOps スタイルの継続的デリバリーのチュートリアルに進む。
• Cloud Build のより高度な機能を確認する。ビルドステップの順序の構成、アーティファクトのビルド、テスト、デプロイ、カスタム ビルドステップの作成をご覧ください。
• Cloud Build による Terraform デプロイメントのスケーリングとコンプライアンスの確保に関するブログを確認します。
• DevOps に関するリソースを読む。
• このチュートリアルに関連する DevOps 機能の詳細については、以下をご覧ください。
  • バージョン管理
  • 継続的インテグレーション
  • 継続的デリバリー
  • 継続的なテスト
• DevOps のクイック チェックで、業界における立ち位置を把握する。