アプリケーションのデプロイ

このページでは、Cloud Deploy を使用してアプリケーションを目的のランタイム環境に取り込む方法について説明します。 これを行う前に、デリバリー パイプラインとターゲットを作成する必要があります。

始める前に

このセクションでは、Cloud Deploy を使用してアプリケーションをデプロイする前に準備する必要があることについて説明します。

• 実行サービス アカウントに必要な IAM ロールと権限があることを確認します。

• デリバリー パイプラインとターゲットを作成します。

  Cloud Deploy は、Google Kubernetes Engine、Cloud Run、GKE Enterprise クラスタにデプロイできます。ターゲット構成は、デプロイする対象によって異なります。

• コンテナ イメージとマニフェストを設定する。

  デプロイするコンテナ イメージと、GKE にデプロイする Kubernetes マニフェスト、または Cloud Run にデプロイするサービス YAML ファイルが1 つ以上必要です。

  イメージをビルドして配置するには、継続的インテグレーション パイプラインやその他のプロセスが必要です。CI ツールは、Cloud Build、Jenkins、または Cloud Deploy デリバリー パイプラインに提供できるコンテナ イメージになるあらゆるものです。

• skaffold.yaml 構成ファイルを用意します。

  Cloud Deploy は skaffold render を呼び出し、このファイルと skaffold apply を使用して Kubernetes マニフェストをレンダリングし、ターゲットにデプロイします。 これを行うには、Skaffold に少なくとも skaffold.yaml が必要です。次の 2 つの方法のいずれかで取得できます。

  • 独自に作成する。

    この例のように、skaffold.yaml ファイルは、サポートされている Skaffold バージョンに対応する名前空間を最初の行で参照する必要があります。

    `apiVersion: skaffold/v4beta7`
    

  • 自動生成させる。

    skaffold.yaml ファイルがまだない場合は、Cloud Deploy で作成できます。このファイルは、Cloud Deploy のオンボーディング、学習、デモに適しています。本番環境のワークロードには使用しないでください。

  詳細については、Cloud Deploy での Skaffold の使用をご覧ください。また、Cloud Deploy でのマニフェストの管理では、Helm、Kustomize、kpt などのマニフェスト管理ツールで Skaffold と Cloud Deploy を使用する方法について詳しく説明します。

任意のランタイム環境用に Cloud Deploy を設定する

Cloud Deploy では、アプリケーションを次のいずれかのランタイム環境にデプロイできます。

• GKE
• GKE Enterprise
• Cloud Run

デリバリー パイプラインを呼び出してリリースを作成する

ランタイムにデプロイするように Cloud Deploy を構成したら、作成したデリバリー パイプラインに従ってデプロイするアプリケーションを送信できます。

1. 通常の継続的インテグレーション（CI）プロセスを実行し、デプロイ可能なアーティファクトを作成します。

2. Cloud Deploy を呼び出してリリースを作成し、デリバリー パイプラインを開始します。

   Skaffold 構成を含むディレクトリから次のコマンドを実行します。

   gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION
   

   このコマンドにより、ディレクトリの内容全体とサブディレクトリの tar ファイルが作成されるため、ホーム ディレクトリまたはルート ディレクトリからこのコマンドを実行することは望ましくない場合があります。Skaffold 構成を含むディレクトリからコマンドを実行するか、後で説明するように --source= オプションを含めることをおすすめします。

   コマンドの内容:

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

   動的リリース名は、'$DATE' と '$TIME' のいずれか、または両方を含めることで指定できます。たとえば、このコマンドを午後 3 時 7 分（UTC）に呼び出した場合、'rel-$TIME' は rel-1507 として解決されます。'$DATE' と '$TIME' は単一引用符で囲む必要があり、時刻は、コマンドを呼び出すマシン上の UTC 時刻です。

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

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

注: 必要に応じて、--source=SOURCE_PATH を含めて skaffold.yaml ファイルの場所を指定できます。デフォルトは現在のディレクトリです。

このコマンドは、構成ファイルを含む tar ファイルを Cloud Storage バケットにアップロードし、リリースを作成します。また、Cloud Deploy では、ロールアウトが自動的に作成され、デリバリー パイプラインで定義された最初のターゲットにイメージがデプロイされます。

このコマンドで示されるパラメータに加えて、次のオプションのいずれかを含めることが可能です。

• --images=<name=path/name:$IMAGE_SHA>,<name=path/name:$IMAGE_SHA>

  イメージ名のフルパスを置換するイメージ名のコレクション。

• --build-artifacts=<path/file>

  Skaffold ビルド アーティファクト出力ファイルへの参照。これは、イメージのフルパスの置換を表すために渡すことができます。

この 2 つのオプションは相互に排他的です。

次のいずれかのフラグを含めると、Cloud Deploy で skaffold.yaml ファイルを生成できます。

• --from-k8s-manifest=K8S_MANIFEST

  生成される Skaffold 構成ファイルは、このフラグを渡す Kubernetes マニフェストに基づいています。このフラグを --skaffold-file フラグまたは --source フラグとともに使用すると、エラーが発生します。詳しくは、skaffold.yaml の生成をご覧ください。

• --from-run-manifest=RUN_MANIFEST

  生成される Skaffold 構成ファイルは、このフラグを渡す Cloud Run サービス YAML に基づいています。このフラグを --skaffold-file フラグまたは --source フラグとともに使用すると、エラーが発生します。詳しくは、skaffold.yaml の生成をご覧ください。

この 2 つのオプションは相互に排他的です。

また、tar ファイルに含めたくないファイルがディレクトリに存在する場合は、.gcloudignore ファイルを含めることもできます。

Google Cloud コンソールからリリースを作成する

Google Cloud コンソールを使用して、デリバリー パイプラインのリリースを作成できます。これは Cloud Deploy を試すには便利ですが、本番環境のワークロードには適していません。

次の手順では、デリバリー パイプラインと 1 つ以上のターゲットをすでに作成していることを前提としています（Google Cloud コンソールを使用してデリバリー パイプラインを作成することもできます）。

1. [デリバリー パイプラインの詳細] ページで、特定のデリバリー パイプラインに対して [リリースを作成] をクリックします。

   

2. [コンテナを選択] フィールドに、デプロイするコンテナ イメージのパスを貼り付けるか入力します。このフィールドに事前入力されたデフォルトのコンテナを使用して、評価することもできます。

   [選択] をクリックして、Artifact Registry または Container Registry からコンテナ イメージを選択することもできます。

3. このリリースの一意の名前を [リリース名] フィールドに指定するか、指定されているデフォルトの名前を使用します。

4. [ロールアウト名] フィールドにロールアウトの名前を入力するか、指定されたデフォルト名を使用します。

   この名前は、このリリースの最初のターゲットへのロールアウトに使用されます。以降のターゲットの場合は、[プロモーション] ダイアログまたは gcloud deploy releases promote コマンドでロールアウトに名前を付けることができます。

5. 必要に応じて、[説明] フィールドにこのリリースの説明を入力します。

6. [Deployment の詳細] で、GKE デプロイまたは Cloud Run サービスの名前を入力するか、指定されたデフォルト名を使用します。

   GKE の場合は、Cloud Deploy によってマニフェストが生成されます。Cloud Run の場合、Cloud Deploy は、サービスの作成に使用されるサービス定義を生成します。

7. [作成] をクリックします。

   

Cloud Deploy は、生成されたマニフェストまたは Cloud Run サービス定義と、生成された skaffold.yaml を使用してリリースを作成します。

デプロイのタイムアウトを変更する

GKE と GKE Enterprise のターゲット クラスタへのデプロイでは、Kubernetes が安定したデプロイを報告するまで待機する時間に影響する 3 つのタイムアウトがあります。

• Cloud Build が Cloud Deploy に対して実行するオペレーションに対するタイムアウトは 1 時間です。

  このタイムアウトは、実行環境の構成で変更できます。

• Skaffold には、ヘルスチェックのタイムアウト（deploy.statusCheckDeadlineSeconds）が設定されています。これは、デプロイが安定するまでの待機時間（秒単位）です。

  デフォルトは 600 秒（10 分）です。このタイムアウトを使用するには、deploy.statusCheck を true に設定する必要があります。デフォルトでは、statusCheck が false の場合、ステータス チェックは行われず、kubectl apply が正常に完了した後、ロールアウトは成功とマークされます。

• kind: Deployment の Kubernetes リソースには、Deployment.spec.progressDeadlineSeconds があります。これは、Deployment が安定したと報告するまでの Kubernetes の待機時間です。

  このタイムアウトは、Deployment リソースにのみ適用されます。これら 2 つのタイムアウトが連携する仕組みは次のとおりです。

  • Kubernetes で Deployment.spec.progressDeadlineSeconds が設定されていない場合、デフォルト値か、明示的に設定されているかにかかわらず、Skaffold ヘルスチェックのタイムアウトが有効なタイムアウトになります。

  • Deployment.spec.progressDeadlineSeconds が Kubernetes で設定されている場合、Skaffold は固有のヘルスチェックのタイムアウトを無視し、Kubernetes の進行状況期限が有効なタイムアウトになります。ただし、Kubernetes のタイムアウトが明示的に 600（10 分）に設定されている場合、Skaffold はデフォルト（未設定）として無視し、Skaffold のタイムアウトを使用します（設定されている場合）。

  • どちらのタイムアウトも設定されていない場合、有効なタイムアウトは Skaffold のデフォルト値 600（10 分）です。

  Deployment 以外に、Kubernetes リソースには、安定性のタイムアウトに影響しないタイムアウトを設定できます。次のいずれかが存在する場合は、それらが安定性タイムアウトと競合していないことを確認します。

  Skaffold（または Cloud Build）がタイムアウトしても、GKE のデプロイは引き続き実行されます。Cloud Deploy は失敗しますが、GKE クラスタでは成功または失敗する場合があります。

デプロイの安定性タイムアウトを変更するには:

1. skaffold.yaml で deploy.statusCheck が true に設定されていることを確認します。

   デフォルトは true です。true の場合、Skaffold は、次のステップのタイムアウト値に従って、ヘルスチェックが安定したデプロイを報告するのを待機します。

2. skaffold.yaml で、statusCheckDeadlineSeconds を待機する秒数に設定します。

   deploy:
     ...
     statusCheck: true
     statusCheckDeadlineSeconds: 600
     ...
   

   デフォルトは 600（10 分）です。Skaffold は、安定したデプロイがこの時間待機します。デプロイが安定する前にこの時間を超えると、デプロイは失敗します。

3. 必要に応じて、statusCheckDeadlineSeconds の後に tolerateFailuresUntilDeadline: true を追加できます。

   この設定により、1 つのデプロイが失敗した場合に終了しないように Skaffold に指示し、statusCheckDeadlineSeconds が期限切れになるまで障害を許容します。この設定は、ステータスが安定した状態に達するまでにより多くのリソースが必要になる場合（ステータス チェックの期限まで）に役立ちます。

   たとえば、Istio または Anthos Service Mesh を使用している場合、デプロイに失敗して次のようなメッセージが表示されることがあります。

   error iptables validation failed; workload is not ready for Istio.
   When using Istio CNI, this can occur if a pod is scheduled before the node is ready.
   

   この設定は、Skaffold 2.0 以降でのみ機能します。

4. Kubernetes マニフェストで、kind: Deployment のリソースに対して、statusCheckDeadlineSeconds に設定した値と同じ値を Deployment.spec.progressDeadlineSeconds に設定します。

次のステップ

• GKE へのデプロイについて確認する

• Cloud Run へのデプロイについて確認する

• GKE Enterprise へのデプロイについて確認する

• デリバリー パイプラインとターゲットの作成方法を学習する

• リリースを昇格する方法を確認する