ビルドプロセスの概要

関数のソースコードを Cloud Run functions にデプロイすると、そのソースは Cloud Storage バケットに保存されます。その後 Cloud Build はコードを自動的にビルドしてコンテナ イメージにし、そのイメージをイメージ レジストリに push します。Cloud Run functions は、関数を実行するためにコンテナを実行する必要がある場合に、このイメージにアクセスします。

注意: Container Registry は非推奨になりました。2025 年 3 月 18 日をもって、Container Registry は廃止され、Container Registry へのイメージの書き込みができなくなります。非推奨と Artifact Registry への移行方法の詳細については、Container Registry の非推奨をご覧ください。

イメージのビルドプロセスは完全に自動化されており、ユーザーが直接入力する必要はありません。ビルドプロセスで使用されるすべてのリソースは、独自のユーザー プロジェクトで実行されます。

プロジェクト内でビルドプロセスを実行するということは、次のことを意味します。

• すべてのビルドログに直接アクセスできます。

• Cloud Build には独自のデフォルトの同時実行割り当てがありますが、事前のビルド時間の割り当てはありません。

• 現在のコンテナ イメージと以前にデプロイしたコンテナ イメージを表示できますが、どちらも Artifact Registry に保存されます。

• Cloud Storage は、プロジェクトで関数のソースコード ディレクトリを保存するために使用されます。次の点にご注意ください。

  • 関数を作成すると、ソースコードを保持するアップロード バケットが作成されます。このアップロード バケットの名前は gcf-uploads-PROJECT_NUMBER-REGION.cloudfunctions.appspot.com です。
  • コードがアップロードされると、関数コードは別のソースバケットに保存されます。
    • デフォルトの暗号化を使用している場合、このバケットの名前は gcf-sources-PROJECT_NUMBER-REGION です。
    • CMEK でデータを保護している場合、バケットの名前は gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH です。
  • ソースバケットとアップロード バケットの両方に保持期間はありません。

注: Cloud Run functions の関数を誤って削除した場合は、gcf-sources バケットのソースファイルを使用して復元できます。ソースファイルは zip ファイルをダウンロードして再デプロイします。gcf-sources bucket には、ソースコードの最新の 2 つのバージョンのみが保持されます。クリーンアップ時に、関数を削除して Cloud Run functions API を無効にしても、gcf-sources バケットは自動的に削除されません。Cloud Run functions 関連のリソースをすべて完全に削除するには、gcf-sources バケットを手動で削除する必要があります。

ビルドプロセスの特徴

ビルドプロセスには次の特徴があります。

• プロジェクト用に Cloud Build API を有効にする必要があります。

  API を手動で有効にするには、上のリンクをクリックし、プルダウン メニューからプロジェクトを選択して、画面の指示に沿って UI を有効にします。

• ビルドプロセス全体はプロジェクトのコンテキスト内で発生するため、プロジェクトに対して、含まれるリソースに基づく料金が課金されます。

  • Cloud Build の料金については、料金ページをご覧ください。このプロセスは Cloud Build のデフォルトのインスタンス サイズを使用します。これらのインスタンスはあらかじめ起動されており、より速く利用できるためです。Cloud Build には無料枠が用意されています。詳細については、料金に関するドキュメントをご覧ください。

  • Cloud Storage の料金については、料金ページをご覧ください。Cloud Storage には無料枠が用意されています。詳細については、料金に関するドキュメントをご覧ください。

  • Artifact Registry の料金については、料金ページをご覧ください。

  • Container Registry（非推奨） の料金については、料金ページをご覧ください。

• ビルドプロセスは課金対象であるため、プロジェクトに Cloud 請求先アカウントが関連付けられている必要があります。

注: 組織のポリシーの制約で gcp.resourceLocations を使用している場合は、適切なマルチリージョン ロケーションを含める必要があります。たとえば、us リージョンのいずれかにデプロイする場合は、us-locations を含める必要があります。これにより、Cloud Build が Artifact Registry ストレージ バケットにアクセスできます。

ビルドイメージ ログを表示する

ユーザー プロジェクトでビルドイメージ プロセスを実行すると、ビルドログにアクセスできます。gcloud CLI または Google Cloud コンソールを使用して、Cloud Logging を介して使用可能なログにアクセスできます。

gcloud

1. gcloud functions deploy コマンドを使用して、関数をデプロイします。

2. ログの URL は、ターミナル ウィンドウにレスポンスの一部として表示されます。次に例を示します。

   Deploying function (may take a while - up to 2 minutes)...⠹
   **For Cloud Build Stackdriver Logs**, visit:
   https://console.cloud.google.com/logs/viewer?project=&advancedFilter=resource.type%
   3Dbuild%0Aresource.labels.build_id%3D38d5b662-2315-45dd-8aa2-
   380d50d4f5e8%0AlogName%3Dprojects%2F%
   2Flogs%2Fcloudbuild
   Deploying function (may take a while - up to 2 minutes)...done.

Google Cloud コンソール

1. Cloud Run functions の概要ウィンドウで、調査する関数の名前をクリックします。
2. [詳細] タブをクリックします。
3. [全般情報] ペインで、[コンテナビルドのログ] のリンクをクリックして [ログ エクスプローラ] ペインを開きます。
4. いずれかの行をクリックすると、そのビルドログ エントリの詳細が表示されます。ファイルに関連付けられているエラーエントリの場合、これらの詳細にはファイルの名前、行、列が含まれます。

イメージ レジストリ

重要: 2025 年 2 月 18 日以降、Cloud Run functions（第 1 世代）のデプロイは、以前の選択に関係なく Artifact Registry を使用するように移行されます。これは、Container Registry を指す第 1 世代の関数に影響を与えることなく、Container Registry のシャットダウンに移動するためのものです。

Cloud Run functions は、関数のソースコードからビルドされたイメージを保存するために Artifact Registry を使用します。イメージは、REGION-docker.pkg.dev/PROJECT_ID/gcf-artifacts という名前のリポジトリに保存されます。

Artifact Registry は、関数と同じプロジェクトに存在する必要があります。次のようにして、Artifact Registry ベースの関数を作成または更新できます。

gcloud

お客様が管理する Artifact Registry の場合は、次のコマンドを実行します。

gcloud functions deploy --no-gen2 FUNCTION \
--docker-repository=REPOSITORY
[FLAGS...]

次のように置き換えます。

• FUNCTION: 関数名。
• REPOSITORY: Artifact Registry リポジトリの完全修飾名（projects/PROJECT_NAME/locations/LOCATION/repositories/REPOSITORY の形式）。

Google が管理する Artifact Registry の場合は、次のコマンドを使用します。

gcloud functions deploy --no-gen2 FUNCTION \
--docker-registry=artifact-registry
[FLAGS...]

Google Cloud コンソール

1. Google Cloud コンソールで [Cloud Run functions] ページに移動します。
   [Cloud Run functions] ページに移動

2. Artifact Registry を使用する関数の名前をクリックします。

3. [編集] をクリックします。

4. [ランタイム、ビルド...] をクリックして、詳細な構成オプションを開きます。

5. メニューバーから [セキュリティとイメージのリポジトリ] をクリックして、[セキュリティ] タブを開きます。

6. [イメージ リポジトリ] で、使用している Artifact Registry のタイプに応じて、次のいずれかを選択します。

   • お客様が管理する Artifact Registry独自の Docker リポジトリを設定する場合は、このオプションを使用します。
   • Google が管理する Artifact Registry独自の設定の代わりに Google が管理する Docker リポジトリを使用する場合は、このオプションを使用します。

7. [お客様が管理する Artifact Registry] で、[Artifact Registry] プルダウンを使用して、必要な Artifact Registry リポジトリを選択するか、プロンプトに従って新しいリポジトリを作成します。

8. [次へ] をクリックします。

9. [デプロイ] をクリックします。

詳しい価格情報については、Cloud Run functions の価格をご覧ください。

プライベート プールでビルドを保護する

npm パッケージなどの依存関係を関数で使用できるように、ビルドプロセス中、Cloud Build には無制限のインターネット アクセスが許可されます。VPC Service Controls（VPC SC）境界を設定し、ビルドのアクセスを境界内に保存された依存関係に制限する場合は、Cloud Build のプライベート ワーカープール機能を使用できます。

通常、次の手順でプライベート プールを設定します。

1. プライベート ワーカープールを作成します。プライベート プールの作成と管理をご覧ください。

2. VPC Service Controls の境界を構成します。VPC Service Controls の使用をご覧ください。

3. プライベート ワーカープールが関数とは異なるプロジェクトにある場合、Cloud Run functions サービス エージェントのサービス アカウント（[e-mail]）に cloudbuild.workerPoolUser ロールを付与し、Cloud Build サービスがワーカープールにアクセスできるようにします。

   gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
       --member serviceAccount:[e-mail]
       --role roles/cloudbuild.workerPoolUser

   ここで、FUNCTION_PROJECT_NUMBER は関数が実行されるプロジェクトの番号、PRIVATE_POOL_PROJECT_ID はワーカープールが存在するプロジェクトの ID です。詳細については、プライベート プールでのビルドの実行をご覧ください。

4. 関数をデプロイしてプライベート プールを使用します。

gcloud

gcloud functions deploy FUNCTION_NAME --no-gen2\
  --runtime RUNTIME \
  --build-worker-pool PRIVATE_POOL_NAME
  [FLAGS...]

ここで、FUNCTION_NAME は関数の名前、RUNTIME は使用しているランタイム、PRIVATE_POOL_NAME はプールの名前です。

特定のプライベート プールの使用を停止し、代わりにデフォルトの Cloud Build プールを使用するには、再デプロイ時に --clear-build-worker-pool フラグを使用します。

gcloud functions deploy FUNCTION_NAME --no-gen2 \
  --runtime RUNTIME \
  --clear-build-worker-pool
  [FLAGS...]

ここで、FUNCTION_NAME は関数の名前、RUNTIME は使用しているランタイムです。

Google Cloud コンソール

1. Cloud Run functions の概要ページで、[関数を作成] を選択します。

2. [ランタイム、ビルド...] セクションで [ビルド] タブをクリックし、[Build ワーカープール] テキスト ボックスにプライベート プールの完全なリソース名を入力します。

詳細については、プライベート プールでビルドを実行するをご覧ください。

カスタム サービス アカウントでビルドを保護する

Cloud Run functions は、ソースコードを取得して Cloud Build に送信し、コンテナ化します。コンテナ化された関数は Artifact Registry に保存され、サービスとして Cloud Run にデプロイされます。デフォルトでは、Cloud Build はビルドの実行時にプリンシパルとして機能するサービス アカウントを割り当てます。2024 年 7 月より、組織内の新しいプロジェクトは、Compute Engine のデフォルトのサービス アカウントを使用して、ビルドを実行するプリンシパルとして機能します。詳細については、Cloud Build のデフォルト サービス アカウントの変更をご覧ください。セキュリティ上の理由から、Compute Engine のデフォルトのサービス アカウントにはビルドを実行するための十分な権限がありません。

2024 年 7 月より前に作成された Google Cloud プロジェクトの場合、Cloud Build は以前の Cloud Build サービス アカウントを使用します。このサービス アカウントは、プロジェクトのニーズに対して権限が緩すぎる可能性がある幅広いユースケースをユーザーが実行できるように設計されています。既存のプロジェクトをこのサービス アカウントから移動する場合は、次の手順を使用すると関数のビルド環境のセキュリティをさらに強化できます。

1. 以前の Cloud Build サービス アカウントがビルドに使用されないようにします。
2. デフォルトのコンピューティング サービス アカウントがビルドに使用されないようにします。
3. ビルドに使用する新しいサービス アカウントを適切にスコープされた権限で構成します。
4. 構成済みのサービス アカウントをビルドに使用します。

以前の Cloud Build サービス アカウントがビルドに使用されないようにする

警告: これにより、新しいサービス アカウントを割り当てるまで、すべてのデプロイが一時的に中断されます。

プロジェクトが以前の Cloud Build サービス アカウントを使用していることを確認するには、関数のビルドの詳細を調べます。デフォルトのビルド サービス アカウントの形式は次のとおりです。

[e-mail]

このサービス アカウントの使用を強制的に無効にするには、組織のポリシー制約 cloudbuild.useBuildServiceAccount を Not Enforced に設定します。または、ロールの付与をすべて削除すると、 Google Cloudリソースへのアクセスが制限されます。

デフォルトのコンピューティング サービス アカウントがビルドに使用されないようにする

警告: これにより、新しいサービス アカウントを割り当てるまで、すべてのデプロイが一時的に中断されます。

デフォルトのコンピューティング サービス アカウントの形式は [e-mail] です。組織のポリシー cloudbuild.useComputeServiceAccount を Not Enforced に設定すると、ビルドにデフォルトで使用されないようにできます。また、このサービス アカウントを無効にすると、 Google Cloud リソースへのアクセスに使用できなくなります。

関数のビルド用のサービス アカウントを指定する

関数のデプロイ時に、関数の構成の一部としてビルド サービス アカウントを指定できます。以前の Cloud Build サービス アカウントとデフォルトのコンピューティング サービス アカウントがビルドに使用できない場合は、関数をデプロイするためにビルド サービス アカウントを指定する必要があります。

関数のビルドサービス アカウントの構成と使用については、Cloud Build のカスタム サービス アカウントをご覧ください。