1. 1. 前提条件
所要時間: 1 ~ 2 時間
この Codelab を実施するモードは、ローカル テストと集約サービスの 2 つがあります。ローカルテストモードでは、ローカルマシンと Chrome ブラウザが必要です(Google Cloud リソースの作成や使用は不要です)。集計サービス モードでは、Google Cloud に集計サービスを完全にデプロイする必要があります。
この Codelab をどちらのモードでも行うには、いくつかの前提条件が必要です。各要件には、ローカルテストと集計サービスにどちらが必要かが表示されます。
1.1. 登録と構成証明を完了する(集計サービス)
プライバシー サンドボックス API を使用するには、Chrome と Android の両方で登録と構成証明を完了していることを確認してください。
1.2. 広告プライバシー API を有効にする(ローカル テストと集計サービス)
プライバシー サンドボックスを使用するため、プライバシー サンドボックスの広告 API を有効にすることをおすすめします。
ブラウザで chrome://settings/adPrivacy
に移動し、すべての広告プライバシー API を有効にします。
また、サードパーティ Cookie が有効になっていることを確認してください。
chrome://settings/cookies
で、サードパーティ Cookie がブロックされていないことを確認します。Chrome のバージョンによっては、この設定メニューに表示されるオプションが異なる場合がありますが、有効な設定には次のようなものがあります。
- [すべてのサードパーティ Cookie をブロックする] = 無効
- [サードパーティの Cookie をブロックする] = 無効
- [シークレット モードでサードパーティ Cookie をブロックする] = 有効
1.3. ローカルテストツールをダウンロードする(ローカルテスト)
ローカルテストを行うには、ローカルテストツールをダウンロードする必要があります。このツールは、暗号化されていないデバッグ レポートから概要レポートを生成します。
ローカル テストツールは、GitHub の Cloud Functions JAR アーカイブからダウンロードできます。LocalTestingTool_{version}.jar
という名前にする必要があります。
1.4. JAVA JRE がインストールされていることを確認する(ローカル テストと集計サービス)
[ターミナル] を開き、java --version
を使用して、マシンに Java または openJDK がインストールされているかどうかを確認します。
インストールされていない場合は、Java のサイトまたは openJDK のサイトからダウンロードしてインストールできます。
1.5. aggregatable_report_converter をダウンロードする(ローカル テストと集計サービス)
aggregatable_report_converter のコピーは、プライバシー サンドボックスのデモの GitHub リポジトリからダウンロードできます。GitHub リポジトリでは IntelliJ または Eclipse の使用について言及していますが、どちらも必須ではありません。これらのツールを使用しない場合は、代わりに JAR ファイルをローカル環境にダウンロードします。
1.6. GCP 環境を設定する(集計サービス)
Aggregation Service では、クラウド プロバイダを使用する高信頼実行環境を使用する必要があります。この Codelab では、集計サービスを GCP にデプロイしますが、AWS もサポートされています。
GitHub のデプロイ手順に沿って、gcloud CLI を設定し、Terraform バイナリとモジュールをダウンロードし、Aggregation Service の GCP リソースを作成します。
デプロイ手順の主なステップは次のとおりです。
- 環境に「gcloud」CLI と Terraform を設定します。
- Terraform の状態を保存する Cloud Storage バケットを作成します。
- 依存関係をダウンロードします。
adtech_setup.auto.tfvars
を更新し、adtech_setup
Terraform を実行します。adtech_setup.auto.tfvars
ファイルの例については、付録をご覧ください。ここで作成されたデータバケットの名前をメモします。これは、コードラボで作成するファイルを保存するために使用されます。dev.auto.tfvars
を更新し、デプロイ サービス アカウントの権限を借用して、dev
Terraform を実行します。dev.auto.tfvars
ファイルの例については、付録をご覧ください。- Deployment が完了したら、Terraform の出力から
frontend_service_cloudfunction_url
をキャプチャします。これは、後続のステップで Aggregation Service にリクエストを送信する際に必要になります。
1.7. 集計サービスのオンボーディングを完了する(集計サービス)
集計サービスを使用するには、コーディネーターにオンボーディングする必要があります。集計サービスのオンボーディング フォームに、レポート サイトなどの情報を入力し、[Google Cloud] を選択してサービス アカウントのアドレスを入力します。このサービス アカウントは、前の前提条件(1.6GCP 環境を設定する)。(ヒント: 指定されたデフォルト名を使用する場合、このサービス アカウントは「worker-sa@」で始まります)。
オンボーディング プロセスが完了するまで 2 週間ほどかかります。
1.8. API エンドポイント(集計サービス)を呼び出す方法を決定する
この Codelab では、Aggregation Service API エンドポイントを呼び出す方法として、cURL と Postman の 2 つの方法を紹介します。cURL は、最小限の設定で追加のソフトウェアを必要とせず、ターミナルから API エンドポイントを呼び出すのが簡単で速い方法です。ただし、cURL を使用したくない場合は、代わりに Postman を使用して API リクエストを実行し、後で使用するために保存できます。
セクション 3.2 で、集計サービスの使用方法をご覧ください。両方のオプションの使用方法について詳しく説明しています。どちらの方法を使用するか判断するために、ここでプレビューできます。Postman を選択した場合は、次の初期設定を行います。
1.8.1. ワークスペースをセットアップ
Postman アカウントを登録します。登録すると、ワークスペースが自動的に作成されます。
ワークスペースが作成されていない場合は、上部のナビゲーション アイテムの [ワークスペース] に移動し、[ワークスペースを作成] を選択します。
[空のワークスペース] を選択し、[次へ] をクリックして「GCP Privacy Sandbox」という名前を付けます。[個人] を選択し、[作成] をクリックします。
事前構成済みのワークスペースの JSON 構成と グローバル環境ファイルをダウンロードします。
[インポート] ボタンを使用して、両方の JSON ファイルを [マイ ワークスペース] にインポートします。
これにより、createJob
と getJob
の HTTP リクエストとともに「GCP Privacy Sandbox」コレクションが作成されます。
1.8.2. 認可を設定する
[GCP Privacy Sandbox] コレクションをクリックし、[認可] タブに移動します。
「Bearer Token」メソッドを使用します。ターミナル環境でこのコマンドを実行し、出力をコピーします。
gcloud auth print-identity-token
次に、このトークン値を Postman の認可タブの [トークン] フィールドに貼り付けます。
1.8.3. 環境を設定する
右上の [環境の概要] に移動します。
[編集] をクリックし、「environment」、「region」、「cloud-function-id」の [現在の値] を更新します。
「request-id」は後で入力するため、今は空白のままにします。他のフィールドには、前提条件 1.6 の Terraform デプロイの正常な完了から返された frontend_service_cloudfunction_url
の値を使用します。URL の形式は https://
です。
2. 2. ローカルテスト コードラボ
完了までの推定時間: 1 時間未満
マシン上のローカル テストツールを使用して、集計を実行し、暗号化されていないデバッグ レポートを使用して概要レポートを生成できます。始める前に、「ローカルテスト」とラベル付けされた前提条件をすべて完了していることを確認してください。
Codelab の手順
ステップ 2.1. レポートをトリガーする: 非公開集計レポートをトリガーしてレポートを収集できるようにします。
ステップ 2.2. デバッグ用 AVRO レポートを作成する: 収集した JSON レポートを AVRO 形式のレポートに変換します。このステップは、広告テクノロジーが API レポート エンドポイントからレポートを収集し、JSON レポートを Avro 形式のレポートに変換する場合と同様です。
ステップ 2.3. バケットキーを取得する: バケットキーは広告テクノロジーによって設計されます。この Codelab では、バケットが事前定義されているため、提供されているバケットキーを取得します。
ステップ 2.4. 出力ドメインの AVRO を作成する: バケットキーを取得したら、出力ドメインの AVRO ファイルを作成します。
ステップ 2.5. 概要レポートを作成する: ローカルテストツールを使用して、ローカル環境で概要レポートを作成できます。
ステップ 2.6. 概要レポートを確認する: ローカル テストツールによって作成された概要レポートを確認します。
2.1. トリガー レポート
限定公開集計レポートをトリガーするには、プライバシー サンドボックスのデモサイト(https://privacy-sandbox-demos-news.dev/?env=gcp)または独自のサイト(https://adtechexample.com など)を使用できます。独自のサイトを使用している場合、登録と構成証明、集約サービスのオンボーディングを完了していない場合は、Chrome フラグと CLI スイッチを使用する必要があります。
このデモでは、プライバシー サンドボックスのデモサイトを使用します。リンクをクリックしてサイトにアクセスし、chrome://private-aggregation-internals
でレポートを表示します。
{reporting-origin}/.well-known/private-aggregation/debug/report-shared-storage
エンドポイントに送信されたレポートは、Chrome Internals ページに表示されるレポートの [レポート本文] にも表示されます。
ここに多くのレポートが表示されますが、この Codelab では、GCP 固有でデバッグ エンドポイントによって生成される集計可能なレポートを使用します。[Report URL] には「/debug/」が含まれ、[Report Body] の aggregation_coordinator_origin field
には URL「https://publickeyservice.msmt.gcp.privacysandboxservices.com」が含まれます。
2.2. デバッグ集計レポートを作成する
chrome://private-aggregation-internals
の [Report Body] にあるレポートをコピーし、privacy-sandbox-demos/tools/aggregatable_report_converter/out/artifacts/aggregatable_report_converter_jar
フォルダ(前提条件 1.5 でダウンロードしたリポジトリ内)に JSON ファイルを作成します。
この例では、Linux を使用しているため vim を使用しています。ただし、任意のテキスト エディタを使用できます。
vim report.json
レポートを report.json
に貼り付けて、ファイルを保存します。
次に、aggregatable_report_converter.jar
を使用して、デバッグ用集計レポートを作成します。これにより、現在のディレクトリに report.avro
という集計可能なレポートが作成されます。
java -jar aggregatable_report_converter.jar \
--request_type convertToAvro \
--input_file report.json \
--debug
2.3. レポートからバケットキーを取得する
output_domain.avro
ファイルを作成するには、レポートから取得できるバケットキーが必要です。
バケットキーはアドテックによって設計されます。ただし、この場合は、サイト プライバシー サンドボックスのデモがバケットキーを作成します。このサイトの非公開集計はデバッグモードであるため、[レポート本文] の debug_cleartext_payload
を使用してバケットキーを取得できます。
レポート本文から debug_cleartext_payload
をコピーします。
goo.gle/ags-payload-decoder を開き、[INPUT] ボックスに debug_cleartext_payload
を貼り付けて [Decode] をクリックします。
このページには、バケットキーの 10 進数値が表示されます。バケットキーの例を次に示します。
2.4. 出力ドメイン AVRO を作成する
バケットキーが作成されたので、作業していたフォルダに output_domain.avro
を作成します。バケットキーは、取得したバケットキーに置き換えてください。
java -jar aggregatable_report_converter.jar \
--request_type createDomainAvro \
--bucket_key <bucket key>
このスクリプトにより、現在のフォルダに output_domain.avro
ファイルが作成されます。
2.5. ローカル テストツールを使用して概要レポートを作成する
前提条件 1.3 でダウンロードした LocalTestingTool_{version}.jar
を使用して、次のコマンドを使用して概要レポートを作成します。{version}
は、ダウンロードしたバージョンに置き換えます。LocalTestingTool_{version}.jar
を現在のディレクトリに移動するか、相対パスを追加して現在の場所を参照してください。
java -jar LocalTestingTool_{version}.jar \
--input_data_avro_file report.avro \
--domain_avro_file output_domain.avro \
--output_directory .
コマンドを実行すると、次のような結果が表示されます。これが完了すると、レポート output.avro
が作成されます。
2.6. 概要レポートを確認する
作成される概要レポートは AVRO 形式です。これを読み取るには、AVRO から JSON 形式に変換する必要があります。理想的には、adTech が AVRO レポートを JSON に変換するコードを記述する必要があります。
aggregatable_report_converter.jar
を使用して、AVRO レポートを JSON に戻します。
java -jar aggregatable_report_converter.jar \
--request_type convertToJson \
--input_file output.avro
これにより、次のようなレポートが返されます。同じディレクトリに作成されたレポート output.json
も作成されます。
Codelab が完了しました
概要: Aggregation Service の集計動作をシミュレートするローカル テストツールを使用して、デバッグ レポートを収集し、出力ドメイン ファイルを作成し、概要レポートを生成しました。
次のステップ: ローカル テストツールを試したところで、次は、ご自身の環境で Aggregation Service を本番環境にデプロイして、同じ演習を行ってみましょう。前提条件を再確認して、「Aggregation Service」モード用にすべてが設定されていることを確認してから、ステップ 3 に進みます。
3. 3. 集計サービス Codelab
所要時間: 1 時間
始める前に、「Aggregation Service」というラベルが付いた前提条件をすべて完了していることを確認します。
Codelab の手順
ステップ 3.1. 集計サービスの入力の作成: 集計サービス用にバッチ処理される集計サービスのレポートを作成します。
- ステップ 3.1.1. トリガー レポート
- ステップ 3.1.2. 集計可能レポートを収集する
- ステップ 3.1.3. レポートを AVRO に変換する
- ステップ 3.1.4. output_domain AVRO を作成する
- ステップ 3.1.5. レポートを Cloud Storage バケットに移動する
ステップ 3.2. 集計サービスの使用: Aggregation Service API を使用して概要レポートを作成し、概要レポートを確認します。
- ステップ 3.2.1.
createJob
エンドポイントを使用してバッチ化する - ステップ 3.2.2.
getJob
エンドポイントを使用してバッチ ステータスを取得する - ステップ 3.2.3. 概要レポートを確認する
3.1. 集計サービスの入力の作成
集計サービスへのバッチ処理用に AVRO レポートを作成します。これらの手順のシェルコマンドは、GCP の Cloud Shell 内(前提条件の依存関係が Cloud Shell 環境にクローンされている場合)またはローカル実行環境で実行できます。
3.1.1. トリガー レポート
リンクをクリックしてサイトにアクセスし、chrome://private-aggregation-internals
でレポートを表示します。
{reporting-origin}/.well-known/private-aggregation/debug/report-shared-storage
エンドポイントに送信されたレポートは、Chrome Internals ページに表示されるレポートの [レポート本文] にも表示されます。
ここに多くのレポートが表示されますが、この Codelab では、GCP 固有でデバッグ エンドポイントによって生成される集計可能なレポートを使用します。[Report URL] には「/debug/」が含まれ、[Report Body] の aggregation_coordinator_origin field
には URL「https://publickeyservice.msmt.gcp.privacysandboxservices.com」が含まれます。
3.1.2. 集計可能レポートを収集する
対応する API の .well-known エンドポイントから集計可能レポートを収集します。
- Private Aggregation:
{reporting-origin}/.well-known/private-aggregation/report-shared-storage
- アトリビューション レポート - 概要レポート:
{reporting-origin}/.well-known/attribution-reporting/report-aggregate-attribution
この Codelab では、レポートの収集を手動で行います。本番環境では、広告テクノロジーがレポートをプログラムで収集して変換することが求められます。
chrome://private-aggregation-internals
の [レポート本文] にある JSON レポートをコピーします。
この例では、Linux を使用しているため vim を使用します。ただし、任意のテキスト エディタを使用できます。
vim report.json
レポートを report.json
に貼り付けて、ファイルを保存します。
3.1.3. レポートを AVRO に変換する
.well-known
エンドポイントから受信したレポートは JSON 形式であるため、AVRO レポート形式に変換する必要があります。JSON レポートを取得したら、report.json
が保存されている場所に移動し、aggregatable_report_converter.jar
を使用して、デバッグ用に集約可能なレポートを作成します。これにより、現在のディレクトリに report.avro
という集計可能なレポートが作成されます。
java -jar aggregatable_report_converter.jar \
--request_type convertToAvro \
--input_file report.json
3.1.4. output_domain AVRO を作成する
output_domain.avro
ファイルを作成するには、レポートから取得できるバケットキーが必要です。
バケットキーはアドテックによって設計されます。ただし、この場合は、サイト プライバシー サンドボックスのデモがバケットキーを作成します。このサイトの非公開集計はデバッグモードであるため、[レポート本文] の debug_cleartext_payload
を使用してバケットキーを取得できます。
レポート本文から debug_cleartext_payload
をコピーします。
goo.gle/ags-payload-decoder を開き、[INPUT] ボックスに debug_cleartext_payload
を貼り付けて [Decode] をクリックします。
このページには、バケットキーの 10 進数値が表示されます。バケットキーの例を次に示します。
バケットキーが作成されたので、作業していたフォルダに output_domain.avro
を作成します。バケットキーは、取得したバケットキーに置き換えてください。
java -jar aggregatable_report_converter.jar \
--request_type createDomainAvro \
--bucket_key <bucket key>
このスクリプトにより、現在のフォルダに output_domain.avro
ファイルが作成されます。
3.1.5. レポートを Cloud Storage バケットに移動する
AVRO レポートと出力ドメインが作成されたら、レポートと出力ドメインを Cloud Storage のバケット(前提条件 1.6 でメモしたバケット)に移動します。
ローカル環境に gcloud CLI が設定されている場合は、次のコマンドを使用してファイルを対応するフォルダにコピーします。
gcloud storage cp report.avro gs://<bucket_name>/reports/
gcloud storage cp output_domain.avro gs://<bucket_name>/output_domain/
それ以外の場合は、ファイルをバケットに手動でアップロードします。「reports」というフォルダを作成し、そこに report.avro
ファイルをアップロードします。「output_domains」というフォルダを作成し、そこに output_domain.avro
ファイルをアップロードします。
3.2. 集計サービスの使用状況
前提条件 1.8 で、Aggregation Service エンドポイントへの API リクエストに cURL または Postman を選択したことを思い出してください。以下に、両方のオプションの手順を示します。
ジョブがエラーで失敗した場合は、GitHub のトラブルシューティング ドキュメントで、対処方法の詳細を確認してください。
3.2.1. createJob
エンドポイントを使用してバッチに処理する
ジョブを作成するには、以下の cURL または Postman の手順を使用します。
cURL
[ターミナル] でリクエスト本文ファイル(body.json
)を作成し、以下を貼り付けます。プレースホルダの値は必ず更新してください。各フィールドの詳細については、こちらの API ドキュメントをご覧ください。
{
"job_request_id": "<job_request_id>",
"input_data_blob_prefix": "<report_folder>/<report_name>.avro",
"input_data_bucket_name": "<bucket_name>",
"output_data_blob_prefix": "<output_folder>/<summary_report_prefix>",
"output_data_bucket_name": "<bucket_name>",
"job_parameters": {
"output_domain_blob_prefix": "<output_domain_folder>/<output_domain>.avro",
"output_domain_bucket_name": "<bucket_name>",
"attribution_report_to": "<reporting origin of report>",
"reporting_site": "<domain of reporting origin(s) of report>", // Only one of attribution_report_to or reporting_site is required as of v2.7.0
"report_error_threshold_percentage": "10",
"debug_run": "true"
}
}
次のリクエストを実行します。cURL リクエストの URL のプレースホルダを、frontend_service_cloudfunction_url
の値に置き換えます。frontend_service_cloudfunction_url
の値は、前提条件 1.6 の Terraform デプロイが正常に完了すると出力されます。
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
-d @body.json \
https://<environment>-<region>-frontend-service-<cloud-function-id>-uc.a.run.app/v1alpha/createJob
Aggregation Service がリクエストを承認すると、HTTP 202 レスポンスが返されます。その他のレスポンス コードについては、API の仕様をご覧ください。
Postman
createJob
エンドポイントの場合、集計可能なレポート、出力ドメイン、概要レポートの場所とファイル名を集計サービスに提供するために、リクエスト本文が必要です。
createJob
リクエストの [Body] タブに移動します。
指定された JSON 内のプレースホルダを置き換えます。これらのフィールドとその内容の詳細については、API ドキュメントをご覧ください。
{
"job_request_id": "<job_request_id>",
"input_data_blob_prefix": "<report_folder>/<report_name>.avro",
"input_data_bucket_name": "<bucket_name>",
"output_data_blob_prefix": "<output_folder>/<summary_report_prefix>",
"output_data_bucket_name": "<bucket_name>",
"job_parameters": {
"output_domain_blob_prefix": "<output_domain_folder>/<output_domain>.avro",
"output_domain_bucket_name": "<bucket_name>",
"attribution_report_to": "<reporting origin of report>",
"reporting_site": "<domain of reporting origin(s) of report>", // Only one of attribution_report_to or reporting_site is required as of v2.7.0
"report_error_threshold_percentage": "10",
"debug_run": "true"
}
}
createJob
API リクエストを「送信」します。
レスポンス コードはページの下半分に表示されます。
Aggregation Service がリクエストを承認すると、HTTP 202 レスポンスが返されます。その他の可能性のあるレスポンス コードについては、API 仕様をご覧ください。
3.2.2. getJob
エンドポイントを使用してバッチ ステータスを取得する
以下の cURL または Postman の手順に沿ってジョブを取得します。
cURL
ターミナルで次のリクエストを実行します。URL のプレースホルダを frontend_service_cloudfunction_url
の値に置き換えます。これは、createJob
リクエストに使用した URL と同じです。「job_request_id」には、createJob
エンドポイントで作成したジョブの値を使用します。
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" \
https://<environment>-<region>-frontend-service-<cloud-function-id>-uc.a.run.app/v1alpha/getJob?job_request_id=<job_request_id>
結果として、HTTP ステータス 200 でジョブリクエストのステータスが返されます。リクエストの「Body」には、job_status
、return_message
、error_messages
(ジョブでエラーが発生した場合)などの必要な情報が含まれます。
Postman
ジョブリクエストのステータスを確認するには、getJob
エンドポイントを使用します。getJob
リクエストの [Params] セクションで、job_request_id
の値を createJob
リクエストで送信された job_request_id
に更新します。
getJob
リクエストを「送信」します。
結果として、HTTP ステータス 200 でジョブリクエストのステータスが返されます。リクエストの「Body」には、job_status
、return_message
、error_messages
(ジョブでエラーが発生した場合)などの必要な情報が含まれます。
3.2.3. 概要レポートを確認する
出力 Cloud Storage バケットに概要レポートが届いたら、ローカル環境にダウンロードできます。概要レポートは AVRO 形式で、JSON に変換できます。aggregatable_report_converter.jar
を使用して、次のコマンドでレポートを読み取ることができます。
java -jar aggregatable_report_converter.jar \
--request_type convertToJson \
--input_file <summary_report_avro>
これにより、各バケットキーの集計値の JSON が返されます。次に例を示します。
createJob
リクエストに debug_run
が true として含まれている場合は、output_data_blob_prefix
にあるデバッグ フォルダに概要レポートを受け取ることができます。レポートは AVRO 形式で、上記のコマンドを使用して JSON に変換できます。
レポートには、バケットキー、ノイズなしの指標、ノイズなしの指標に追加されて概要レポートを形成するノイズが含まれています。レポートは次のようになります。
アノテーションには、「in_reports」や「in_domain」も含まれます。これは、次のことを意味します。
- in_reports - 集計可能なレポート内でバケットキーを使用できます。
- in_domain - バケットキーは output_domain AVRO ファイル内で使用できます。
Codelab が完了しました
概要: Aggregation Service を独自のクラウド環境にデプロイし、デバッグ レポートを収集し、出力ドメイン ファイルを作成して、これらのファイルを Cloud Storage バケットに保存し、ジョブを正常に実行しました。
次のステップ: 環境で Aggregation Service を引き続き使用するか、手順 4 のクリーンアップ手順に沿って、作成したばかりのクラウド リソースを削除します。
4. 4. クリーンアップ
Terraform で Aggregation Service 用に作成されたリソースを削除するには、adtech_setup
フォルダと dev
フォルダ(または他の環境)で destroy コマンドを使用します。
$ cd <repository_root>/terraform/gcp/environments/adtech_setup
$ terraform destroy
$ cd <repository_root>/terraform/gcp/environments/dev
$ terraform destroy
集計可能なレポートと概要レポートを保持する Cloud Storage バケットを削除するには:
$ gcloud storage buckets delete gs://my-bucket
前提条件 1.2 の Chrome Cookie 設定を以前の状態に戻すこともできます。
5. 5. 付録
adtech_setup.auto.tfvars
ファイルの例
/**
* Copyright 2023 Google LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
project = "my-project-id"
# Required to generate identity token for access of Adtech Services API endpoints
service_account_token_creator_list = ["user:me@email.com"]
# Uncomment the below line if you like Terraform to create an Artifact registry repository
# for self-build container artifacts. "artifact_repo_location" defaults to "us".
artifact_repo_name = "my-ags-artifacts"
# Note: Either one of [1] or [2] must be uncommented.
# [1] Uncomment below lines if you like Terraform grant needed permissions to
# pre-existing service accounts
# deploy_service_account_email = "<YourDeployServiceAccountName>@<ProjectID>.iam.gserviceaccount.com"
# worker_service_account_email = "<YourWorkerServiceAccountName>@<ProjectID>.iam.gserviceaccount.com"
# [2] Uncomment below lines if you like Terraform to create service accounts
# and needed permissions granted e.g "deploy-sa" or "worker-sa"
deploy_service_account_name = "deploy-sa"
worker_service_account_name = "worker-sa"
# Uncomment the below line if you want Terraform to create the
# below bucket. "data_bucket_location" defaults to "us".
data_bucket_name = "my-ags-data"
# Uncomment the below lines if you want to specify service account customer role names
# deploy_sa_role_name = "<YourDeploySACustomRole>"
# worker_sa_role_name = "<YourWorkerSACustomRole>"
dev.auto.tfvars
ファイルの例
/**
* Copyright 2022 Google LLC
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
# Example values required by job_service.tf
#
# These values should be modified for each of your environments.
region = "us-central1"
region_zone = "us-central1-c"
project_id = "my-project-id"
environment = "operator-demo-env"
# Co-locate your Cloud Spanner instance configuration with the region above.
# https://cloud.google.com/spanner/docs/instance-configurations#regional-configurations
spanner_instance_config = "regional-us-central1"
# Adjust this based on the job load you expect for your deployment.
# Monitor the spanner instance utilization to decide on scale out / scale in.
# https://console.cloud.google.com/spanner/instances
spanner_processing_units = 100
# Uncomment the line below at your own risk to disable Spanner database protection.
# This needs to be set to false and applied before destroying all resources is possible.
spanner_database_deletion_protection = false
instance_type = "n2d-standard-8" # 8 cores, 32GiB
# Container image location that packages the job service application
# If not set otherwise, uncomment and edit the line below:
#worker_image = "<location>/<project>/<repository>/<image>:<tag or digest>"
# Service account created and onboarded for worker
user_provided_worker_sa_email = "worker-sa@my-project-id.iam.gserviceaccount.com"
min_worker_instances = 1
max_worker_instances = 20