アプリケーションをデプロイする

このページでは、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:07 UTC に呼び出すと、'rel-$TIME' は rel-1507 に解決されます。'$DATE' と '$TIME' は単一引用符で囲む必要があり、時刻は、コマンドを呼び出すマシン上の UTC 時刻です。

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

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

このコマンドは、構成を含む 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. [デプロイの詳細] で、GKE デプロイまたは Cloud Run サービスの名前を入力するか、指定されたデフォルト名を使用します。

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

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

   

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

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

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

• 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 ヘルスチェックのタイムアウトが有効なタイムアウトになります。

  • Kubernetes で Deployment.spec.progressDeadlineSeconds が設定されている場合、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 を追加できます。

   この設定では、単一のデプロイが失敗した場合に Skaffold が終了せず、statusCheckDeadlineSeconds が期限切れになるまで失敗を許容するように指示します。この設定は、安定した状態に到達するのにさらに時間（ステータスチェックの期限まで）が必要なリソースがある場合に役立ちます。

   たとえば、Istio または Cloud 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 のリソースについては、Deployment.spec.progressDeadlineSeconds を statusCheckDeadlineSeconds に設定したのと同じ値に設定します。

次のステップ

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

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

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

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

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