ビルドプロセスの概要

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

注: Container Registry は非推奨となりました。今後、提供終了となります。2024 年 1 月 8 日より前に Container Registry を使用していない組織では、デフォルトで Artifact Registry に新しい gcr.io リポジトリがホストされます。2024 年 5 月 15 日以降、それまで Container Registry を使用していなかった Google Cloud プロジェクトでは、Artifact Registry で gcr.io ドメインのイメージのホスティングと管理のみがサポートされます。

Container Registry は 2025 年 3 月 18 日に提供終了となる予定です。サポート終了の詳細については、Container Registry のサポート終了をご覧ください。

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

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

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

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

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

• Cloud Storage はプロジェクトで直接使用され、関数のソースコード ディレクトリがプロジェクト内のバケットに保存されます。次の点にご注意ください。

  • デフォルトの暗号化を使用している場合、このバケットの名前は gcf-sources-PROJECT_NUMBER-REGION です。
  • CMEK でデータを保護している場合、バケットの名前は gcf-sources-PROJECT_NUMBER-REGION-CMEK_KEY_HASH です。
  • このバケットには保持期間が設定されていません。

ビルドプロセスの特徴

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

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

イメージ レジストリ

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

Cloud Functions（第 1 世代）では、デフォルトで Artifact Registry が使用されます。Container Registry は非推奨になります。

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

gcloud

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

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

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

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

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

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

Google Cloud コンソール

1. Google Cloud コンソールの [Cloud Functions] ページに移動します。
   [Cloud 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 Functions の価格をご覧ください。

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

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

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

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

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

3. プライベート ワーカープールが関数とは異なるプロジェクトにある場合、Cloud 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 \
  --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 \
  --runtime RUNTIME \
  --clear-build-worker-pool
  [FLAGS...]

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

Google Cloud コンソール

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

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

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