Cloud Run サービス、ジョブ、ワーカープールをデプロイする

このドキュメントでは、Cloud Run サービス、Cloud Run ジョブ、Cloud Run ワーカープールなどのアプリケーションをデプロイする方法について説明します。

Cloud Deploy を使用すると、コンテナベースのワークロードを任意の Cloud Run サービスジョブ、またはワーカープールにデプロイできます。Cloud Run サービスまたはワーカープールの Cloud Run ターゲットにデプロイする場合、Cloud Deploy のすべての機能はサポートされますが、Cloud Run ジョブのカナリア デプロイはサポートされません。

このドキュメントでは、Cloud Run にデプロイするために完了する必要がある 3 つの主要な構成について説明します。

制限事項

  • ターゲットごとにデプロイできる Cloud Run サービス、ジョブ、ワーカープールは 1 つだけです。

  • Cloud Run ジョブに対してカナリア デプロイを実行することはできません。

    ただし、Cloud Run サービスとワーカープールではカナリア デプロイを使用できます。

  • Cloud Deploy を使用して Cloud Run 関数をデプロイするには、関数をコンテナにビルドして Cloud Run サービスとしてデプロイするように CI ワークフローを変更する必要があります。

始める前に

ターゲット構成を作成する

ターゲットは、デリバリー パイプライン YAML で構成することも、別のファイルで構成することもできます。また、同じファイルで複数のターゲットを構成することもできます。

ターゲットは、デリバリー パイプラインと同じプロジェクトとリージョンで定義する必要があります。ただし、ターゲットのデプロイ先となるサービス、ジョブ、ワーカー プールは、サービス アカウントがこれらのプロジェクトにアクセスできる限り、異なるプロジェクトとリージョンに存在できます。

ターゲット定義で、Cloud Run サービスが作成される場所を特定する run スタンザを作成します。

ターゲット定義で Cloud Run サービス、ジョブ、ワーカープールを指定する構文は次のとおりです。

run:
 location: projects/[project_name]/locations/[region_name]

このリソース ID には次の要素が使用されます。

  • project_name は、Cloud Run サービス、ジョブ、ワーカープールが作成される Google Cloud プロジェクトの名前です。

    ターゲットごとにこれを行います。Cloud Run のサービス、ジョブ、ワーカープールごとに異なるプロジェクトを指定することをおすすめします。同じプロジェクトに複数のサービス、ジョブ、ワーカープールが必要な場合は、skaffold.yaml 構成ファイルで Skaffold プロファイルを使用する必要があります。

  • region_name は、サービス、ジョブ、ワーカープールが作成されるリージョンです。サービス、ジョブ、ワーカープールは、Cloud Run がサポートする任意のリージョンに配置できます。

以下は、作成する Cloud Run サービス、ジョブ、ワーカープールを定義するターゲット構成の例です。

      apiVersion: deploy.cloud.google.com/v1
      kind: Target
      metadata:
       name: dev
      description: development service
      run:
       location: projects/my-app/locations/us-central1

このターゲットは、Cloud Deploy デリバリー パイプラインの定義内または個別に定義できます。いずれにしても、リリースを作成して Cloud Run サービス、ジョブ、ワーカープールをデプロイする前に、ターゲットを登録する必要があります。

Skaffold 構成を作成する

Cloud Run デプロイskaffold.yaml ファイルの例を次に示します。

apiVersion: skaffold/v4beta7
kind: Config
metadata: 
  name: cloud-run-application
manifests:
  rawYaml:
  - service.yaml
deploy:
  cloudrun: {}

この skaffold.yaml ファイルの内容は以下のとおりです。

  • manifests.rawYaml は、Cloud Run サービス定義の名前を指定します。

    この例では、service.yaml は Skaffold がデプロイする Cloud Run サービスを定義するファイルです。このファイル名は任意ですが、慣例により、サービスの場合は service.yaml、ジョブの場合は job.yaml、ワーカープールの場合は workerpool.yaml とします。

  • deploy スタンザは、マニフェストのデプロイ方法(プロジェクトとロケーションなど)を指定します。deploy は必須です。

    空の {} はそのままにしておくことをおすすめします。Cloud Deploy は、ターゲット定義のプロジェクトとロケーションに基づいて、レンダリング中にこの値を入力します。

    ただし、ローカル開発の場合はここで値を指定できます。ただし、ここで値が指定されているかどうかに関係なく、Cloud Deploy は常にターゲット定義のプロジェクトとロケーションを使用します。

Cloud Run サービス定義を作成する

Cloud Run サービス定義を作成するには、手動で作成するか、既存のサービスから定義をコピーします。このセクションでは、両方の手順について説明します。

オプション 1: 新しい Cloud Run service.yaml を作成する

service.yaml は、Cloud Run サービスを定義します。リリースを作成すると、Skaffold はこの定義を使用してサービスをデプロイします。

簡単な例を次に示します。

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
 name: [SERVICE_NAME]
spec:
 template:
  spec:
   containers:
   - image: [IMAGE_PATH]

ここで

  • [SERVICE_NAME] は、この Cloud Run サービスの名前です。

  • [IMAGE_PATH] は、このサービスでデプロイするコンテナ イメージを指します。

オプション 2: Google Cloud コンソールを使用して既存のサービスから service.yaml をコピーする

Google Cloud コンソールを使用してサービスを作成するか、既存のサービスを使用し、そこから service.yaml をコピーできます。

Google Cloud CLI を使用して service.yaml を取得するには:

gcloud run services describe [service_name] --format=export

Google Cloud コンソールから service.yaml を取得するには:

  1. Google Cloud コンソールで、Cloud Run サービスのページに移動します。

  2. 使用する定義を持つ既存のサービスを選択します。

または、新しく作成して選択します。サービスを選択すると、[サービスの詳細] ページが表示されます。

[YAML] タブを表示するサービスの詳細ページのGoogle Cloud コンソール

  1. [YAML] タブを選択します。

  2. [編集] をクリックし、YAML の内容をファイル システム内の service.yaml という新しいファイルにコピーします。これにより、リリースを作成するときに Skaffold によって使用できるようになります。

Cloud Run ジョブ定義を作成する

Cloud Run ジョブ定義をデプロイするには、手動で作成するか、既存のジョブからコピーします。このセクションでは、両方の手順について説明します。

ジョブは、Cloud Deploy によってデプロイされたときに必ずしも実行されるとは限りません。これは、デプロイ後に実行されるアプリケーションであるサービスとは異なります。ジョブの呼び出し方法はジョブ自体によって異なります。

オプション 1: 新しい Cloud Run job.yaml を作成する

job.yaml は、Cloud Run ジョブを定義します。リリースを作成すると、Skaffold はこの定義を使用してジョブをデプロイします。

簡単な例を次に示します。

apiVersion: run.googleapis.com/v1
kind: Job
metadata:
 name: [JOB_NAME]
spec:
  template:
  spec:
   containers:
   - image: [IMAGE_PATH]

ここで

  • [JOB_NAME] は、この Cloud Run ジョブの名前です。

  • [IMAGE_PATH] は、このジョブ用にデプロイするコンテナ イメージを指します。

オプション 2: Google Cloud コンソールを使用して既存のジョブから job.yaml をコピーする

Google Cloud コンソールを使用してジョブを作成するか、既存のジョブを使用し、そこから job.yaml をコピーできます。

Google Cloud CLI を使用して job.yaml を取得するには:

gcloud run jobs describe [job_name] --format=export

Google Cloud コンソールから job.yaml を取得するには:

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

  2. 使用する定義の既存のジョブを選択します。

または、新しく作成して選択します。ジョブを選択すると、[ジョブの詳細] ページが表示されます。

[YAML] タブを表示しているGoogle Cloud コンソールのジョブの詳細ページ

  1. [YAML] タブを選択します。

  2. [編集] をクリックし、YAML の内容をファイル システム内の job.yaml という新しいファイルにコピーします。これにより、リリースを作成するときに Skaffold によって使用できるようになります。

Cloud Run ワーカープールの定義を作成する

Cloud Run ワーカープール定義をデプロイするには、手動で作成するか、既存のワーカープールから定義をコピーします。このセクションでは、両方の手順について説明します。

オプション 1: 新しい Cloud Run workerpool.yaml を作成する

workerpool.yaml は、Cloud Run ワーカープールを定義します。リリースを作成すると、Skaffold はこの定義を使用してワーカープールをデプロイします。

簡単な例を次に示します。

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
 name: [WORKERPOOL_NAME]
 annotations:
  run.googleapis.com/launch-stage: BETA
spec:
  template:
   spec:
    containers:
    - image: [IMAGE_PATH]

ここで

  • [WORKERPOOL_NAME] は、この Cloud Run ワーカープールの名前です。

  • [IMAGE_PATH] は、このワーカープールにデプロイするコンテナ イメージを指します。

オプション 2: Google Cloud コンソールを使用して既存のワーカープールから workerpool.yaml をコピーする

Google Cloud コンソールを使用してワーカープールを作成するか、既存のワーカープールを使用し、そこから workerpool.yaml をコピーできます。

Google Cloud CLI を使用して workerpool.yaml を取得するには:

gcloud beta run worker-pools describe [workerpool_name] --format=export

Google Cloud コンソールから workerpool.yaml を取得するには:

  1. Google Cloud コンソールで、Cloud Run の [ワーカープール] ページに移動します。

  2. 使用する定義の既存のワーカープールを選択します。

または、新しく作成して選択します。ワーカープールを選択すると、[ワーカープールの詳細] ページが表示されます。

[YAML] タブを表示しているGoogle Cloud コンソールのワーカープールの詳細ページ

  1. [YAML] タブを選択します。

  2. YAML の内容をファイル システム内の workerpool.yaml という新しいファイルにコピーします。これにより、リリースを作成するときに Skaffold によって使用できるようになります。

すべてを組み合わせる

Cloud Run サービス、ジョブ、ワーカープールの定義、skaffold.yaml 構成、Cloud Deploy ターゲット定義があり、ターゲットを Cloud Deploy リソースとして登録したら、配信パイプラインを呼び出してリリースを作成し、パイプラインで定義されたターゲットの進行状況を追跡できます。

Cloud Deploy を使用してアプリを Cloud Run にデプロイするのクイックスタートに、これらすべての動作が示されています。

リビジョン間のサービスの動作

サービスを再デプロイすると、新しいリビジョンは新しくデプロイされた service.yaml に基づきます。以前のリビジョンに関する情報は、新しくデプロイされた YAML で同じでない限り、保持されません。たとえば、新しい YAML にない構成設定やラベルが以前のリビジョンにある場合、それらの設定やラベルは新しいリビジョンにはありません。

Cloud Run ジョブのトリガー

ジョブをデプロイしたら、Cloud Run のドキュメントで説明されているようにトリガーできます。

複数のプロジェクトに Cloud Run サービス、ジョブ、ワーカープールをデプロイする

異なるプロジェクトにあるサービス、ジョブ、ワーカープールをデプロイする必要がある場合、実行サービス アカウントには、これらのサービス、ジョブ、ワーカープールが定義されているプロジェクトにアクセスする権限が必要です。

詳細については、Cloud Deploy 実行サービス アカウントIdentity and Access Management のロールと権限をご覧ください。

Cloud Run functions をデプロイする

Cloud Run functions は、関数がデプロイされるたびにソースコードをビルドします。このため、パイプライン内の各ターゲット ランタイムで取得されるアーティファクトが若干異なる場合があります。これは Cloud Deploy のベスト プラクティスに反します。代わりに、Cloud Run サービスを直接使用することをおすすめします。これにより、単一のアーティファクトをビルドして、環境間で昇格させることができます。

  1. Cloud Run functions の service.yaml で確認します。

    これは、次のコマンドを実行して取得できます。

    gcloud run services describe FUNCTION_NAME \
    --format=export \
    --region=REGION \
    --project=PROJECT
    
  2. 次のアノテーションが存在する場合は削除します。

    • run.googleapis.com/build-base-image
    • run.googleapis.com/build-name
    • run.googleapis.com/build-source-location
    • run.googleapis.com/build-enable-automatic-updates
  3. spec.spec.containers.image の値を IMAGE_TAG に置き換えます。

  4. Cloud Run サービスをターゲットとして、デリバリー パイプラインとターゲットを作成します。

  5. CI プロセスでビルドステップとデプロイ ステップを分離します。Google Cloud CLI を使用して関数をデプロイする代わりに、次の手順を行います。

    1. Cloud Build を使用して関数をコンテナにビルドします。

      gcloud builds submit --pack image=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME \
      --project=PROJECT \
      --region=REGION
      
    2. Cloud Deploy を使用してリリースを作成します。

      gcloud deploy releases create RELEASE_NAME \
      --project=DEPLOY_PROJECT \
      --region=REGION \
      --delivery-pipeline=DELIVERY_PIPELINE \
      --images=IMAGE_TAG=REGION-docker.pkg.dev/PROJECT/cloud-run-source-deploy/IMAGE_NAME
      

      コマンドの内容:

      • RELEASE_NAME は、このリリースに付ける名前です。名前は、このデリバリー パイプラインのすべてのリリース間で一意である必要があります。

      • DEPLOY_PROJECT は、デプロイ パイプラインを作成したプロジェクトのプロジェクト ID です。

      • DELIVERY_PIPELINE は、ターゲットの進行状況を通じて、このリリースのデプロイを管理するデリバリー パイプラインの名前です。この名前は、パイプライン定義の name フィールドと一致する必要があります。

      • REGION は、リリースを作成するリージョンの名前です(例: us-central1)。必須入力項目です。

      • IMAGE_NAME は、前の手順で関数をビルドしたときにイメージに付けた名前です。

次のステップ