Cloud Build を使用して Git リポジトリからワークフローをデプロイする

Cloud Build トリガーを使用して、ビルドを自動的に開始し、Git リポジトリからワークフローをデプロイできます。ソースリポジトリが変更されたときにワークフローをデプロイするようにトリガーを構成できます。また、変更が特定の条件に一致する場合にのみワークフローをデプロイすることもできます。

このアプローチは、デプロイライフサイクルを管理する際に活用できます。たとえば、ステージング環境でワークフローの変更をデプロイし、その環境に対してテストを実行して、これらの変更を本番環境に段階的にロールアウトできます。

始める前に

この手順では、トリガーを作成できるように、Google Cloud プロジェクトで Cloud Build 編集者のロール（roles/cloudbuild.builds.editor）を付与されていることを前提としています。また、GitHub や Bitbucket などのソースリポジトリにワークフローも必要です。

Console

Cloud Build API と Workflows API を有効にします。

API を有効にする
Workflows 管理者のロール（roles/workflows.admin）を Cloud Build サービスアカウントに付与します。
1. Google Cloud コンソールの [IAM] ページに移動します。
  
  [IAM] に移動
2. プロジェクトを選択します。
3. Cloud Build サービスアカウント（PROJECT_NUMBER@cloudbuild.gserviceaccount.com）の行で、 [プリンシパルを編集] をクリックします。
4. [ 別のロールを追加] をクリックします。
5. [ロール] リストで、[ワークフロー管理者] ロールを選択します。
6. [保存] をクリックします。
Compute Engine のデフォルトサービスアカウントのサービスアカウントユーザーロール（roles/iam.serviceAccountUser）を Cloud Build サービスアカウントに付与します。Compute Engine API を有効にした場合、Compute Engine のデフォルトのサービスアカウントは PROJECT_NUMBER-compute@developer.gserviceaccount.com です。

注意: サービスアカウントユーザーのロールを割り当てると、デフォルトのサービスアカウントに関連付けられたロールが間接的にユーザーに付与されます。たとえば、デフォルトのサービスアカウントに編集者のロールがある場合、ユーザーは編集者として機能できます。これらのロールの割り当ての影響を最小限に抑えるには、最小権限の原則に沿ってデフォルトのサービスアカウントを構成することをおすすめします。詳細については、デフォルトのサービスアカウントへの自動的なロール付与を無効にするをご覧ください。
1. Google Cloud コンソールで、[サービスアカウント] ページに移動します。
  
  [サービスアカウント] に移動
2. プロジェクトを選択します。
3. Compute Engine のデフォルトのサービスアカウント（PROJECT_NUMBER-compute@developer.gserviceaccount.com）のメールアドレスをクリックします。
4. [権限] タブをクリックします。
5. [アクセスを許可] ボタンをクリックします。
6. 新しいプリンシパルを追加するには、サービスアカウントのメールアドレス（SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com）を入力します。
7. [ロールを選択] リストで、[サービスアカウント] > [サービスアカウントユーザー] ロールを選択します。
8. [保存] をクリックします。

gcloud

Cloud Build API と Workflows API を有効にします。

gcloud services enable cloudbuild.googleapis.com \
  workflows.googleapis.com

Workflows 管理者のロール（roles/workflows.admin）を Cloud Build サービスアカウントに付与します。

PROJECT_NUMBER=$(gcloud projects describe PROJECT_ID --format='value(projectNumber)')
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/workflows.admin

PROJECT_ID は、Google Cloud プロジェクトの ID に置き換えます。

Compute Engine のデフォルトサービスアカウントのサービスアカウントユーザーロール（roles/iam.serviceAccountUser）を Cloud Build サービスアカウントに付与します。Compute Engine API を有効にした場合、Compute Engine のデフォルトのサービスアカウントは PROJECT_NUMBER-compute@developer.gserviceaccount.com です。

注意: サービスアカウントユーザーのロールを割り当てると、デフォルトのサービスアカウントに関連付けられたロールが間接的にユーザーに付与されます。たとえば、デフォルトのサービスアカウントに編集者のロールがある場合、ユーザーは編集者として機能できます。これらのロールの割り当ての影響を最小限に抑えるには、最小権限の原則に沿ってデフォルトのサービスアカウントを構成することをおすすめします。詳細については、デフォルトのサービスアカウントへの自動的なロール付与を無効にするをご覧ください。
```
gcloud iam service-accounts add-iam-policy-binding \
  $PROJECT_NUMBER-compute@developer.gserviceaccount.com \
  --member=serviceAccount:$PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role=roles/iam.serviceAccountUser
```

ソースリポジトリに接続する

リポジトリで発生したイベントに応じて Cloud Build がビルドを自動化できるようにするには、Cloud Build をソースリポジトリに接続する必要があります。

GitHub または Bitbucket に接続するには、次の手順を実行します。

Google Cloud コンソールで、[Cloud Build トリガー] ページに移動します。

[トリガー] に移動
必要に応じて、プロジェクトを選択して [開く] をクリックします。
[リージョン] リストから、トリガーを作成するリージョンを選択します。

注: リージョンとして グローバルを選択すると、ビルドの実行にデフォルトのプールが使用されます。それ以外の場合は、トリガーのリージョンのプライベートプールが使用されます。プライベートプールは、ビルド構成ファイルに、またはビルド引数を使用して指定する必要があります。
[リポジトリを接続] をクリックします。
ソースコードを保存したソースリポジトリを選択します。

例: GitHub（Cloud Build GitHub アプリ）
[続行] をクリックします。
ユーザー名とパスワードを使用して、ソースリポジトリに対する認証を行います。

GitHub にログインする場合は、続行するために Google Cloud Build GitHub アプリから GitHub アカウントへのアクセスを承認するように求められます。
使用可能なリポジトリのリストからリポジトリを選択して、[OK] をクリックします。

GitHub や Bitbucket などの外部リポジトリを使用するには、作業中の Google Cloud プロジェクトでオーナーレベルの権限が必要になります。
同意の免責条項を読み、横にあるチェックボックスをオンにして、利用規約に同意することを表明します。
[Connect] をクリックします。
リポジトリのソースコードのビルドを自動化するビルドトリガーの作成を続けるには、[トリガーを作成する] をクリックします。それ以外の場合は [完了] をクリックします。

Cloud Build 構成ファイルを作成する

ビルド構成ファイルでは、ビルドトリガーを使用してビルドを開始する際に必要となるフィールドを定義します。プロジェクトのルートディレクトリに構成ファイルを作成し、YAML または JSON のいずれかを使用して記述します。

たとえば、次の構成ファイルでは、テストワークフローをデプロイして実行し、スクリプトを使用して出力を確認します。テストに合格すると、ワークフローがデプロイされます。

steps:
# Deploy the test workflow with the commit sha
- id: 'deploy-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--source', 'gitops/workflow.yaml']

# Run the test workflow and capture the output
- id: 'run-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'gcloud workflows run $_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA > /workspace/testoutput.log']

# Delete the test workflow
- id: 'delete-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'delete', '$_WORKFLOW_NAME-$BRANCH_NAME-$SHORT_SHA', '--quiet']

# Check the test output
- id: 'check-test-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['gitops/test-$BRANCH_NAME.sh']

# Deploy the workflow
- id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', '$_WORKFLOW_NAME-$BRANCH_NAME', '--source', 'gitops/workflow.yaml']

Git リポジトリからビルドがトリガーされると、Cloud Build によって、$BRANCH_NAME と $SHORT_SHA の置換変数が設定されます。置換変数は、ブランチ名、およびビルドに関連付けられた commit ID の最初の 7 文字を表します。

$_WORKFLOW_NAME 置換変数を使用すると、別の変数値で構成ファイルを再利用できます。この値は、ビルドトリガーの作成時に指定できます。

詳細については、ビルド構成ファイルを作成するをご覧ください。

ビルドトリガーを作成する

Cloud Build トリガーを作成すると、ワークフローのデプロイを自動化できます。

前のセクションの構成ファイルのビルドトリガーを作成するには:

Google Cloud コンソールで、[Cloud Build トリガー] ページに移動します。

[トリガー] に移動
[トリガーを作成] をクリックします。
[名前] 欄にトリガーの名前を入力します。
[イベント] で、トリガーを呼び出すイベントを選択します。

例: ブランチに push する
[ソース] で、トリガーを開始するリポジトリとブランチまたはタグ名を選択します。正規表現を使用して、ブランチまたはタグとの照合を指定できます。

例: GoogleCloudPlatform/workflows-demos（リポジトリ）と ^main$|^staging$（main ブランチと staging ブランチと一致）
[含まれるファイルと無視されるファイルフィルタを表示] セクションを展開し、含まれるファイルとしてワークフローを指定すれば、ワークフローが変更されたときにビルドが呼び出されます。

例: gitops/workflow.yaml
[構成] で、タイプとして [Cloud Build 構成ファイル（YAML または JSON）] を選択し、ロケーションとして [リポジトリ] を選択します。
[Cloud Build 構成ファイルの場所] フィールドに、ファイルの場所を指定します。

例: gitops/cloudbuild.yaml
必要に応じて、置換変数を追加するには、[変数を追加] をクリックしてキーと値の組み合わせを指定します。

例: _WORKFLOW_NAME（変数）や workflows-gitops（値）
ビルドトリガーを保存するには、[作成] をクリックします。

Git リポジトリの指定されたブランチ内のワークフローに変更が push されると、ワークフローをデプロイするために Cloud Build が自動的にトリガーされます。

詳細については、ビルドトリガーを作成して管理するをご覧ください。

ビルドトリガーをテストする

前のセクションのビルドトリガーと構成ファイルをテストできます。

Git リポジトリの staging ブランチで workflow.yaml を編集し、Hello World を Bye World に変更します。

main:
  steps:
    - init:
        assign:
          - message: "Hello World"
    - returnResult:
        return: ${message}

staging ブランチへの変更を commit し、push します。
```
git add workflow.yaml
git commit -m "Update workflow.yaml in staging"
git push
```
Cloud Build トリガーがビルドを実行し、開始します。
ビルドが成功したことを確認するには、Google Cloud コンソールで [ビルド履歴] ページに移動します。

[ビルド履歴] に移動

ビルドの完了後、Cloud Build はビルド全体と個々のビルドステップの全体的なステータスを表示します。詳細については、ビルド結果を表示するをご覧ください。
ステージングワークフローがデプロイされていることを確認するには、Google Cloud コンソールで [ワークフロー] ページに移動します。

[ワークフロー] に移動

workflows-gitops-staging という名前のワークフローが表示されます。

ステージングワークフローを本番環境にデプロイするには、staging ブランチを main ブランチにマージします。

git checkout main
git merge staging
git push

test-main.sh はワークフローの出力で Hello World を想定しているため、ビルドは失敗します。

RESULT_EXPECTED="result: '\"Hello World\"'"
RESULT_ACTUAL=$(grep "result: " $FILE)
if [[ $RESULT_EXPECTED == $RESULT_ACTUAL ]]; then
  echo "Result test passed"
else
  echo "Result test failed. Expected: $RESULT_EXPECTED Actual: $RESULT_ACTUAL"; exit 1;
fi

本番環境ワークフローを正常にデプロイするには、staging ブランチで workflow.yaml を再度編集し、文字列を Hello World に戻します。
staging ブランチに変更を commit して push し、staging ブランチを main ブランチにマージします。
本番環境ワークフローがデプロイされていることを確認するには、Google Cloud コンソールで [ワークフロー] ページに移動します。

[ワークフロー] に移動

workflows-gitops-main という名前のワークフローが表示されます。

次のステップ

Cloud Build の詳細を確認する
ビルドエラーをトラブルシューティングする方法について学習する。
ワークフローのトラブルシューティングの方法を学習する。