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 を使用しますが、Deployment Manager などの別の IaC 管理ツールを使用する場合でも、自動化パイプラインで使用するアーキテクチャ パターンとコンポーネントを利用できます。このチュートリアルで利用するオープンソースのコードベースは、具体的な 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 推奨事項についての以下の既知の制限に対応しています。

前提条件

  1. 2 つの Google Cloud プロジェクトを選択または作成します。

    [プロジェクトの選択] ページに移動

    • 自動化パイプラインをホストして実行するビルド プロジェクト。
    • 自動化パイプラインのテストに使用される Google Cloud リソースをホストするテスト プロジェクト。

  2. Google Cloud プロジェクトで課金が有効になっていることを確認します。

  3. test プロジェクトで、Recommender と Compute Engine API を有効にします。

    API を有効にする

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

    API を有効にする

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

環境の設定

  1. Google Cloud コンソールで、build プロジェクトを選択します。

  2. Google Cloud コンソールで、Cloud Shell に移動します。

    Cloud Shell に移動

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

    このチュートリアルでは、すべてのターミナル コマンドに Cloud Shell を使用します。

  3. 次のコマンドを使用して、build プロジェクトのプロジェクト番号を保持する環境変数を作成します。

    export BUILD_PROJECT_ID=$DEVSHELL_PROJECT_ID

  4. test プロジェクトのプロジェクト番号を保持する環境変数を作成します。PROJECT-ID は、手動でテスト プロジェクト ID をコピーして置き換えます。

    export TEST_PROJECT_ID=PROJECT-ID

  5. このチュートリアル全体で使用される値（リージョンやゾーンなど）には、デフォルト設定を割り当てます。このチュートリアルでは、デフォルトのリージョンとして us-central1 を使用し、デフォルトのゾーンとして us-central1-b を使用します。

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

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

  7. build プロジェクトをデフォルト プロジェクトとして設定します。

    gcloud config set project $BUILD_PROJECT_ID

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

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

  9. このチュートリアル用に GitHub リポジトリのクローンを作成します。

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

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

gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 \
 gs://recommender-tf-state-$BUILD_PROJECT_ID

GitHub リポジトリの作成

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

  1. 新しいプライベート GitHub リポジトリを作成します。このチュートリアルでは、この IAC-REPO-NAME リポジトリは IaC リポジトリとして機能します。

  2. 以降の手順では、クローンされたリポジトリの 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 にアップロードします。

  1. 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 キーを押します。

  2. ダウンロードした SSH 認証鍵を保存するディレクトリ SSH-KEYS-DIR をメモします。デフォルトの場所は、$HOME/.ssh/ です。

  3. 生成された 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] をクリックします。

  4. Cloud Shell セッションに戻ります。

  5. GitHub 用の known_hosts ファイルを作成します。Cloud Shell セッションで、次のコマンドを実行します。

    ssh-keyscan github.com >> ~/.ssh/known_hosts

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

    gsutil mb -p ${BUILD_PROJECT_ID} -l us-central1 gs://github-keys-$BUILD_PROJECT_ID

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

  7. 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 の設定

  1. 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 でのビルドの実行をご覧ください。

  2. コピーしたディレクトリには、cloudbuild.yaml ファイルがあります。この構成ファイルには、Cloud Build ジョブがトリガーされたときに実行されるステップの概要が記載されています。

    steps:
- name: hashicorp/terraform:0.12.0
  args: ['init']
- name: hashicorp/terraform:0.12.0
  args: ['apply', '-auto-approve']

  3. 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

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

  5. [build] プロジェクトを選択し、[開く] をクリックします。

  6. トリガーの定義を更新します。

    1. メニューをクリックし、[編集] をクリックします。
    2. [構成] で [Cloud Build 構成ファイル（yaml または json）] オプションを選択し、テキスト フィールドに「cloudbuild.yaml」と入力します。
    3. [保存] をクリックします。

  7. ビルドトリガーを手動でテストするには、トリガーリスト中の作成したトリガーの行で [実行] をクリックします。

  8. tf-compute-1 という Compute Engine インスタンスと Terraform Recommender Test というサービス アカウントが、前の手順で実行した Cloud Build ジョブにより、テスト プロジェクト内に作成されることを確認します。

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

  1. Cloud Shell で、リポジトリのクローンとして作成されたディレクトリに移動します。

    cd $HOME/recommender-iac-pipeline-nodejs-tutorial/parser-service

  2. Cloud Run サービスのデフォルト リージョンを使用するように Google Cloud を構成します。このチュートリアルでは、us-central1 リージョンを使用しますが、サポートされている別のリージョンを選択することもできます。

    gcloud config set run/region us-central1

  3. 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

  4. 次のコマンドを実行して、Docker イメージ用の環境変数を作成します。

    export IMAGE=gcr.io/$BUILD_PROJECT_ID/recommender-parser:1.0

  5. イメージをビルドして、Container Registry にアップロードします。

    gcloud builds submit --tag $IMAGE .

  6. パイプライン内の他の 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

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

    gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
gs://github-keys-$BUILD_PROJECT_ID

gsutil iam ch serviceAccount:recommender-parser-sa@$BUILD_PROJECT_ID.iam.gserviceaccount.com:objectCreator,objectViewer \
gs://recommender-tf-state-$BUILD_PROJECT_ID

  8. 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

  9. 次のコマンドを実行して、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 の設定

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

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

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

Cloud Scheduler ジョブの設定

  1. 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

  2. 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

  3. recommender-service の URL を取得します。

    gcloud beta run services list --platform managed --project $BUILD_PROJECT_ID

    Cloud Scheduler ジョブは、recommender-parser サービスの /recommendation/iam ルートを呼び出して IAM 推奨事項を解析し、/recommender/vm ルートを呼び出して VM サイズ変更の推奨事項を解析します。

  4. 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

  5. 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 トピックにビルド情報を公開します。

  1. 次のコマンドを実行して、build プロジェクトに cloud-builds トピックが存在することを確認します。

    gcloud pubsub topics describe cloud-builds

    トピックが存在する場合、次の出力が表示されます。ここで BUILD-PROJECT-ID はビルド プロジェクト ID です。

    name: projects/BUILD-PROJECT-ID/topics/cloud-builds

    リソースが見つからないというエラー メッセージが表示された場合は、ビルド通知へのサブスクリプションの手順に沿ってトピックを手動で作成します。

  2. 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

  3. 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

  4. 作成した 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

  5. Google Cloud Console で Pub/Sub に移動します。

  6. cloud-builds トピックをクリックします。

  7. [サブスクリプションを作成] をクリックします。

  8. [サブスクリプション ID] に「recommender-service-build-events」と入力します。

  9. [配信タイプ] で、[push] を選択します。

  10. [エンドポイント] には、/ci が付加された recommender-service の URL を入力します。

  11. [認証を有効にする] にチェックを入れます。

    1. 作成したサービス アカウント recommender-ci-subscription-sa を選択します。
    2. 入力を促すメッセージが表示されたら、[付与] をクリックします。

  12. [確認応答期限] には「60」秒と入力します。

  13. 残りはデフォルト値のままににします。

  14. [CREATE] をクリックします。

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

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

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

  1. Google Cloud コンソールでテスト プロジェクトに移動し、作成されたリソースを確認します。次のリソースが必要です。

    1. マシンタイプ g1-small を有する tf-compute-1 と呼ばれる Compute Engine インスタンス。
    2. テスト プロジェクト用に editor のロールを持つ Terraform Recommender Test という名前のサービス アカウント。

  2. build プロジェクトの Cloud Scheduler コンソールのページで、recommender-iam-scheduler ジョブの [今すぐ実行] をクリックします。

  3. ジョブをクリックしてログを表示します。また、recommender-parser サービスログを表示して、サービスによって実行されたステップの詳細を確認することもできます。

  4. サービスの実行が完了したら、GitHub の IAC-REPO-NAME リポジトリに移動します。recommender-parser サービスで、pull リクエストが生成されています。この pull リクエストを構成する変更された IaC マニフェストを確認し、問題がなければ [Merge pull request] をクリックします。

  5. pull リクエストをマージすると、マスター ブランチへの新しい commit が作成されます。これにより、test プロジェクト内の Google Cloud リソースに変更をロールアウトする Cloud Build ジョブがトリガーされます。Cloud Build ジョブが完了するまで少し待ちます。ステータスは Google Cloud コンソールで確認できます。

  6. ジョブが完了したら、テスト プロジェクトに移動します。サンプル ペイロードにより、テスト プロジェクトのリソースは次のように変更されます。

    • 前のデプロイでは editor ロールが付与されていた Terraform テスト サービス アカウントは、viewer に変更されます。

クリーンアップ

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

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

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

  1. Google Cloud コンソールで、[リソースの管理] ページに移動します。

    [リソースの管理] に移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ