概要
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 サブスクリプションの使用をご覧ください。 
このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。
環境の設定
-  Google Cloud コンソールで、buildプロジェクトを選択します。
- Google Cloud コンソールで、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 リポジトリのクローンを作成します。 
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 します。- Cloud Shell で、 - sample-iacディレクトリをホーム ディレクトリにコピーします。このディレクトリを使用して新しいローカル リポジトリを作成し、それを GitHub に push します。- cp -r recommender-iac-pipeline-nodejs-tutorial/sample-iac $HOME
- この新しいディレクトリに移動します。 - cd $HOME/sample-iac
- ローカルマシンでリポジトリを初期化します。 - git init
- IAC-REPO-NAME をリモート リポジトリとして追加します。IAC-REPO-NAME と GITHUB-ACCOUNT は、適切な値に置き換えます。 - git remote add origin https://github.com/GITHUB-ACCOUNT/IAC-REPO-NAME 
- このリポジトリで、ファイル内のプレースホルダを - 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
- GitHub に add、commit、push します。 - git add . git commit -m "First Commit" git push origin master
- 表示された指示に従って、GitHub アカウントにログインします。 
 
リポジトリの SSH 認証鍵の生成
GitHub で IaC リポジトリを使用して SSH 認証鍵認証を設定し、鍵を Cloud Storage にアップロードします。
- GitHub リポジトリの SSH 認証鍵を生成します。 - SSH 認証鍵ペアを生成します。your_email@example.com は、GitHub メールアドレスに置き換えます。Cloud Shell で次を処理します。 - ssh-keygen -t rsa -b 4096 -m PEM -C "your_email@example.com" 
- 「鍵を保存するファイルを入力してください」というメッセージが表示されたら、Enter キーを押します。これでデフォルトのファイルの場所が指定されます。 
- パスフレーズの入力を求めるメッセージが出力されたら、Enter キーを押します。 
 
- ダウンロードした SSH 認証鍵を保存するディレクトリ SSH-KEYS-DIR をメモします。デフォルトの場所は、 - $HOME/.ssh/です。
- 生成された SSH 公開鍵を、デプロイキーとして GitHub リポジトリにコピーします。 - Cloud Shell で生成した SSH 公開鍵をコピーします。SSH-KEYS-DIR は、ディレクトリ パスに置き換えます。 - cat SSH-KEYS-DIR/id_rsa.pub
- GitHub アカウントで、IAC-REPO-NAME リポジトリに移動します。 
- [Settings] > [Deploy keys] をクリックします。 
- [Add deploy key] をクリックして、コピーした SSH 公開鍵を貼り付けます。キーの [Title] を入力します。 
- [Allow write access] チェックボックスをオンにします。 
- [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 マニフェストをチェックインします。 - GitHub アカウントで、ページの右上にあるプロフィール写真をクリックし、つづいて [Settings] をクリックします。 
- 左側のサイドバーで [Developer settings] をクリックします。 
- 左側のサイドバーで [Personal access tokens] をクリックします。 
- [Generate new token] をクリックします。 
- トークンにわかりやすい名前を付けます。 
- [Select scopes] で、[repo] を選択します。 
- [Generate token] をクリックします。 
- トークンをクリップボードにコピーします。 
- Cloud Shell セッションで、環境変数を作成します。 - export GITHUB_PAT=personal-access-token-you-copied 
 
Cloud Build の設定
- IAC-REPO-NAME Git リポジトリを接続し、Cloud Build と統合します。 - GitHub Marketplace の Cloud Build App ページに移動します。
- 下にスクロールし、ページ下部にある [Setup with Google Cloud Build] をクリックします。
- 表示された指示に沿って、GitHub にログインします。
- [Only select repositories] を選択します。[Select repositories] プルダウン リストを使用して、Cloud Build アプリで IAC-REPO-NAME へのアクセスのみを有効にします。
- [インストール] をクリックします。
- Google Cloudにログインします。 - 承認ページが表示され、Google Cloud Build アプリが Google Cloudに接続できるよう承認を求められます。 
- [Authorize Google Cloud Build by GoogleCloudBuild] をクリックします。 Google Cloud コンソールにリダイレクトされます。 
- Google Cloud プロジェクトを選択します。 
- 同意のチェックボックスをオンにして、[次へ] をクリックします。 
- [リポジトリの選択] ページが表示されたら、IAC-REPO-NAME GitHub リポジトリを選択します。 
- [リポジトリを接続] をクリックします。 
- [トリガーを作成する] をクリックします。これにより、トリガーの定義が作成されます。 
- [作成] をクリックして、ビルドトリガーを保存します。 
 - 詳細については、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 コンソールで [ビルドトリガー] ページを開きます。 
- [ - build] プロジェクトを選択し、[開く] をクリックします。
- トリガーの定義を更新します。 - メニューをクリックし、[編集] をクリックします。
- [構成] で [Cloud Build 構成ファイル(yaml または json)] オプションを選択し、テキスト フィールドに「cloudbuild.yaml」と入力します。
- [保存] をクリックします。
 
- ビルドトリガーを手動でテストするには、トリガーリスト中の作成したトリガーの行で [実行] をクリックします。 
- 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 コンソールで、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 コンソールで Pub/Sub に移動します。 
- cloud-builds トピックをクリックします。 
- [サブスクリプションを作成] をクリックします。 
- [サブスクリプション ID] に「 - recommender-service-build-events」と入力します。
- [配信タイプ] で、[push] を選択します。 
- [エンドポイント] には、 - /ciが付加された recommender-service の URL を入力します。
- [認証を有効にする] にチェックを入れます。 - 作成したサービス アカウント recommender-ci-subscription-saを選択します。
- 入力を促すメッセージが表示されたら、[付与] をクリックします。
 
- 作成したサービス アカウント 
- [確認応答期限] には「60」秒 と入力します。 
- 残りはデフォルト値のままににします。 
- [CREATE] をクリックします。 
パイプラインをテストする
Recommender では、ロールの権限の一部が 60 日間使用されていない場合に IAM の推奨事項を生成します。VM サイズ変更の推奨事項についても同様です。このパイプラインをオンデマンドでテストするため、このチュートリアル用にクローン作成したリポジトリの stub サブディレクトリに提供されるサンプルの推奨事項 JSON ペイロードを使用します。これにより、パイプラインをテストして、recommender-parser が Recommender API エンドポイントに対して行う API 呼び出しを抑制し、正常に適用された推奨事項のステータスを更新できます。
また、 Google Cloudプロジェクトに有効な推奨事項が存在する場合は、スタブを使用せずに、エンドツーエンドでもパイプラインをテストできます。後述する結果の概要は、パイプラインのテストにサンプル ペイロードを使用した場合のものです。ただし、サンプルを使用しない場合も、このパイプラインをテストする手順は変わりません。
- Google Cloud コンソールでテスト プロジェクトに移動し、作成されているリソースを確認します。次のリソースが必要です。 - マシンタイプ g1-smallを有するtf-compute-1と呼ばれる Compute Engine インスタンス。
- テスト プロジェクト用に 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 リクエストをマージすると、マスター ブランチへの新しい commit が作成されます。これにより、 - testプロジェクト内の Google Cloud リソースに変更をロールアウトする Cloud Build ジョブがトリガーされます。Cloud Build ジョブが完了するまで少し待つと、 Google Cloud コンソールでステータスを確認できます。
- ジョブが完了したら、テスト プロジェクトに移動します。サンプル ペイロードにより、テスト プロジェクトのリソースは次のように変更されます。 - 前のデプロイでは editorロールが付与されていた Terraform テスト サービス アカウントは、viewerに変更されます。
 
- 前のデプロイでは