このチュートリアルでは、以下で構成される投票サービスの作成方法について説明します。
ブラウザベースのクライアント。次の処理を行います。
- Identity Platform を使用して ID トークンを取得する。
- ユーザーがお気に入りの動物に投票する。
- 取得した ID トークンをリクエストに付加して、投票を処理する Cloud Run サーバーに送信する。
Cloud Run サーバー。次の処理を行います。
- 有効な ID トークンが提供され、エンドユーザーが正しく認証されていることを確認する。
- エンドユーザーの投票を処理する。
- 独自の認証情報を使用して、投票結果を Cloud SQL に送信して保管する。
投票結果を保存する PostgreSQL データベース。
説明をわかりやすくするため、このチュートリアルでは Google をプロバイダとして使用します。ID トークンを取得するには、ユーザーは Google アカウントを使用して認証を行う必要があります。ただし、ユーザーのログインに他のプロバイダや認証方法を使用することもできます。
このサービスは、Secret Manager を使用して Cloud SQL インスタンスへの接続で使用されるセンシティブ データを保護し、セキュリティ リスクを最小限に抑えます。また、最小権限のサービス ID を使用して、データベースへのアクセスを保護します。
gcloud
のデフォルトを設定する
Cloud Run サービスを gcloud のデフォルトに構成するには:
デフォルト プロジェクトを設定します。
gcloud config set project PROJECT_ID
PROJECT_ID は、このチュートリアルで作成したプロジェクトの名前に置き換えます。
選択したリージョン向けに gcloud を構成します。
gcloud config set run/region REGION
REGION は、任意のサポートされている Cloud Run のリージョンに置き換えます。
Cloud Run のロケーション
Cloud Run はリージョナルです。つまり、Cloud Run サービスを実行するインフラストラクチャは特定のリージョンに配置され、そのリージョン内のすべてのゾーンで冗長的に利用できるように Google によって管理されます。
レイテンシ、可用性、耐久性の要件を満たしていることが、Cloud Run サービスを実行するリージョンを選択する際の主な判断材料になります。一般的には、ユーザーに最も近いリージョンを選択できますが、Cloud Run サービスで使用されている他の Google Cloudプロダクトのロケーションも考慮する必要があります。 Google Cloud プロダクトを複数のロケーションで使用すると、サービスのレイテンシだけでなく、コストにも影響を及ぼす可能性があります。
Cloud Run は、次のリージョンで利用できます。
ティア 1 料金を適用
asia-east1
(台湾)asia-northeast1
(東京)asia-northeast2
(大阪)asia-south1
(ムンバイ、インド)europe-north1
(フィンランド)低 CO2
europe-north2
(ストックホルム)低 CO2
europe-southwest1
(マドリッド)低 CO2
europe-west1
(ベルギー)低 CO2
europe-west4
(オランダ)低 CO2
europe-west8
(ミラノ)europe-west9
(パリ)低 CO2
me-west1
(テルアビブ)northamerica-south1
(メキシコ)us-central1
(アイオワ)低 CO2
us-east1
(サウスカロライナ)us-east4
(北バージニア)us-east5
(コロンバス)us-south1
(ダラス)低 CO2
us-west1
(オレゴン)低 CO2
ティア 2 料金を適用
africa-south1
(ヨハネスブルグ)asia-east2
(香港)asia-northeast3
(ソウル、韓国)asia-southeast1
(シンガポール)asia-southeast2
(ジャカルタ)asia-south2
(デリー、インド)australia-southeast1
(シドニー)australia-southeast2
(メルボルン)europe-central2
(ワルシャワ、ポーランド)europe-west10
(ベルリン)europe-west12
(トリノ)europe-west2
(ロンドン、イギリス)低 CO2
europe-west3
(フランクフルト、ドイツ)europe-west6
(チューリッヒ、スイス)低 CO2
me-central1
(ドーハ)me-central2
(ダンマーム)northamerica-northeast1
(モントリオール)低 CO2
northamerica-northeast2
(トロント)低 CO2
southamerica-east1
(サンパウロ、ブラジル)低 CO2
southamerica-west1
(サンティアゴ、チリ)低 CO2
us-west2
(ロサンゼルス)us-west3
(ソルトレイクシティ)us-west4
(ラスベガス)
Cloud Run サービスをすでに作成している場合は、Google Cloud コンソールの Cloud Run ダッシュボードにリージョンが表示されます。
サンプルコードを取得する
使用するコードサンプルを取得するには:
ローカルマシンにサンプルアプリのリポジトリのクローンを作成します。
Node.js
git clone https://github.com/GoogleCloudPlatform/nodejs-docs-samples.git
または、zip 形式のサンプルをダウンロードし、ファイルを抽出してもかまいません。
Python
git clone https://github.com/GoogleCloudPlatform/python-docs-samples.git
または、zip 形式のサンプルをダウンロードし、ファイルを抽出してもかまいません。
Java
git clone https://github.com/GoogleCloudPlatform/java-docs-samples.git
または、zip 形式のサンプルをダウンロードし、ファイルを抽出してもかまいません。
Cloud Run のサンプルコードが含まれているディレクトリに移動します。
Node.js
cd nodejs-docs-samples/run/idp-sql/
Python
cd python-docs-samples/run/idp-sql/
Java
cd java-docs-samples/run/idp-sql/
アーキテクチャを可視化する

エンドユーザーが、Cloud Run サーバーに最初のリクエストを行います。
クライアントがブラウザに読み込まれます。
ユーザーが Identity Platform の Google ログイン ダイアログでログイン認証情報を入力します。ログインしたユーザーにアラートが表示されます。
制御がサーバーにリダイレクトされます。エンドユーザーがクライアントを使用して投票します。クライアントは、Identity Platform から ID トークンを取得して、投票リクエスト ヘッダーに追加します。
サーバーは、リクエストを受信すると、Identity Platform ID トークンを検証してエンドユーザーが適切に認証されていることを確認します。次に、サーバーは、独自の認証情報を使用して Cloud SQL に投票を送信します。
コアコードについて
このサンプルは、以下のようにクライアントとサーバーとして実装されます。
Identity Platform との統合: クライアント側のコード
このサンプルでは、Firebase SDK を使用して Identity Platform と統合し、ユーザーのログインと管理を行います。Identity Platform に接続するため、クライアント側の JavaScript はプロジェクトの認証情報への参照を構成オブジェクトとして保持し、必要な Firebase JavaScript SDK をインポートします。
Firebase JavaScript SDK は、ポップアップ ウィンドウを表示してエンドユーザーに Google アカウントへのログインを求めることにより、ログインフローを処理します。次に、サービスにリダイレクトします。
ユーザーがログインに成功すると、クライアントは Firebase メソッドを使用して ID トークンを作成します。クライアントが、この ID トークンをサーバーに対するリクエストの Authorization
ヘッダーに追加します。
Identity Platform との統合: サーバーサイドのコード
サーバーでは、Firebase Admin SDK を使用して、クライアントから送信されたユーザー ID トークンを確認します。提供された ID トークンが正しい形式で、期限切れではなく、適切に署名されていれば、メソッドはデコードされた ID トークンを返します。そのユーザーの Identity Platform uid
が、サーバーにより抽出されます。
Node.js
Python
Java
サーバーを Cloud SQL に接続する
サービスは、/cloudsql/CLOUD_SQL_CONNECTION_NAME
の形式を使用して、Cloud SQL インスタンスの Unix ドメイン ソケットに接続します。
Node.js
Python
Java
Spring Cloud Google Cloud PostgreSQL スターター インテグレーションを使用して、Spring JDBC ライブラリを使用する Cloud SQL の PostgreSQL データベースを操作します。DataSource
Bean を自動的に構成するように Cloud SQL for MySQL 構成を設定します。これは、Spring JDBC と一体となり、データベースのクエリや変更などのオペレーションを可能にする JdbcTemplate
オブジェクト Bean を提供します。
Secret Manager で機密性の高い構成を処理する
Cloud SQL 構成などのセンシティブ データは、Secret Manager によって一元管理され、安全に保管されます。このサービスは、Secret Manager から環境変数を介してランタイムに Cloud SQL 認証情報を挿入します。詳しくは、Cloud Run でのシークレットの使用をご覧ください。
Node.js
Python
Java
Identity Platform を設定する
Identity Platform は、 Google Cloud コンソールで手動で設定する必要があります。
Google Cloud コンソールで、Identity Platform API を有効にします。
プロジェクトを構成します。
新しいウィンドウで、[Google Auth Platform] > [概要] ページに移動します。
[使ってみる] をクリックし、プロジェクトの構成設定手順に沿って操作します。
[アプリ情報] ダイアログで、次の操作を行います。
- アプリケーション名を入力します。
- 表示されたユーザー サポートメールのいずれかを選択します。
[オーディエンス] ダイアログで [外部] を選択します。
[連絡先情報] ダイアログで、連絡先のメールアドレスを入力します。
ユーザーデータに関するポリシーに同意し、[作成] をクリックします。
OAuth クライアント ID とシークレットを作成して取得します。
Google Cloud コンソールで、[API とサービス] > [認証情報] ページに移動します。
ページの上部にある [認証情報を作成] をクリックし、[
OAuth client ID
] を選択します。[アプリケーションの種類] で [ウェブ アプリケーション] を選択し、名前を入力します。
[作成] をクリックします。
client_id
とclient_secret
の値は、次のステップで使用します。
Google をプロバイダとして構成します。
Google Cloud コンソールで、[ID プロバイダ] ページに移動します。
[プロバイダを追加] をクリックします。
リストから [Google] を選択します。
[ウェブ SDK 構成] 設定で、前のステップで取得した
client_id
とclient_secret
の値を入力します。[アプリケーションの構成] で [詳細を設定] をクリックします。
構成をアプリケーションにコピーします。
apiKey
とauthDomain
の値をサンプルのstatic/config.js
にコピーして、Identity Platform Client SDK を初期化します。
サービスのデプロイ
手順に沿って、インフラストラクチャのプロビジョニングとデプロイを完了します。
コンソール または CLI を使用して、PostgSQL データベースの Cloud SQL インスタンスを作成します。
gcloud sql instances create CLOUD_SQL_INSTANCE_NAME \ --database-version=POSTGRES_16 \ --region=CLOUD_SQL_REGION \ --cpu=2 \ --memory=7680MB \ --root-password=DB_PASSWORD
Cloud SQL の認証情報の値を
postgres-secrets.json
に追加します。Node.js
Python
Java
コンソールまたは CLI を使用して、バージョニングされたシークレットを作成します。
gcloud secrets create idp-sql-secrets \ --replication-policy="automatic" \ --data-file=postgres-secrets.json
コンソール または CLI を使用して、サーバーのサービス アカウントを作成します。
gcloud iam service-accounts create idp-sql-identity
コンソール または CLI を使用して、Secret Manager と Cloud SQL にアクセスするためのロールを付与します。
サーバーに関連付けられたサービス アカウントに、作成したシークレットへのアクセスを許可します。
gcloud secrets add-iam-policy-binding idp-sql-secrets \ --member serviceAccount:idp-sql-identity@PROJECT_ID.iam.gserviceaccount.com \ --role roles/secretmanager.secretAccessor
サーバーに関連付けられたサービス アカウントに Cloud SQL へのアクセスを許可します。
gcloud projects add-iam-policy-binding PROJECT_ID \ --member serviceAccount:idp-sql-identity@PROJECT_ID.iam.gserviceaccount.com \ --role roles/cloudsql.client
Artifact Registry を作成します。
gcloud artifacts repositories create REPOSITORY \ --repository-format docker \ --location REGION
REPOSITORY
はリポジトリの名前です。プロジェクト内のリポジトリのロケーションごとに、リポジトリ名は一意でなければなりません。
Cloud Build を使用してコンテナ イメージをビルドします。
Node.js
gcloud builds submit --tag REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/idp-sql
Python
gcloud builds submit --tag REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/idp-sql
Java
このサンプルでは、Jib を使用して一般的な Java ツールにより Docker イメージをビルドします。Jib は、Dockerfile や Docker をインストールせずにコンテナのビルドを最適化します。Jib を使用して Java コンテナを構築する方法の詳細を確認します。
Docker を承認して Artifact Registry に push するには、gcloud 認証ヘルパーを使用します。
gcloud auth configure-docker
Jib Maven プラグインを使用して、コンテナをビルドし Artifact Registry に push します。
mvn compile jib:build -Dimage=REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/idp-sql
コンソールまたは CLI を使用して、コンテナ イメージを Cloud Run にデプロイします。このサーバーは、未認証のアクセスを許可するようにデプロイされています。これは、ユーザーがクライアントを読み込んで処理を開始できるようにするためです。サーバーは、投票リクエストに追加された ID トークンを手動で検証し、エンドユーザーを認証します。
gcloud run deploy idp-sql \ --image REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/idp-sql \ --allow-unauthenticated \ --service-account idp-sql-identity@PROJECT_ID.iam.gserviceaccount.com \ --add-cloudsql-instances PROJECT_ID:REGION:CLOUD_SQL_INSTANCE_NAME \ --update-secrets CLOUD_SQL_CREDENTIALS_SECRET=idp-sql-secrets:latest
また、
--service-account
、--add-cloudsql-instances
、--update-secrets
の各フラグにも注意してください。これらはそれぞれ、サービス ID、Cloud SQL インスタンス接続、環境変数としてバージョン付きシークレット名を指定します。
最後の仕上げ
Identity Platform では、ユーザーがログインした後に、Cloud Run サービスの URL を許可されたリダイレクトとして承認する必要があります。
[ID プロバイダ] ページでペンのアイコンをクリックして、Google プロバイダを編集します。
右側の [承認済みドメイン] で [ドメインを追加] をクリックし、Cloud Run サービスの URL を入力します。
ビルドまたはデプロイの後、サービス URL はログで確認できます。また、次のコマンドを使用して確認することもできます。
gcloud run services describe idp-sql --format 'value(status.url)'
-
OAuth クライアント ID の横にある鉛筆アイコンをクリックして編集し、
Authorized redirect URIs click the
[URI を追加] ボタンをクリックします。フィールドに、次の URL をコピーして貼り付け、ページ下部の [保存] ボタンをクリックします。
https://PROJECT_ID.firebaseapp.com/__/auth/handler
試してみる
完成したサービスを試すには:
ブラウザで、前述のデプロイの手順により提供された URL に移動します。
[Google でログイン] ボタンをクリックして、認証フローを行います。
投票します。
次のようになります。
これらのサービスの開発を継続する場合は、 Google Cloud の他のサービスへの Identity and Access Management(IAM)アクセスが制限されます。他の多くのサービスにアクセスするには、追加の IAM ロールをこれらのサービスに付与する必要があることにご注意ください。