Infrastructure as Code の推奨事項の使用

概要

Google Cloud Policy Intelligence によって、企業によるポリシーの把握と管理が容易になり、リスクが軽減されます。可視性が高まり、自動化が進むことで、お客様がワークロードを増やさずにセキュリティを強化できるようにします。

Recommender を使用すると、Google Cloud リソースに対する推奨事項を取得でき、クラウドセキュリティの改善や費用の削減などが促進されます。サポートされている推奨事項の一覧については、Recommender のドキュメントをご覧ください。このチュートリアルでは、VM インスタンスの推奨サイズ提案と Identity and Access Management（IAM）の推奨事項の使用について説明します。Recommender は、機械学習を使用して、Google Cloud リソースへの不要なアクセス権を排除する推奨事項や、リソース利用の効率化を図るために Compute Engine インスタンスをサイズ変更する推奨事項を管理者に提供します。

各推奨事項には、推奨されるアクションとその影響が含まれます。適用する推奨事項は、特定された効果および環境固有の他の考慮事項に関する確認を行った後、選択できます。推奨事項は、Google Cloud コンソールで手動で適用することも、Infrastructure as Code（IaC）パイプラインに統合してプログラムで適用することもできます。

IaC を使用すると、Google Cloud リソースの作成を自動化できます。IaC リポジトリを最新の状態に保ち、発生した変更をそのリポジトリを介して Google Cloud 組織に転送する必要があります。組織の IaC 戦略は、それが厳格に実装され、クラウドインフラストラクチャの信頼できる唯一のバージョンとして提供される場合に、メリットをもたらすことが一般的に実証されています。IaC リポジトリを最新状態に保つことは、IaC リポジトリを反映するインフラストラクチャのバージョンと組織にあるバージョンとの間のズレを防ぐために極めて重要です。

IAM の推奨事項

他のベストプラクティスとして一般的なものは、最小権限のセキュリティ原則と、組織に対する変更のロールアウトと IaC リポジトリとの同期の方法を慎重に検討することがあげられます。

VM のサイズ変更の推奨事項

サイズ変更の推奨事項では、インスタンスのマシンタイプをサイズ変更してインスタンスのリソースを効率的に使用するための提案を提供することで、コストの削減を促進します。

このチュートリアルでは、Policy Intelligence の推奨事項をプログラムで適用する自動化パイプラインを設計して構築する方法について説明します。この自動化パイプラインの中では、Recommender によって生成された VM サイズ変更と IAM ポリシーバインディングの推奨事項に基づいて Google Cloud 組織に加える変更を決め、それを使用して IaC リポジトリを最新状態に保つ方法について学習します。

このチュートリアルでは、IaC ツールとして Hashicorp Terraform を使用しますが、別の IaC 管理ツール（Deployment Manager など）を使用する場合でも、前述の自動化パイプラインで使用するアーキテクチャパターンとコンポーネントを使用できます。このチュートリアルで利用するオープンソースのコードベースは、具体的な IaC 実装に合わせて変更する必要があります。

このガイドは、Google Cloud の管理、セキュリティ、インフラストラクチャ計画を担当する可能性があるアーキテクト、プロダクトオーナー、デベロッパーを対象としています。

オートメーションパイプラインのアーキテクチャ

次の図は、このオートメーションパイプラインで使用する各コンポーネントを示しています。

オートメーションパイプラインのコンポーネント

スケジュール設定された Cloud Scheduler ジョブでは、recommender-parser サービスを実行します。このサービスは、Recommender API を呼び出して、指定されたプロジェクトに対する Recommender の推奨事項を取得します。次に、これらの VM のサイズ設定と IAM の推奨事項を解析し、Terraform マニフェスト内の構成にマッピングします。同サービスにより、IaC マニフェストが更新され、これらの推奨事項が反映されます。また、更新を確認できるように、変更を含む pull リクエストも生成します。pull リクエストを確認してマージすると、Cloud Build ジョブによって Google Cloud 組織内のインフラストラクチャに変更がロールアウトされます。

パイプラインでは、処理済みの最適化案のトラッキング、ビルド完了時の通知の生成、Terraform の状態の保存のために、いくつかの補助的な Google Cloud サービスが使用されます。このチュートリアルでは、これらのサービスについて詳しく説明します。

各コンポーネントの目的とアクセス制御の要件は、以下のとおりです。

Platform Intelligence Recommender

目的: セキュリティと VM サイズ変更の推奨事項を生成します。

アクセス制御: Google Cloud サービスアカウントには、Recommender API を使用して推奨事項を取得するために必要な IAM 権限を付与する必要があります。

Recommender のロールと権限を確認し、recommender-parser サービスの実行に使用するサービスアカウントに最も適したロールを選択します。

Cloud Scheduler

目的: Cloud Scheduler は、recommender-parser サービスをトリガーします。Cloud Scheduler を使用すると、recommender-parser サービスのインスタンスを必要なだけ呼び出す複数のジョブを設定できます。各呼び出しでは、次の入力を渡す必要があります。

推奨事項を処理するプロジェクトのリスト
推奨事項のタイプ
IaC リポジトリ名

アクセス制御: Cloud Scheduler から recommender-parser サービスへの呼び出しに使用する Google Cloud サービスアカウントを作成するか指定します。

そのサービスアカウントには、Cloud Scheduler サービスエージェントのロールを付与して、Cloud Scheduler ジョブを実行できるようにします。さらに、そのアカウントで Cloud Run サービスを呼び出すため、サービスアカウントに Cloud Run 起動元ロールを付与します。

詳細については、Scheduler ジョブに対する認証済みアクセスの構成に関するドキュメントをご覧ください。

Cloud Run サービス

目的: recommender-parser サービスの処理コードは、すべてこの中で動作します。ルートが複数あり、それぞれが特定の目的を処理します。

推奨事項タイプそれぞれに対して推奨事項を解析します。
処理中の推奨事項のステータスを更新します。

アクセス制御: このサービスへのアクセスは、IAM で管理します。

さらに、サービスを専用のサービスアカウントに割り当てます。これにより、Firestore などの他のサービスを、そのサービスからのみ呼び出せるようになります。

HashiCorp Terraform

目的: Terraform 0.12 は IaC ツールです。

Terraform 用の Cloud Build ビルダーは Terraform コマンドを呼び出すために使用され、Cloud Build サービスアカウントがこのために使用されます。

Cloud Build

目的: Google Cloud Build は、ポリシーインテリジェンスの推奨事項に沿って IaC マニフェストに加えた変更に基づいてインフラストラクチャのデプロイを自動化します。

アクセス制御: Cloud Build サービスアカウントには、テストプロジェクト内のリソースを操作するための適切な一連の権限が必要です。

Cloud Build サービスアカウントの構成に関するドキュメントをご覧ください。

GitHub

目的: IaC リポジトリでは、ソース管理に GitHub を使用します。GitHub の IaC リポジトリは、Cloud Build と統合されています。マスターブランチに対して commit が行われると、Cloud Build ジョブがトリガーされ、事前構成された一連のタスクが実行されます。

アクセス制御: IaC リポジトリへのアクセスを有効にするには、SSH 認証鍵を生成する必要があります。

さらに、GitHub に commit を push するには、個人用のアクセストークンを生成する必要があります。

Firestore

Firestore は、スケーラブルなフルマネージドの NoSQL ドキュメントデータベースで、このアーキテクチャでは、recommender-parser サービスによって解析される推奨事項 ID に関する情報と、Git commit に関連する対応する詳細情報を保持するために使用されます。

Firestore に保持される詳細情報は、エンドツーエンドのパイプラインの一部であるフィードバックループにおいて不可欠な役割を担います。Parser サービスは、Recommender API により生成された推奨事項を受け取ると、推奨事項の状態を CLAIMED に設定した後、推奨事項を処理します。同サービスは、推奨事項が正常に適用されると、データベースに対してクエリを実行して、Cloud Build ジョブによって正常に適用された推奨事項 ID を取得し、推奨事項の状態を SUCCEEDED に変更します。Cloud Build ジョブが失敗した場合、推奨事項の状態は FAILED に変更されます。

アクセス制御: 詳細については、Firestore のロールをご覧ください。recommender-parser サービスは Firestore からデータを読み取ります。そのためには、roles/datastore.user ロールが必要です。

Pub/Sub

目的: Cloud Build は、ビルドが作成されたとき、ビルドが作業状態に移行したとき、ビルドが完成したときなど、ビルドの状態が変化したときに、Pub/Sub トピックにメッセージをパブリッシュします。

Cloud Build がメッセージをパブリッシュする Pub/Sub トピックは cloud-builds と呼ばれ、プロジェクトで Cloud Build API を有効にするときに自動的に作成されます。

アクセス制御: push サブスクリプションは、サービスがリクエストを承認するための認証ヘッダーを提供するように構成できます。詳細については、push サブスクリプションの使用をご覧ください。

目標

次のことを行う自動化パイプラインを構築する。
- プラットフォームの Policy Intelligence に関する推奨事項をプロアクティブにモニタリングする。
- 推奨事項を解析し、既存の IaC リポジトリに更新を適用する。
Google Cloud サービスのスイートである Hashicorp Terraform および GitHub を使用して、このパイプラインを構築する方法を学習する。
このパイプラインを構築するために留意すべき前提条件とベストプラクティスを理解する。
パイプラインをテストする

費用

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

Cloud Run
Cloud Build
Compute Engine
Cloud Storage
Firestore
Pub/Sub
Cloud Scheduler
Recommender

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

このチュートリアルは、ユーザーが GitHub アカウントを持ち、Git、Node.js、Terraform、Docker に慣れていることを前提としています。

リリースノートと前提事項

IaC ツールとマニフェストには、非常に多くの使用方法があります。

次の情報を確認し、このチュートリアルが自身の IaC パイプラインに適合するか、どのような変更が必要かを判断してください。

このパイプラインでは、Terraform ver. 0.12 を使用します。HCL 構成構文における大幅な変更や、Terraform 状態ファイルの構造の変更によって、問題が発生する可能性があります。
このパイプラインは、IaC ディレクトリ構造がネストされておらず、1 つの IaC リポジトリが 1 つ以上の Google Cloud プロジェクトのリソースを管理することを前提としています。
環境変数で渡される Terraform 変数、コマンドライン引数はサポートされていません。このプロトタイプでは、Terraform 変数は、tfvars ファイル内で宣言により構成されることを前提としています。
Recommender では、ロールの権限の一部が 60 日間使用されていない場合に IAM の推奨事項を生成します。また、VM サイズ変更の推奨事項についても同様です。このチュートリアルでは、パイプラインのテストに使用できるサンプルの推奨ペイロードが用意されています。
このリリースでは、Terraform 内のループはサポートされていません
Terraform モジュールは、サポートされていません。コードベースはオープンソースであり、解析フローは、ディレクトリ構造とモジュールの使用方法に合わせ、必要に応じて個別に拡張することが想定されます。

現在のバージョンのオープンソース recommender-parser サービスは、IAM 推奨事項についての以下の既知の制限に対応しています。

次の Cloud IAM ポリシーバインディングだけが、推奨事項の対象になります。
- プロジェクトレベルのポリシーバインディング
- ユーザーアカウントとユーザー管理サービスアカウントに関連付けられているポリシーバインディング
IAM の推奨事項では、基本ロールと事前定義ロールのみがサポートされます。カスタムロールと条件付きバインディングは、評価や推奨の対象になりません。
推奨されるロールには、現在のロールの権限のサブセットのみが含まれます。推奨されるロールによって新しい権限が追加されることはありません。

前提条件

2 つの Google Cloud プロジェクトを選択または作成します。
[プロジェクトの選択] ページに移動
- 自動化パイプラインをホストして実行するビルド プロジェクト。
- 自動化パイプラインのテストに使用される Google Cloud リソースをホストする テスト プロジェクト。
Make sure that billing is enabled for your Google Cloud project.
test プロジェクトで、Recommender と Compute Engine API を有効にします。

Enable the APIs
ビルド プロジェクトで、Cloud Run、Firestore、Pub/Sub と Cloud Scheduler、IAM、CloudResourceManager API を有効にします。

Enable the APIs

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

環境の設定

Google Cloud コンソールで、build プロジェクトを選択します。
Google Cloud コンソールで、Cloud Shell に移動します。
Cloud Shell に移動

Google Cloud コンソールの下部で Cloud Shell セッションが開き、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

このチュートリアルでは、すべてのターミナルコマンドに Cloud Shell を使用します。
次のコマンドを使用して、build プロジェクトのプロジェクト番号を保持する環境変数を作成します。
```
export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID
```
test プロジェクトのプロジェクト番号を保持する環境変数を作成します。PROJECT-ID は、手動でテストプロジェクト ID をコピーして置き換えます。
```
export TEST_PROJECT_ID=PROJECT-ID
```
このチュートリアル全体で使用される値（リージョンやゾーンなど）には、デフォルト設定を割り当てます。このチュートリアルでは、デフォルトのリージョンとして us-central1 を使用し、デフォルトのゾーンとして us-central1-b を使用します。

次のコマンドを実行して、このチュートリアルのデフォルトのリージョンとゾーンを設定します。

gcloud config set compute/zone us-central1-b --project $BUILD_PROJECT_ID
gcloud config set compute/zone us-central1-b --project $TEST_PROJECT_ID

build プロジェクトをデフォルトプロジェクトとして設定します。
```
gcloud config set project $BUILD_PROJECT_ID
```

build プロジェクト番号用に BUILD_PROJECT_NUMBER という環境変数を作成します。

export BUILD_PROJECT_NUMBER=$(gcloud projects describe $DEVSHELL_PROJECT_ID --format='value(projectNumber)')

このチュートリアル用に GitHub リポジトリのクローンを作成します。
注: 特に指定がない限り、このチュートリアルのすべてのコマンドは、Cloud Shell で実行します。

Terraform の状態用バケットの作成

ビルドプロジェクトで Cloud Storage バケットを作成し、Terraform の状態ファイルを保存します。

gcloud storage buckets create gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --project=${BUILD_PROJECT_ID} --location=us-central1

GitHub リポジトリの作成

サンプルの IaC リポジトリとして機能する GitHub リポジトリを作成します。

新しいプライベート GitHub リポジトリを作成します。このチュートリアルでは、この IAC-REPO-NAME リポジトリは IaC リポジトリとして機能します。
以降の手順では、クローンされたリポジトリの sample-iac サブディレクトリ内のファイルを GitHub アカウントに push します。
1. Cloud Shell で、sample-iac ディレクトリをホームディレクトリにコピーします。このディレクトリを使用して新しいローカルリポジトリを作成し、それを GitHub に push します。
```
cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
```
2. この新しいディレクトリに移動します。
```
cd $HOME/sample-iac
```
3. ローカルマシンでリポジトリを初期化します。
```
git init
```
4. IAC-REPO-NAME をリモートリポジトリとして追加します。IAC-REPO-NAME と GITHUB-ACCOUNT は、適切な値に置き換えます。
```
git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME
```
5. このリポジトリで、ファイル内のプレースホルダを test プロジェクト ID と Terraform Cloud Storage バケット名に置き換えます。
```
sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./terraform.tfvars

sed -i "s|__STATE_BUCKET_NAME__|recommender-tf-state-$BUILD_PROJECT_ID|g" ./backend.tf
```
6. GitHub に add、commit、push します。
```
git add .
git commit -m "First Commit"
git push origin master
```
7. 表示された指示に従って、GitHub アカウントにログインします。

リポジトリの SSH 認証鍵の生成

GitHub で IaC リポジトリを使用して SSH 認証鍵認証を設定し、鍵を Cloud Storage にアップロードします。

GitHub リポジトリの SSH 認証鍵を生成します。
1. SSH 認証鍵ペアを生成します。your_email@example.com は、GitHub メールアドレスに置き換えます。Cloud Shell で次を処理します。
```
ssh-keygen -t rsa -b 4096 -m PEM -C "your_email@example.com"
```
2. 「鍵を保存するファイルを入力してください」というメッセージが表示されたら、Enter キーを押します。これでデフォルトのファイルの場所が指定されます。
3. パスフレーズの入力を求めるメッセージが出力されたら、Enter キーを押します。
ダウンロードした SSH 認証鍵を保存するディレクトリ SSH-KEYS-DIR をメモします。デフォルトの場所は、$HOME/.ssh/ です。
生成された SSH 公開鍵を、デプロイキーとして GitHub リポジトリにコピーします。
1. Cloud Shell で生成した SSH 公開鍵をコピーします。SSH-KEYS-DIR は、ディレクトリパスに置き換えます。
```
cat SSH-KEYS-DIR/id_rsa.pub
```
2. GitHub アカウントで、IAC-REPO-NAME リポジトリに移動します。
3. [Settings] > [Deploy keys] をクリックします。
4. [Add deploy key] をクリックして、コピーした SSH 公開鍵を貼り付けます。キーの [Title] を入力します。
5. [Allow write access] チェックボックスをオンにします。
6. [Save] をクリックします。
Cloud Shell セッションに戻ります。
GitHub 用の known_hosts ファイルを作成します。Cloud Shell セッションで、次のコマンドを実行します。
```
ssh-keyscan github.com >> ~/.ssh/known_hosts
```

build プロジェクトに Cloud Storage バケットを作成し、SSH 認証鍵と known_hosts ファイルをアップロードします。SSH-KEYS-DIR は、SSH 認証鍵を生成したディレクトリのパスに置き換えます。

gcloud storage buckets create gs://github-keys-$BUILD_PROJECT_ID --project=${BUILD_PROJECT_ID} --location=us-central1

gcloud storage cp SSH-KEYS-DIR/id_rsa* gs://github-keys-$BUILD_PROJECT_ID
gcloud storage cp SSH-KEYS-DIR/known_hosts gs://github-keys-$BUILD_PROJECT_ID

GitHub 用の個人アクセストークンを生成します。このトークンは、API 呼び出しを使用して Git オペレーションを実行するときに使用され、そのオペレーションでは、recommender-parser サービスが pull リクエストを生成し、更新された IaC マニフェストをチェックインします。
1. GitHub アカウントで、ページの右上にあるプロフィール写真をクリックし、つづいて [Settings] をクリックします。
2. 左側のサイドバーで [Developer settings] をクリックします。
3. 左側のサイドバーで [Personal access tokens] をクリックします。
4. [Generate new token] をクリックします。
5. トークンにわかりやすい名前を付けます。
6. [Select scopes] で、[repo] を選択します。
7. [Generate token] をクリックします。
8. トークンをクリップボードにコピーします。
9. Cloud Shell セッションで、環境変数を作成します。
```
export GITHUB_PAT=personal-access-token-you-copied
```

Cloud Build の設定

IAC-REPO-NAME Git リポジトリを接続し、Cloud Build と統合します。
1. GitHub Marketplace の Cloud Build App ページに移動します。
2. 下にスクロールし、ページ下部にある [Setup with Google Cloud Build] をクリックします。
3. 表示された指示に沿って、GitHub にログインします。
4. [Only select repositories] を選択します。[Select repositories] プルダウンリストを使用して、Cloud Build アプリで IAC-REPO-NAME へのアクセスのみを有効にします。
5. [Install] をクリックします。
6. Google Cloud にログインします。
  
  認可ページが表示されます。ここで、Google Cloud Build アプリが Google Cloud に接続するのを認可するよう求められます。
7. [Authorize Google Cloud Build by GoogleCloudBuild] をクリックします。Google Cloud コンソールにリダイレクトされます。
8. Google Cloud プロジェクトを選択します。
9. 同意のチェックボックスをオンにして、[次へ] をクリックします。
10. [リポジトリの選択] ページが表示されたら、IAC-REPO-NAME GitHub リポジトリを選択します。
11. [リポジトリを接続] をクリックします。
12. [トリガーを作成する] をクリックします。これにより、トリガーの定義が作成されます。
13. [作成] をクリックして、ビルドトリガーを保存します。
詳細については、GitHub でのビルドの実行をご覧ください。
コピーしたディレクトリには、cloudbuild.yaml ファイルがあります。この構成ファイルには、Cloud Build ジョブがトリガーされたときに実行されるステップの概要が記載されています。
```
steps:
- name: hashicorp/terraform:0.12.0
  args: ['init']
- name: hashicorp/terraform:0.12.0
  args: ['apply', '-auto-approve']
```

Cloud Build サービスアカウントに権限を追加して、サービスアカウント、関連するロール、テストプロジェクト内の仮想マシン（Compute Engine インスタンス）の作成を許可します。

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role roles/compute.admin \
  --project $TEST_PROJECT_ID

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
  --role roles/iam.serviceAccountAdmin \
  --project $TEST_PROJECT_ID

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
--member serviceAccount:$BUILD_PROJECT_NUMBER@cloudbuild.gserviceaccount.com \
--role roles/iam.securityAdmin \
--project $TEST_PROJECT_ID

Google Cloud コンソールで Cloud Build の [トリガー] ページを開きます。
[build] プロジェクトを選択し、[開く] をクリックします。
トリガーの定義を更新します。
1. メニューをクリックし、[編集] をクリックします。
2. [構成] で [Cloud Build 構成ファイル（yaml または json）] オプションを選択し、テキストフィールドに「cloudbuild.yaml」と入力します。
3. [保存] をクリックします。
ビルドトリガーを手動でテストするには、トリガーリスト中の作成したトリガーの行で [実行] をクリックします。
tf-compute-1 という Compute Engine インスタンスと Terraform Recommender Test というサービスアカウントが、前の手順で実行した Cloud Build ジョブにより、テストプロジェクト内に作成されることを確認します。

recommender-parser Cloud Run サービスのデプロイ

Cloud Shell で、リポジトリのクローンとして作成されたディレクトリに移動します。
```
cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service
```
Cloud Run サービスのデフォルトリージョンを使用するように Google Cloud を構成します。このチュートリアルでは、us-central1 リージョンを使用しますが、サポートされている別のリージョンを選択することもできます。
```
gcloud config set run/region us-central1
```
parser-service ディレクトリには、スタブサブディレクトリがあり、その中には recommender-parser サービスをテストするためのサンプルペイロード JSON がいくつかあります。次の sed コマンドを実行して、これらの JSON の PROJECT_ID プレースホルダをテストプロジェクト ID に置き換えます。
```
sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/iam.json
sed -i "s|__PROJECT_ID__|${TEST_PROJECT_ID}|g" ./stub/vm.json
```
次のコマンドを実行して、Docker イメージ用の環境変数を作成します。
```
export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0
```
イメージをビルドして、Container Registry にアップロードします。
```
gcloud builds submit --tag $IMAGE .
```
パイプライン内の他の Google Cloud サービスとやり取りする recommender-parser サービス用のサービスアカウントを作成します。Cloud Run サービスには、細分化した権限を付与することをおすすめします。詳細については、Cloud Run サービス ID をご覧ください。
```
gcloud beta iam service-accounts create recommender-parser-sa \
  --description "Service account that the recommender-parser service uses to invoke other Google Cloud services" \
  --display-name "recommender-parser-sa" \
  --project $BUILD_PROJECT_ID
```

recommender-parser サービスは、先に作成した Cloud Storage バケットにアップロードした GitHub SSH 認証鍵と Terraform の状態にアクセスする必要があります。サービスアカウントをメンバーとして Cloud Storage バケットに追加します。

gcloud storage buckets add-iam-policy-binding gs://github-keys-$BUILD_PROJECT_ID \
  --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectUser

gcloud storage buckets add-iam-policy-binding gs://recommender-tf-state-$BUILD_PROJECT_ID \
  --member=serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/storage.objectUser

recommender-parser サービスのサービスアカウントに、Firestore、Recommender、Service Usage API へのアクセス権を付与します。

gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
  --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/datastore.user

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/recommender.iamAdmin

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/recommender.iamViewer

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/recommender.computeAdmin

gcloud projects add-iam-policy-binding $TEST_PROJECT_ID \
  --member serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/serviceusage.serviceUsageConsumer

次のコマンドを実行して、Cloud Run サービス（recommender-parser）をデプロイします。GITHUB-ACCOUNT は、メールアドレスではなく GitHub アカウントのユーザー名に置き換えます。システムからのメッセージは、すべて受け入れます。

gcloud run deploy \
 --image=${IMAGE} \
 --no-allow-unauthenticated \
 --region us-central1 \
 --platform managed \
 --service-account recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
 --set-env-vars="GITHUB_ACCOUNT=github.com:GITHUB-ACCOUNT,GITHUB_PAT=${GITHUB_PAT},SSH_KEYS_BUCKET=github-keys-${BUILD_PROJECT_ID},TERRAFORM_STATE_BUCKET=recommender-tf-state-$BUILD_PROJECT_ID" \
 --project $BUILD_PROJECT_ID \
 recommender-parser

Firestore の設定

Google Cloud Console で、build プロジェクトの Firestore ページに移動します。
モードの選択を求められた場合は、[ネイティブモードに切り替える] をクリックします。
デフォルトのロケーションとして us-east1 を選択します。
[データベースを作成] をクリックします。

recommender-parser サービスは、次の目的でこのデータベースにドキュメントを書き込みます。

Recommender API から取得した推奨事項を追跡する。
推奨事項が処理されたら、Recommender API を呼び出して、処理された各推奨事項のステータスを SUCCEEDED または FAILED に適宜更新する。これは、推奨事項が不完全に処理されることや、複数回処理されることを防ぐことにより、パイプラインをべき等にする重要なステップです。

Cloud Scheduler ジョブの設定

Cloud Scheduler ジョブが recommender-parser サービスを実行するために使用するサービスアカウントを作成します。

gcloud beta iam service-accounts create recommender-scheduler-sa \
  --description "Service Account used by Cloud Scheduler to invoke the recommender-parser service" \
  --display-name "recommender-scheduler-sa" \
  --project $BUILD_PROJECT_ID

Cloud Run サービスを呼び出すことができるように、サービスアカウントに Cloud Run 起動元ロールを付与します。

gcloud beta run services add-iam-policy-binding recommender-parser \
--member=serviceAccount:recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
--role=roles/run.invoker \
--region=us-central1

recommender-service の URL を取得します。
```
gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID
```
Cloud Scheduler ジョブは、recommender-parser サービスの /recommendation/iam ルートを呼び出して IAM 推奨事項を解析し、/recommender/vm ルートを呼び出して VM サイズ変更の推奨事項を解析します。
Cloud Scheduler ジョブが呼び出すエンドポイントの変数を作成します。RECOMMENDER-SERVICE-URL は、前の手順でコピーした recommender-service の URL に置き換えます。
```
export RECOMMENDER_ROUTE_TO_INVOKE_IAM=RECOMMENDER-SERVICE-URL/recommendation/iam
```
ルート情報を追加した後の URL は、次のサンプル URL のような形になります。
```
RECOMMENDER-SERVICE-URL/recommendation/iam
```
recommender-iam-scheduler. という名前の Cloud Scheduler ジョブを作成します。
- タイムゾーンは、設定したロケーションに基づいて変更します。
- IAC-REPO-NAME は、作成した GitHub リポジトリの名前に置き換えます。
メッセージ本文には 3 つの入力が必要で、次のように作成する必要があります。
- repo: GitHub リポジトリの作成で作成した GitHub リポジトリ IAC-REPO-NAME の名前です。
- projects: この IaC GitHub リポジトリがマッピングする Google Cloud プロジェクト ID のリスト / 配列。このチュートリアルでは、test プロジェクトです。
- stub: Recommender では、ロールの権限の一部が 60 日間使用されていない場合に IAM の推奨事項を生成します。また、VM サイズ変更の推奨事項についても同様です。このパイプラインをオンデマンドでテストするために、stub を true として渡すことができます。これにより、このチュートリアルでクローン作成したリポジトリに提供されるサンプルの Recommender ペイロードを使用して、パイプラインをテストできます。
```
gcloud beta scheduler jobs create http recommender-iam-scheduler \
  --project $BUILD_PROJECT_ID \
  --time-zone "America/Los_Angeles" \
  --schedule="0 */3 * * *" \
  --uri=$RECOMMENDER_ROUTE_TO_INVOKE_IAM \
  --description="Scheduler job to invoke recommendation pipeline" \
  --oidc-service-account-email="recommender-scheduler-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com" \
  --headers="Content-Type=application/json" \
  --http-method="POST" \
  --message-body="{ \"repo\": \"IAC-REPO-NAME\", \"projects\": [\"$TEST_PROJECT_ID\"], \"location\": \"global\", \"stub\": true }"
```

その他の手順

Cloud Build は、ビルドプロジェクトで Cloud Build API を有効にしたときに自動的に作成された cloud-builds と呼ばれる Pub/Sub トピックにビルド情報を公開します。

次のコマンドを実行して、build プロジェクトに cloud-builds トピックが存在することを確認します。
```
gcloud pubsub topics describe cloud-builds
```
トピックが存在する場合、次の出力が表示されます。ここで BUILD-PROJECT-ID はビルドプロジェクト ID です。
```
name: projects/BUILD-PROJECT-ID/topics/cloud-builds
```
リソースが見つからないというエラーメッセージが表示された場合は、ビルド通知へのサブスクリプションの手順に沿ってトピックを手動で作成します。

Pub/Sub が recommender-parser サービスエンドポイントを呼び出すために使用するサービスアカウントを作成します。

gcloud beta iam service-accounts create recommender-ci-subscription-sa \
  --description "Service Account used by Cloud Pub/Sub to push Cloud Build events to the recommender-parser service" \
  --display-name "recommender-ci-subscription-sa" \
  --project $BUILD_PROJECT_ID

Pub/Sub サービスアカウントは、メッセージを公開して recommender-parser サービスを開始するために必要なロールと関連付けられる必要があります。

gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
  --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/pubsub.publisher \
  --project $BUILD_PROJECT_ID

gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
  --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/pubsub.subscriber \
  --project $BUILD_PROJECT_ID

gcloud projects add-iam-policy-binding $BUILD_PROJECT_ID \
  --member serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role roles/run.invoker \
  --project $BUILD_PROJECT_ID

作成した recommender-ci-subscription-sa サービスアカウントを、invoker ロールを持つメンバーとして recommender-parser サービスに追加します。

gcloud beta run services add-iam-policy-binding recommender-parser \
  --member=serviceAccount:recommender-ci-subscription-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/run.invoker --region=us-central1

Google Cloud Console で Pub/Sub に移動します。
cloud-builds トピックをクリックします。
[サブスクリプションを作成] をクリックします。
[サブスクリプション ID] に「recommender-service-build-events」と入力します。
[配信タイプ] で、[push] を選択します。
[エンドポイント] には、/ci が付加された recommender-service の URL を入力します。
[認証を有効にする] にチェックを入れます。
1. 作成したサービスアカウント recommender-ci-subscription-sa を選択します。
2. 入力を促すメッセージが表示されたら、[付与] をクリックします。
[確認応答期限] には「60」秒と入力します。
残りはデフォルト値のままににします。
[CREATE] をクリックします。

パイプラインをテストする

Recommender では、ロールの権限の一部が 60 日間使用されていない場合に IAM の推奨事項を生成します。VM サイズ変更の推奨事項についても同様です。このパイプラインをオンデマンドでテストするため、このチュートリアル用にクローン作成したリポジトリの stub サブディレクトリに提供されるサンプルの推奨事項 JSON ペイロードを使用します。これにより、パイプラインをテストして、recommender-parser が Recommender API エンドポイントに対して行う API 呼び出しを抑制し、正常に適用された推奨事項のステータスを更新できます。

また、Google Cloud プロジェクトに有効な推奨事項が存在する場合は、スタブを使用せずに、エンドツーエンドでもパイプラインをテストできます。後述する結果の概要は、パイプラインのテストにサンプルペイロードを使用した場合のものです。ただし、サンプルを使用しない場合も、このパイプラインをテストする手順は変わりません。

Google Cloud コンソールでテストプロジェクトに移動し、作成されたリソースを確認します。次のリソースが必要です。
1. マシンタイプ g1-small を有する tf-compute-1 と呼ばれる Compute Engine インスタンス。
2. テストプロジェクト用に editor のロールを持つ Terraform Recommender Test という名前のサービスアカウント。
build プロジェクトの Cloud Scheduler コンソールのページで、recommender-iam-scheduler ジョブの [今すぐ実行] をクリックします。
ジョブをクリックしてログを表示します。また、recommender-parser サービスログを表示して、サービスによって実行されたステップの詳細を確認することもできます。
サービスの実行が完了したら、GitHub の IAC-REPO-NAME リポジトリに移動します。recommender-parser サービスで、pull リクエストが生成されています。この pull リクエストを構成する変更された IaC マニフェストを確認し、問題がなければ [Merge pull request] をクリックします。

警告: 本番環境では、変更をマージする前に、pull リクエストの人間によるレビューなど、しっかりした承認ワークフローを適用することをおすすめします。レビュー担当者には、推奨事項内に確認される影響に加え、インフラストラクチャやビジネスに固有の影響を評価する知識が必要です。適切な評価を行わずに推奨事項を適用すると、システムパフォーマンスの問題、低い信頼性、必要な権限の不足など、想定外の変化につながる可能性があります。レビュープロセスを設定する手順については、GitHub のドキュメントをご覧ください。
pull リクエストをマージすると、マスターブランチへの新しい commit が作成されます。これにより、test プロジェクト内の Google Cloud リソースに変更をロールアウトする Cloud Build ジョブがトリガーされます。Cloud Build ジョブが完了するまで少し待ちます。ステータスは Google Cloud コンソールで確認できます。

注: DevOps パイプラインを設定するときは、機能的なロールバック戦略を策定することをおすすめします。たとえば、このチュートリアルで構築した自動化パイプラインによってロールアウトされるインフラストラクチャの変更は、以前の Git commit に戻すことでロールバックできます。https://git-scm.com/docs/git-reset コマンドと git revert コマンドの詳細については、この Git ドキュメントをご覧ください。
ジョブが完了したら、テストプロジェクトに移動します。サンプルペイロードにより、テストプロジェクトのリソースは次のように変更されます。
- 前のデプロイでは editor ロールが付与されていた Terraform テストサービスアカウントは、viewer に変更されます。
注: Cloud Scheduler サービスを実行して、/recommendation/vm エンドポイントで VM サイズ変更の推奨事項の解析を呼び出すと、当初は g1-small のマシンタイプだった Compute Engine インスタンス tf-compute-1 が f1-micro に変更されます。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、作成した両方のプロジェクトを削除します。

課金をなくす最も簡単な方法は、チュートリアル用に作成したプロジェクトを削除することです。

プロジェクトを削除するには:

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

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

次のステップ

Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud アーキテクチャセンターを確認します。
Google Cloud Policy Intelligence の詳細をドキュメントで確認する。