このページは Cloud Translation API によって翻訳されました。

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

このページでは、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 が必要です。次のいずれかの方法で取得できます。
- 独自に作成する。
  
  この例のように、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 は、次のいずれかのランタイム環境にアプリケーションをデプロイできます。

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

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

通常の継続的インテグレーション（CI）プロセスを実行して、デプロイ可能な 1 つ以上のアーティファクトを作成します。
Cloud Deploy を呼び出してリリースを作成し、デリバリーパイプラインを開始します。

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

コマンドの内容:

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

'$DATE'、'$TIME'、またはその両方を含めることで、動的リリース名を指定できます。たとえば、UTC 午後 3 時 7 分にこのコマンドを呼び出すと、'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 コンソールを使用してデリバリーパイプラインを作成することもできます）。

[デリバリーパイプラインの詳細] ページで、特定のデリバリーパイプラインの [リリースを作成] をクリックします。
[コンテナを選択] フィールドに、デプロイするコンテナイメージのパスを貼り付けるか入力します。このフィールドに事前入力されているデフォルトのコンテナを評価に使用することもできます。

[選択] をクリックして、Artifact Registry からコンテナイメージを選択することもできます。
このリリースの一意の名前を [リリース名] フィールドに指定するか、指定されているデフォルトの名前を使用します。
[ロールアウト名] フィールドにロールアウトの名前を指定するか、指定されているデフォルトの名前を使用します。

この名前は、このリリースの最初のターゲットへのロールアウトに使用されます。以降のターゲットの場合は、[プロモーション] ダイアログまたは gcloud deploy releases promote コマンドでロールアウトに名前を付けることができます。
必要に応じて、[説明] フィールドにこのリリースの説明を入力します。
[デプロイの詳細] で、GKE デプロイまたは Cloud Run サービスの名前を入力するか、指定されたデフォルト名を使用します。

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

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 ヘルスチェックのタイムアウトが有効なタイムアウトになります。
- Kubernetes で Deployment.spec.progressDeadlineSeconds が設定されている場合、Skaffold は独自のヘルスチェックタイムアウトを無視し、Kubernetes の進行状況の期限が有効なタイムアウトになります。ただし、Kubernetes のタイムアウトが明示的に 600（10 分）に設定されている場合、Skaffold はデフォルト（未設定）として無視し、Skaffold のタイムアウトを使用します（設定されている場合）。
- どちらのタイムアウトも設定されていない場合、有効なタイムアウトは Skaffold のデフォルトの 600（10 分）になります。
Deployment 以外に、Kubernetes リソースには、安定性のタイムアウトに影響しないタイムアウトを設定できます。これらのいずれかが存在する場合は、安定性タイムアウトと競合していないことを確認します。

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

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

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

デフォルトは true です。true の場合、Skaffold は、次のステップのタイムアウト値に従って、ヘルスチェックが安定したデプロイを報告するまで待機します。
skaffold.yaml で、statusCheckDeadlineSeconds を待機する秒数に設定します。
```
deploy:
  ...
  statusCheck: true
  statusCheckDeadlineSeconds: 600
  ...
```
デフォルトは 600（10 分）です。Skaffold は、安定したデプロイのためにこの時間だけ待機します。デプロイが安定する前にこの時間を超えると、デプロイは失敗します。
必要に応じて、statusCheckDeadlineSeconds の後に tolerateFailuresUntilDeadline: true を追加できます。

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

たとえば、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.
```
Kubernetes マニフェストで、kind: Deployment のリソースに対して、Deployment.spec.progressDeadlineSeconds を statusCheckDeadlineSeconds に設定した値と同じ値に設定します。

次のステップ

GKE へのデプロイについて確認する
Cloud Run へのデプロイについて確認する
GKE Enterprise へのデプロイについて確認する
デリバリーパイプラインとターゲットの作成方法を学習する
リリースを昇格する方法を確認する