このページは Cloud Translation API によって翻訳されました。

Compute Engine にデプロイ

このガイドでは、Cloud Build と Terraform を使用して Compute Engine マネージドインスタンスグループ（MIG）でダウンタイムなしの Blue/Green デプロイを行う方法について説明します。

Cloud Build を使用すると、さまざまな Google Cloud ランタイム（Compute Engine、Google Kubernetes Engine、GKE Enterprise、Cloud Run functions など）へのアプリケーションのビルドとデプロイなど、さまざまなデベロッパープロセスを自動化できます。

Compute Engine MIG を使用すると、複数の同じ仮想マシン（VM）でアプリケーションを操作できます。自動スケーリング、自動修復、リージョン（マルチゾーン）デプロイ、自動更新などの自動化 MIG サービスを活用することで、ワークロードのスケーラビリティと高可用性を実現できます。Blue/Green 継続的デプロイモデルを使用して、ユーザートラフィックを、ある MIG（Blue）から別の MIG（Green）に段階的に転送する方法について学習します。MIG は、どちらも本番環境で実行されます。

始める前に

Enable the Cloud Build, Cloud Run, Artifact Registry, and Resource Manager APIs.
Roles required to enable APIs
To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.
Enable the APIs

アプリケーションのソースコードを用意します。ソースコードは、GitHub や Bitbucket などのリポジトリに保存する必要があります。
このページで gcloud コマンドを実行するには、Google Cloud CLI をインストールします。

必要な Identity and Access Management 権限

Google Cloud コンソールで、 Cloud Build の [権限] ページに移動します。
[権限] に移動
指定した Cloud Build サービスアカウントまたはデフォルトの Cloud Build サービスアカウントで、次のロールのステータスを [有効] に設定します。
- Compute インスタンス管理者 v1（roles/compute.instanceAdmin）| Cloud Build が新しいインスタンスを Compute Engine にデプロイできるようにします。
  - [サービスアカウントユーザーのロールを割り当てる] パネルで、権限を借用するサービスアカウントを選択し、[権限を付与] をクリックします。
- ストレージ管理者（roles/storage.admin）| Cloud Storage からの読み取りと書き込みを有効にします。
- Artifact Registry 書き込み（roles/artifactregistry.writer）| Artifact Registry からのイメージの pull と Artifact Registry への書き込みを許可します。
- ログ書き込み（roles/logging.logWriter）| ログエントリを Cloud Logging に書き込むことができます。
- Cloud Build 編集者（roles/cloudbuild.builds.editor）| サービスアカウントでビルドを実行できます。

デザインの概要

次の図は、このドキュメントで説明するコードサンプルで使用される Blue / Green デプロイモデルを示しています。

Blue/Green モデル

大まかに表現すると、このモデルには、次のコンポーネントが含まれています。

2 つの Compute Engine VM プール（Blue と Green）。
3 つの外部 HTTP(S) ロードバランサ:
- Blue-Green ロードバランサ。エンドユーザーから VM インスタンスの Blue または Green プールにトラフィックを転送します。
- QA エンジニアとデベロッパーから Blue VM インスタンスプールにトラフィックを転送する Blue ロードバランサ。
- QA エンジニアとデベロッパーから Green インスタンスプールにトラフィックを転送する Green ロードバランサ。
次の 2 セットのユーザー:
- Blue-Green ロードバランサにアクセスできるエンドユーザー。Blue または Green のインスタンスプールを参照します。
- 開発とテストを目的として、両方のプールセットにアクセスする必要がある QA エンジニアとデベロッパー。Blue ロードバランサと Green ロードバランサの両方にアクセスでき、ロードバランサはそれぞれ Blue インスタンスプールと Green インスタンスプールに転送されます。

Blue と Green の VM プールは Compute Engine MIG として実装され、外部 IP アドレスは、外部 HTTP(S) ロードバランサを使用して MIG の VM に転送されます。このドキュメントで説明するコードサンプルでは、Terraform を使用してこのインフラストラクチャを構成します。

次の図では、デプロイで発生するデベロッパーオペレーションを示します。

デベロッパーオペレーションフロー

上の図では、赤い矢印はデプロイメントインフラストラクチャを初めて設定するときに発生するブートストラップフローを表し、青い矢印はすべてのデプロイ中に発生する GitOps のフローを表しています。

このインフラストラクチャを設定するには、ブートストラッププロセスを開始して GitOps フローのコンポーネントを設定するセットアップスクリプトを実行します。

セットアップスクリプトは、次のオペレーションを実行する Cloud Build パイプラインを実行します。

Cloud Source Repositories に copy-of-gcp-mig-simple という名前のリポジトリを作成し、GitHub サンプルリポジトリから Cloud Source Repositories にあるこのリポジトリにソースコードをコピーします。
apply と destroy という名前の 2 つの Cloud Build トリガーを作成します。

apply トリガーは、Cloud Source Repositories の main.tfvars という名前の Terraform ファイルにアタッチされています。このファイルには、Blue ロードバランサと Green ロードバランサを表す Terraform 変数が含まれています。

デプロイを設定するには、main.tfvars ファイルの変数を更新します。apply トリガーは、tf_apply を実行する Cloud Build パイプラインを実行し、次のオペレーションを実行します。

2 つの Compute Engine MIG（1 つは Green、もう 1 つは Blue）、4 つの Compute Engine VM インスタンス（2 つの Green MIG と 2 つの Blue MIG）、3 つのロードバランサ（Blue、Green、スプリッターなど）と 3 つのパブリック IP アドレス。
デプロイされたアプリケーションを Blue インスタンスと Green インスタンスで表示するために使用できる IP アドレスを出力します。

破棄トリガーは手動でトリガーされ、適用トリガーによって作成されたすべてのリソースを削除します。

試してみる

Google コードサンプルリポジトリから設定スクリプトを実行します。

bash <(curl https://raw.githubusercontent.com/GoogleCloudPlatform/cloud-build-samples/main/mig-blue-green/setup.sh)

セットアップスクリプトでユーザーの同意を求められたら、「yes」と入力します。

スクリプトの実行は、数秒で完了します。
Google Cloud コンソールで、Cloud Build の [ビルド履歴] ページを開きます。

[ビルド履歴] ページを開く
最新のビルドをクリックします。

[ビルドの詳細] ページが開き、3 つのビルドステップを含む Cloud Build パイプラインが表示されます。最初のビルドステップで、Cloud Source Repositories にリポジトリが作成されます。2 番目のステップでは、GitHub のサンプルリポジトリの内容のクローンを Cloud Source Repositories に作成します。3 番目のステップでは 2 つのビルドトリガーを追加します。
Cloud Source Repositories を開く

Cloud Source Repositories を開く
リポジトリリストで、copy-of-gcp-mig-simple をクリックします。

ページの下部にある [履歴] タブでは、copy-of-gcp-mig-simple という名前のリポジトリを作成するために Cloud Build が作成した説明 A copy of https://github.com/GoogleCloudPlatform/cloud-build-samples.git を含む 1 つの commit が表示されます。
Cloud Build の [トリガー] ページを開きます。

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

apply と destroy という名前の 2 つのビルドトリガーが表示されます。apply トリガーは main ブランチの infra/main.tfvars ファイルにアタッチされています。このトリガーは、ファイルが更新されるたびに実行されます。destroy トリガーは手動トリガーです。

デプロイプロセスを開始するには、infra/main.tfvars ファイルを更新します。
1. ターミナルウィンドウで、deploy-compute-engine という名前のフォルダを作成して移動します。
```
mkdir ~/deploy-compute-engine
cd ~/deploy-compute-engine
```
2. copy-of-gcp-mig-simple リポジトリのクローンを作成します。
```
gcloud source repos clone copy-of-mig-blue-green
```
3. クローン作成したディレクトリに移動します。
```
cd ./copy-of-mig-blue-green
```
4. infra/main.tfvars を更新して、Blue を Green に置き換えます。
```
sed -i'' -e 's/blue/green/g' infra/main.tfvars
```
5. 更新したファイルを追加します。
```
git add .
```
6. ファイルを commit します。
```
git commit -m "Promote green"
```
7. ファイルを push します。
```
git push
```
  infra/main.tfvars を変更すると、apply トリガーの実行がトリガーされ、デプロイが開始されます。
Cloud Source Repositories を開く

Cloud Source Repositories を開く
リポジトリリストで、copy-of-gcp-mig-simple をクリックします。

ページの下部にある [履歴] タブに、Promote green と記述された commit が表示されます。
apply トリガーの実行を表示するには、 Google Cloud コンソールで [ビルド履歴] ページを開きます。

[ビルド履歴] ページを開く
最初のビルドをクリックして、[ビルドの詳細] ページを開きます。

2 つのビルドステップを含む apply トリガーパイプラインが表示されます。最初のビルドステップでは、Terraform apply を実行して、Compute Engine とデプロイのロードバランシングリソースを作成します。2 番目のビルドステップでは、アプリケーションが実行されている IP アドレスを出力します。
ブラウザで、Green MIG に対応する IP アドレスを開きます。次のようなデプロイを示すスクリーンショットが表示されます。
Compute Engine の [インスタンスグループ] ページに移動して、Blue と Green のインスタンスグループを表示します。

[インスタンスグループ] ページを開く
[VM インスタンス] ページを開き、4 つの VM インスタンスを確認します。

[VM インスタンス] ページを開く
[外部 IP アドレス] ページを開き、3 つのロードバランサを確認します。

[外部 IP アドレス] ページを開く

コードについて

このコードサンプルのソースコードには以下が含まれます。

セットアップスクリプトに関連するソースコード。
Cloud Build パイプラインに関連するソースコード。
Terraform テンプレートに関連するソースコード。

セットアップスクリプト

setup.sh は、ブートストラッププロセスを実行して Blue/Green デプロイのコンポーネントを作成するセットアップスクリプトです。このスクリプトは、次の操作を実行します。

Cloud Build、Resource Manager、Compute Engine、Cloud Source Repositories の各 API を有効にします。
プロジェクトの Cloud Build サービスアカウントに roles/editor IAM ロールを付与します。このロールは、Cloud Build がデプロイに必要な GitOps コンポーネントを作成して設定するために必要です。
プロジェクトの Cloud Build サービスアカウントに roles/source.admin IAM ロールを付与します。このロールは、Cloud Build サービスアカウントがプロジェクトに Cloud Source Repositories を作成し、サンプル GitHub リポジトリの内容を Cloud Source Repositories にクローン作成するために必要です。
次のように、bootstrap.cloudbuild.yaml という名前の Cloud Build パイプラインをインラインで生成します。
- Cloud Source Repositories に新しいリポジトリを作成します。
- サンプル GitHub リポジトリから Cloud Source Repositories の新しいリポジトリにソースコードをコピーします。
- 適用ビルドトリガーと破棄ビルドトリガーを作成します。

set -e

BLUE='\033[1;34m'
RED='\033[1;31m'
GREEN='\033[1;32m'
NC='\033[0m'

echo -e "\n${GREEN}######################################################"
echo -e "#                                                    #"
echo -e "#  Zero-Downtime Blue/Green VM Deployments Using     #"
echo -e "#  Managed Instance Groups, Cloud Build & Terraform  #"
echo -e "#                                                    #"
echo -e "######################################################${NC}\n"

echo -e "\nSTARTED ${GREEN}setup.sh:${NC}"

echo -e "\nIt's ${RED}safe to re-run${NC} this script to ${RED}recreate${NC} all resources.\n"
echo "> Checking GCP CLI tool is installed"
gcloud --version > /dev/null 2>&1

readonly EXPLICIT_PROJECT_ID="$1"
readonly EXPLICIT_CONSENT="$2"

if [ -z "$EXPLICIT_PROJECT_ID" ]; then
    echo "> No explicit project id provided, trying to infer"
    PROJECT_ID="$(gcloud config get-value project)"
else
    PROJECT_ID="$EXPLICIT_PROJECT_ID"
fi

if [ -z "$PROJECT_ID" ]; then
    echo "ERROR: GCP project id was not provided as parameter and could not be inferred"
    exit 1
else
    readonly PROJECT_NUM="$(gcloud projects describe $PROJECT_ID --format='value(projectNumber)')"
    if [ -z "$PROJECT_NUM" ]; then
        echo "ERROR: GCP project number could not be determined"
        exit 1
    fi
    echo -e "\nYou are about to:"
    echo -e "  * modify project ${RED}${PROJECT_ID}/${PROJECT_NUM}${NC}"
    echo -e "  * ${RED}enable${NC} various GCP APIs"
    echo -e "  * make Cloud Build ${RED}editor${NC} of your project"
    echo -e "  * ${RED}execute${NC} Cloud Builds and Terraform plans to create"
    echo -e "  * ${RED}4 VMs${NC}, ${RED}3 load balancers${NC}, ${RED}3 public IP addresses${NC}"
    echo -e "  * incur ${RED}charges${NC} in your billing account as a result\n"
fi

if [ "$EXPLICIT_CONSENT" == "yes" ]; then
  echo "Proceeding under explicit consent"
  readonly CONSENT="$EXPLICIT_CONSENT"
else
    echo -e "Enter ${BLUE}'yes'${NC} if you want to proceed:"
    read CONSENT
fi

if [ "$CONSENT" != "yes" ]; then
    echo -e "\nERROR: Aborted by user"
    exit 1
else
    echo -e "\n......................................................"
    echo -e "\n> Received user consent"
fi

#
# Executes action with one randomly delayed retry.
#
function do_with_retry {
    COMMAND="$@"
    echo "Trying $COMMAND"
    (eval $COMMAND && echo "Success on first try") || ( \
        echo "Waiting few seconds to retry" &&
        sleep 10 && \
        echo "Retrying $COMMAND" && \
        eval $COMMAND \
    )
}

echo "> Enabling required APIs"
# Some of these can be enabled later with Terraform, but I personally
# prefer to do all API enablement in one place with gcloud.
gcloud services enable \
    --project=$PROJECT_ID \
    cloudbuild.googleapis.com \
    cloudresourcemanager.googleapis.com \
    compute.googleapis.com \
    sourcerepo.googleapis.com \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/editor"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com" \
    --role='roles/editor' \
    --condition=None \
    --no-user-output-enabled \
    --quiet

echo "> Adding Cloud Build to roles/source.admin"
gcloud projects add-iam-policy-binding \
    "$PROJECT_ID" \
    --member="serviceAccount:$PROJECT_NUM@cloudbuild.gserviceaccount.com" \
    --condition=None \
    --role='roles/source.admin' \
    --no-user-output-enabled \
    --quiet

echo "> Configuring bootstrap job"
rm -rf "./bootstrap.cloudbuild.yaml"
cat <<'EOT_BOOT' > "./bootstrap.cloudbuild.yaml"
tags:
- "mig-blue-green-bootstrapping"
steps:
- id: create_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating source code repository"

    gcloud source repos delete \
        "copy-of-mig-blue-green" \
        --quiet || true

    gcloud source repos create \
        "copy-of-mig-blue-green" \
        --quiet

- id: copy_demo_source_into_new_cloud_source_repo
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
    - "PROJECT_NUMBER=$PROJECT_NUMBER"
  script: |
    #!/bin/bash
    set -e

    readonly GIT_REPO="https://github.com/GoogleCloudPlatform/cloud-build-samples.git"

    echo "Cloning demo source repo"
    mkdir /workspace/from/
    cd /workspace/from/
    git clone $GIT_REPO ./original
    cd ./original

    echo "Cloning new empty repo"
    mkdir /workspace/to/
    cd /workspace/to/
    gcloud source repos clone \
        "copy-of-mig-blue-green"
    cd ./copy-of-mig-blue-green

    echo "Making a copy"
    cp -r /workspace/from/original/mig-blue-green/* ./

    echo "Setting git identity"
    git config user.email \
        "$PROJECT_NUMBER@cloudbuild.gserviceaccount.com"
    git config user.name \
        "Cloud Build"

    echo "Commit & push"
    git add .
    git commit \
        -m "A copy of $GIT_REPO"
    git push

- id: add_pipeline_triggers
  name: "gcr.io/cloud-builders/gcloud"
  env:
    - "PROJECT_ID=$PROJECT_ID"
  script: |
    #!/bin/bash
    set -e

    echo "(Re)Creating destroy trigger"
    gcloud builds triggers delete "destroy" --quiet || true
    gcloud builds triggers create manual \
        --name="destroy" \
        --repo="https://source.developers.google.com/p/$PROJECT_ID/r/copy-of-mig-blue-green" \
        --branch="master" \
        --build-config="pipelines/destroy.cloudbuild.yaml" \
        --repo-type=CLOUD_SOURCE_REPOSITORIES \
        --quiet

    echo "(Re)Creating apply trigger"
    gcloud builds triggers delete "apply" --quiet || true
    gcloud builds triggers create cloud-source-repositories \
        --name="apply" \
        --repo="copy-of-mig-blue-green" \
        --branch-pattern="master" \
        --build-config="pipelines/apply.cloudbuild.yaml" \
        --included-files="infra/main.tfvars" \
        --quiet

EOT_BOOT

echo "> Waiting API enablement propagation"
do_with_retry "(gcloud builds list --project "$PROJECT_ID" --quiet && gcloud compute instances list --project "$PROJECT_ID" --quiet && gcloud source repos list --project "$PROJECT_ID" --quiet) > /dev/null 2>&1" > /dev/null 2>&1

echo "> Executing bootstrap job"
gcloud beta builds submit \
    --project "$PROJECT_ID" \
    --config ./bootstrap.cloudbuild.yaml \
    --no-source \
    --no-user-output-enabled \
    --quiet
rm ./bootstrap.cloudbuild.yaml

echo -e "\n${GREEN}All done. Now you can:${NC}"
echo -e "  * manually run 'apply' and 'destroy' triggers to manage deployment lifecycle"
echo -e "  * commit change to 'infra/main.tfvars' and see 'apply' pipeline trigger automatically"

echo -e "\n${GREEN}Few key links:${NC}"
echo -e "  * Dashboard: https://console.cloud.google.com/home/dashboard?project=$PROJECT_ID"
echo -e "  * Repo: https://source.cloud.google.com/$PROJECT_ID/copy-of-mig-blue-green"
echo -e "  * Cloud Build Triggers: https://console.cloud.google.com/cloud-build/triggers;region=global?project=$PROJECT_ID"
echo -e "  * Cloud Build History: https://console.cloud.google.com/cloud-build/builds?project=$PROJECT_ID"

echo -e "\n............................."

echo -e "\n${GREEN}COMPLETED!${NC}"

Cloud Build パイプライン

apply.cloudbuild.yaml と destroy.cloudbuild.yaml は、セットアップスクリプトが GitOps フローのリソースを設定するために使用する Cloud Build 構成ファイルです。apply.cloudbuild.yaml には、2 つのビルドステップがあります。

Terraform をインストールする関数 tf_install_in_cloud_build_step を呼び出す tf_apply build ビルドステップ。tf_apply は、GitOps フローで使用されるリソースを作成します。関数 tf_install_in_cloud_build_step と tf_apply は bash_utils.sh で定義され、ビルドステップは source コマンドを使用してそれらを呼び出します。
ロードバランサの IP アドレスを出力する describe_deployment 関数を呼び出す describe_deployment ビルドステップ。

destroy.cloudbuild.yaml は、tf_apply によって作成されたすべてのリソースを削除する tf_destroy を呼び出します。

関数 tf_install_in_cloud_build_step、tf_apply、describe_deployment、tf_destroy は、bash_utils.sh ファイルで定義されています。ビルド構成ファイルは、source コマンドを使用して関数を呼び出します。

steps:
  - id: run-terraform-apply
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_apply

  - id: describe-deployment
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      describe_deployment

tags:
  - "mig-blue-green-apply"

steps:
  - id: run-terraform-destroy
    name: "gcr.io/cloud-builders/gcloud"
    env:
      - "PROJECT_ID=$PROJECT_ID"
    script: |
      #!/bin/bash
      set -e
      source /workspace/lib/bash_utils.sh
      tf_install_in_cloud_build_step
      tf_destroy

tags:
  - "mig-blue-green-destroy"

次のコードでは、bash_utils.sh で定義されている関数 tf_install_in_cloud_build_step を示します。ビルド構成ファイルがこの関数を呼び出して、Terraform をその場でインストールします。Terraform のステータスを記録する Cloud Storage バケットを作成します。

function tf_install_in_cloud_build_step {
    echo "Installing deps"
    apt update
    apt install \
        unzip \
        wget \
        -y

    echo "Manually installing Terraform"
    wget https://releases.hashicorp.com/terraform/1.3.4/terraform_1.3.4_linux_386.zip
    unzip -q terraform_1.3.4_linux_386.zip
    mv ./terraform /usr/bin/
    rm -rf terraform_1.3.4_linux_386.zip

    echo "Verifying installation"
    terraform -v

    echo "Creating Terraform state storage bucket $BUCKET_NAME"
    gcloud storage buckets create \
        "gs://$BUCKET_NAME" || echo "Already exists..."

    echo "Configure Terraform provider and state bucket"
cat <<EOT_PROVIDER_TF > "/workspace/infra/provider.tf"
terraform {
  required_version = ">= 0.13"
  backend "gcs" {
    bucket = "$BUCKET_NAME"
  }
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = ">= 3.77, < 5.0"
    }
  }
}
EOT_PROVIDER_TF

    echo "$(cat /workspace/infra/provider.tf)"
}

次のコードスニペットでは、bash_utils.sh で定義されている関数 tf_apply を示します。まず、すべてのモジュールとカスタムライブラリを読み込む terraform init を呼び出し、次に terraform apply を実行して main.tfvars ファイルから変数を読み込みます。

function tf_apply {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform apply"
    terraform \
        -chdir="$TF_CHDIR" \
        apply \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

次のコードスニペットでは、bash_utils.sh で定義されている関数 describe_deployment を示します。gcloud compute addresses describe を使用し、名前でロードバランサの IP アドレスを取得して出力します。

function describe_deployment {
    NS="ns1-"
    echo -e "Deployment configuration:\n$(cat infra/main.tfvars)"
    echo -e \
      "Here is how to connect to:" \
      "\n\t* active color MIG: http://$(gcloud compute addresses describe ${NS}splitter-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* blue color MIG: http://$(gcloud compute addresses describe ${NS}blue-address-name --region=us-west1 --format='value(address)')/" \
      "\n\t* green color MIG: http://$(gcloud compute addresses describe ${NS}green-address-name --region=us-west1 --format='value(address)')/"
    echo "Good luck!"
}

次のコードスニペットでは、bash_utils.sh で定義されている関数 tf_destroy を示します。すべてのモジュールとカスタムライブラリを読み込む terraform init を呼び出して、Terraform 変数をアンロードする terraform destroy を実行します。

function tf_destroy {
    echo "Running Terraform init"
    terraform \
        -chdir="$TF_CHDIR" \
        init

    echo "Running Terraform destroy"
    terraform \
        -chdir="$TF_CHDIR" \
        destroy \
        -auto-approve \
        -var project="$PROJECT_ID" \
        -var-file="main.tfvars"
}

Terraform テンプレート

すべての Terraform 構成ファイルと変数は、copy-of-gcp-mig-simple/infra/ フォルダにあります。

main.tf: Terraform 構成ファイルです。
main.tfvars: このファイルは Terraform 変数を定義します。
mig/ と splitter/: これらのフォルダには、ロードバランサを定義するモジュールが含まれています。mig/ フォルダには、Blue ロードバランサと Green ロードバランサの MIG を定義する Terraform 構成ファイルが含まれています。Blue MIG と Green MIG は、同じであるため、Blue オブジェクトと Green オブジェクト用に 1 回定義され、インスタンス化されます。スプリッターロードバランサの Terraform 構成ファイルは、splitter/ フォルダにあります。

次のコードスニペットでは、infra/main.tfvars の内容を示します。これには、Blue プールと Green プールにデプロイするアプリケーションのバージョンを決定する 2 つの変数と、アクティブな色（Blue または Green）の変数が含まれます。このファイルへの変更によってデプロイがトリガーされます。

MIG_VER_BLUE     = "v1"
MIG_VER_GREEN    = "v1"
MIG_ACTIVE_COLOR = "blue"

次は infra/main.tf のコードスニペットです。このスニペットでは:

Google Cloud プロジェクト用に変数が定義されます。
Google は Terraform プロバイダとして設定されます。
名前空間用に変数が定義されます。Terraform で作成したすべてのオブジェクトには、この接頭辞が付けられるため、アプリケーションの複数のバージョンを同じプロジェクトにデプロイでき、オブジェクト名は互いに競合しません。
変数 MIG_VER_BLUE、MIG_VER_BLUE、MIG_ACTIVE_COLOR は、infra/main.tfvars ファイル内の変数に対するバインディングです。

variable "project" {
  type        = string
  description = "GCP project we are working in."
}

provider "google" {
  project = var.project
  region  = "us-west1"
  zone    = "us-west1-a"
}

variable "ns" {
  type        = string
  default     = "ns1-"
  description = "The namespace used for all resources in this plan."
}

variable "MIG_VER_BLUE" {
  type        = string
  description = "Version tag for 'blue' deployment."
}

variable "MIG_VER_GREEN" {
  type        = string
  description = "Version tag for 'green' deployment."
}

variable "MIG_ACTIVE_COLOR" {
  type        = string
  description = "Active color (blue | green)."
}

infra/main.tf の次のコードスニペットでは、スプリッターモジュールのインスタンス化を示します。このモジュールは、分配ロードバランサがアプリケーションをデプロイする MIG を認識できるように、アクティブカラーを取得します。

module "splitter-lb" {
  source               = "./splitter"
  project              = var.project
  ns                   = "${var.ns}splitter-"
  active_color         = var.MIG_ACTIVE_COLOR
  instance_group_blue  = module.blue.google_compute_instance_group_manager_default.instance_group
  instance_group_green = module.green.google_compute_instance_group_manager_default.instance_group
}

次に示す infra/main.tf のコードスニペットでは、Blue MIG と Green MIG に対する 2 つの同じモジュールを定義します。これはスプリッターモジュールで定義されたカラー、ネットワーク、サブネットワークを取得します。

module "blue" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_BLUE
  ns                                   = var.ns
  color                                = "blue"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

module "green" {
  source                               = "./mig"
  project                              = var.project
  app_version                          = var.MIG_VER_GREEN
  ns                                   = var.ns
  color                                = "green"
  google_compute_network               = module.splitter-lb.google_compute_network
  google_compute_subnetwork            = module.splitter-lb.google_compute_subnetwork_default
  google_compute_subnetwork_proxy_only = module.splitter-lb.google_compute_subnetwork_proxy_only
}

ファイル splitter/main.tf では、スプリッター MIG 用に作成されるオブジェクトを定義します。splitter/main.tf のコードスニペットを次に示します。これには、Green MIG と Blue MIG を切り替えるロジックが含まれています。これは google_compute_region_backend_service サービスを基盤としており、var.instance_group_blue または var.instance_group_green の 2 つのバックエンドリージョンにトラフィックを転送できます。capacity_scaler では、転送するトラフィックの量を定義します。

次のコードでは、トラフィックの 100% が指定された色に転送されますが、このコードをカナリアデプロイで更新して、そのトラフィックをユーザーのサブセットに転送できます。

resource "google_compute_region_backend_service" "default" {
  name                  = local.l7-xlb-backend-service
  region                = "us-west1"
  load_balancing_scheme = "EXTERNAL_MANAGED"
  health_checks         = [google_compute_region_health_check.default.id]
  protocol              = "HTTP"
  session_affinity      = "NONE"
  timeout_sec           = 30
  backend {
    group           = var.instance_group_blue
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "blue" ? 1 : 0
  }
  backend {
    group           = var.instance_group_green
    balancing_mode  = "UTILIZATION"
    capacity_scaler = var.active_color == "green" ? 1 : 0
  }
}

ファイル mig/main.tf では、Blue MIG と Green MIG に関連するオブジェクトが定義されています。このファイルの次のコードスニペットでは、VM プールの作成に使用される Compute Engine インスタンステンプレートを定義します。このインスタンステンプレートでは、Terraform ライフサイクルプロパティが create_before_destroy に設定されます。これはプールのバージョンを更新する際、テンプレートが以前のバージョンのプールでまだ使用されている場合に、そのテンプレートで新しいバージョンのプールを作成できないためです。ただし、新しいテンプレートを作成する前に古いバージョンのプールが破棄されると、プールがダウンする期間が発生します。このシナリオを回避するため、Terraform ライフサイクルを create_before_destroy に設定し、古いバージョンが破棄される前に新しいバージョンの VM プールが作成されるようにします。

resource "google_compute_instance_template" "default" {
  name = local.l7-xlb-backend-template
  disk {
    auto_delete  = true
    boot         = true
    device_name  = "persistent-disk-0"
    mode         = "READ_WRITE"
    source_image = "projects/debian-cloud/global/images/family/debian-10"
    type         = "PERSISTENT"
  }
  labels = {
    managed-by-cnrm = "true"
  }
  machine_type = "n1-standard-1"
  metadata = {
    startup-script = <<EOF
    #! /bin/bash
    sudo apt-get update
    sudo apt-get install apache2 -y
    sudo a2ensite default-ssl
    sudo a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    sudo echo "<html><body style='font-family: Arial; margin: 64px; background-color: light${var.color};'><h3>Hello, World!<br><br>version: ${var.app_version}<br>ns: ${var.ns}<br>hostname: $vm_hostname</h3></body></html>" | \
    tee /var/www/html/index.html
    sudo systemctl restart apache2
    EOF
  }
  network_interface {
    access_config {
      network_tier = "PREMIUM"
    }
    network    = var.google_compute_network.id
    subnetwork = var.google_compute_subnetwork.id
  }
  region = "us-west1"
  scheduling {
    automatic_restart   = true
    on_host_maintenance = "MIGRATE"
    provisioning_model  = "STANDARD"
  }
  tags = ["load-balanced-backend"]

  # NOTE: the name of this resource must be unique for every update;
  #       this is wy we have a app_version in the name; this way
  #       new resource has a different name vs old one and both can
  #       exists at the same time
  lifecycle {
    create_before_destroy = true
  }
}