Cloud Functions イメージのビルド

概要

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

イメージの構築プロセスは完全に自動化されているので、ユーザーが直接入力する必要はありません。ただし、古い Node.js 8 ランタイムと Go 1.11 ランタイムのプロセスと、他のランタイム(Java 11、Python 3.7、Python 3.8、Node.js 10、Go 1.13)の現在のプロセスとでは多少の違いがあります。

Node.js 8 ランタイムと Go 1.11 ランタイム

古いランタイムの場合、ビルドプロセスは、ユーザー プロジェクトではなく、テナント プロジェクトという関連プロジェクトで行われます。テナント プロジェクトでビルドを実行すると、ランタイムに関するいくつかの問題が解決されましたが、次のような新しい問題も発生しました。

  • ビルドはプロジェクト内では行われないため、ビルドログにアクセスして、発生するビルドの問題を整理することはできません。

  • このプロセスには、内部的な 1 日単位のビルド時間割り当てが必要ですが、ごく普通の状況では、使い切ってしまう可能性があります。これにより、割り当てが補充されるまで、新しいソースコードのデプロイの機能が制限される可能性があります。

  • 関数のコンテナ イメージが格納されている Container Registry へのアクセス権がないため、使用可能なイメージを表示できません。

最新のランタイム

Java 11 以降、Python 3.7 以降、Node.js 10 以降、Go 1.13 以降などの新しいランタイムの場合、ビルドプロセスで使用されるすべてのリソースはテナント プロジェクトではなく、独自のユーザー プロジェクトで実行されます。これがデフォルトのプロセスになりました。

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

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

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

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

  • Cloud Storage はプロジェクトで直接使用されるため、関数のソースコード ディレクトリが gcf-sources-<PROJECT_NUMBER>-<REGION> というバケットに表示されます。

デフォルト プロセスの特性

この変更により、デフォルト プロセスを使用するランタイムには次の特性があります。

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

    API を手動で有効にするには、上のリンクをクリックし、プルダウン メニューからプロジェクトを選択して、[Continue] をクリックします。

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

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

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

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

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

ビルドイメージのログへのアクセス

ユーザー プロジェクトでビルドイメージ プロセスを実行すると、ログを作成する際のアクセスが容易になります。gcloud CLI または Cloud Console を使用して、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.
    

Cloud Console

  1. [Cloud Functions] 画面で、対象の関数の名前をクリックします。[関数の詳細] ページが開きます。

  2. [コンテナビルド] セクションが表示されるまで、下にスクロールします。ビルドにエラーが発生していない場合は、ビルドログを表示するためのリンクが表示されます。次に示すように、ビルドにエラーが発生した場合は [コンテナビルド] セクションに表示されます。[詳細] をクリックして、ビルドログを直接表示します。

    コンテナビルドのセクションの出力を示すスクリーンショット

  3. ログビューアの画面が開きます。関心のあるエントリをクリックします。

  4. 完全なビルドのログエントリが開き、影響を受けるファイル、エラーの説明(この場合は pom.xml に欠落しているかっこ)と、エラーの行と列が表示されます。

    ビルドのログエントリを示すスクリーンショット

プライベート プールを使用したビルドの保護

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

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

  1. プライベート ワーカープールを作成します。プライベート プールの作成と管理をご覧ください。
  2. VPC Service Controls の境界を構成します。VPC Service Controls の使用をご覧ください。

  3. プライベート ワーカープールが関数とは異なるプロジェクトにある場合、Cloud Functions サービス エージェントのサービス アカウント(service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com)にcloudbuild.workerPoolUser ロールを付与し、Cloud Build サービスがワーカープールにアクセスできるようにします。

    gcloud projects add-iam-policy-binding PRIVATE_POOL_PROJECT_ID \
        --member serviceAccount:service-FUNCTION_PROJECT_NUMBER@gcf-admin-robot.iam.gserviceaccount.com
        --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 は使用しているランタイムです。

    Cloud Console

    [Create function] ページの [Runtime, build and connections settings] セクションで、[Build] タブを選択し、[Build worker pools Selected environment] テキスト ボックスに PRIVATE_POOL_NAME を入力します。ここで PRIVATE_POOL_NAME はプール名です。

    Cloud Console のスクリーンショット