翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# コンテナフリートのデプロイの検証とトラブルシューティング
<a name="containers-deployment-validation"></a>

このトピックの*デプロイ*と呼ばれる*フリートデプロイ*は、コンテナフリートのインスタンス上のコンテナを、新しいコンテナグループ定義バージョンなどのフリートの新しい設定を使用するコンテナに置き換えるために Amazon GameLift Serversが使用するプロセスです。実行中のすべてのコンテナを一度に置き換える代わりに、デプロイはまず新しいコンテナがゲームセッションをホストできることを確認し、残りのコンテナを徐々に置き換えて、フリート全体にデプロイする前に不正な変更をキャッチします。コンテナフリートは、次の 3 つの状況でデプロイを開始します。
+ **コンテナグループ定義を使用してフリートを作成する場合。**[CreateContainerFleet](https://docs.aws.amazon.com/gamelift/latest/apireference/API_CreateContainerFleet.html) リクエストにゲームサーバーコンテナグループ定義が含まれている場合、フリートの作成は、フリートの新しいインスタンスにコンテナをインストールするデプロイを開始します。コンテナグループ定義なしでフリートを作成する場合、ゲームサーバーコンテナグループ定義を追加するまで、インスタンスはデプロイされず、フリートはデプロイされません。
+ **フリートのコンテナグループ定義または他のコンテナ設定を更新すると、** は、新しいゲームサーバーコンテナグループ定義バージョンを指定するなど、フリートが実行するコンテナの更新によってデプロイ[UpdateContainerFleet](https://docs.aws.amazon.com/gamelift/latest/apireference/API_UpdateContainerFleet.html)を開始します。これらの設定を変更しない更新では、デプロイは開始されません。デプロイを開始する設定については、「」を参照してください[Amazon GameLift Servers マネージドコンテナフリートを更新する](containers-update-fleet.md)。
+ **アクティブなフリートにロケーションを追加すると、 **はフリートの設定済みコンテナグループ定義を使用して新しいロケーションでデプロイAmazon GameLift Serversを開始します。既存のロケーションは再デプロイされません。別のデプロイの進行中にロケーションを追加することはできません。

デプロイの詳細を表示するには、 [FleetDeployment](https://docs.aws.amazon.com/gamelift/latest/apireference/API_FleetDeployment.html) オブジェクトを返[DescribeFleetDeployment](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DescribeFleetDeployment.html)す を呼び出します。これには、デプロイ ID、ステータス、設定、デプロイされるコンテナグループ定義バージョン、ロールバックバージョンが含まれます。フリートの `DeploymentDetails.LatestDeploymentId`プロパティは、最新のデプロイを識別します。

**注記**  
デプロイはマネージドコンテナフリートにのみ適用されます。

## デプロイを設定する
<a name="containers-deployment-validation-config"></a>

デプロイの [DeploymentConfiguration](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeploymentConfiguration.html)は、デプロイがフリート全体でどのように進行し、失敗した場合にどうなるかを制御する一連のルールです。各設定の値とデフォルトの詳細については、 *Amazon GameLift Servers API リファレンス*の[DeploymentConfiguration](https://docs.aws.amazon.com/gamelift/latest/apireference/API_DeploymentConfiguration.html)「」を参照してください。

コンソールでフリートを呼び出し`UpdateContainerFleet`たり編集したりするときに、デプロイ設定を設定します。 `CreateContainerFleet`はデプロイ設定を受け入れないため、フリートの最初のデプロイでは常にデフォルト値が使用されます。

## がデプロイAmazon GameLift Serversを検証する方法
<a name="containers-deployment-validation-howitworks"></a>

デプロイが開始されると、 はAmazon GameLift Serversまずフリートの各ロケーションでゲームサーバーコンテナグループを検証します。フリートの既存の容量のごく一部で新しいコンテナを実行し、それらが正常であることを確認します。新しいゲームサーバーコンテナグループは、ゲームサーバーコンテナが `ProcessReady()`を呼び出してゲームセッションをホストする準備ができていることを報告すると、*正常*です。

この初期検証では、ゲームサーバーコンテナグループをチェックします。フリートがインスタンスごとのコンテナグループ定義も使用している場合、 はゲームサーバーグループを更新した後にそれらのグループAmazon GameLift Serversを更新します。 は、デプロイが完了する前にインスタンスごとのグループを個別にAmazon GameLift Serversチェックします。ゲームサーバーの`ProcessReady()`チェックは使用しません。

が待機Amazon GameLift Serversを停止する前に新しいゲームサーバーコンテナグループが正常にならない場合、検証は失敗します。一般的な理由とその調査方法については、「」を参照してください[障害のあるデプロイのデバッグ](#containers-deployment-validation-debug)。

検証が失敗した場合、 はデプロイの Amazon GameLift Serversを適用`ImpairmentStrategy`し、デプロイステータスを `IMPAIRED` ( の場合`MAINTAIN`) または `ROLLBACK_IN_PROGRESS` ( の場合) に設定します`ROLLBACK`。ある場所で検証が成功した後でのみ、 はそこでゲームサーバーを実行している残りのコンテナをAmazon GameLift Servers置き換えます。

### 検証にかかる時間
<a name="containers-deployment-validation-timeouts"></a>

が検証Amazon GameLift Serversに使用する容量が保護されたゲームセッションをホストしている場合、検証には時間がかかります。フリートの は、新しいゲームセッションのデフォルトの保護`NewGameSessionProtectionPolicy`を決定します。有効な値は、`NoProtection` および `FullProtection` です。デプロイの は、デプロイがその保護に従うかどうか`ProtectionStrategy`を決定します。有効な値は、`WITH_PROTECTION` および `IGNORE_PROTECTION` です。

フリートが `NewGameSessionProtectionPolicy`に設定`FullProtection`され、デプロイが に`ProtectionStrategy`設定されている場合`WITH_PROTECTION`、 は保護されたゲームセッションの終了に長い検証タイムアウトAmazon GameLift Serversを許可します。他の組み合わせでは、短いタイムアウトが使用されます。

**重要**  
新しいコンテナが正常になることがなく、フリートが`WITH_PROTECTION`デプロイ`FullProtection`で を使用する場合、障害を報告する前に保護されたゲームセッションが終了するまでデプロイ`IN_PROGRESS`のステータスを維持できます。より高速なシグナルを得るには、テスト`IGNORE_PROTECTION`中に を使用して新しいコンテナイメージをデプロイするか、自分でデプロイをキャンセルします。デプロイをキャンセルする手順については、「」を参照してください[新しいデプロイを開始してデプロイをキャンセルする](#containers-deployment-validation-cancel)。  
`NewGameSessionProtectionPolicy` が であるフリート[UpdateGameSession](https://docs.aws.amazon.com/gamelift/latest/apireference/API_UpdateGameSession.html)で個々のゲームセッションを で保護する場合`NoProtection`、 Amazon GameLift Serversはそれらの待機時間を延長しません。これらのゲームセッションが時間内に終了しない場合、新しい設定が機能していても検証が失敗する可能性があります。

## デプロイステータスを追跡する
<a name="containers-deployment-validation-status"></a>

[Amazon GameLift Servers コンソール](https://console.aws.amazon.com/gamelift/)でデプロイを追跡するには、フリートを開き、**デプロイタブ**を選択します。 AWS Command Line Interface (AWS CLI) で追跡するには、 [list-fleet-deployments](https://docs.aws.amazon.com/cli/latest/reference/gamelift/list-fleet-deployments.html)を使用してデプロイ ID を検索し、次に [describe-fleet-deployment](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-deployment.html) を使用して単一のデプロイの詳細を確認します。

デプロイステータス値とそれぞれの意味については、 *Amazon GameLift Servers API リファレンス*[DeploymentStatus](https://docs.aws.amazon.com/gamelift/latest/apireference/API_FleetDeployment.html#gameliftservers-Type-FleetDeployment-DeploymentStatus)の「」を参照してください。

## 障害のあるデプロイのデバッグ
<a name="containers-deployment-validation-debug"></a>

デプロイの障害は、検証中に新しいコンテナが正常ではなかったことを意味します。多くの場合、コンテナが終了または起動に失敗したために、待機Amazon GameLift Serversを停止`ProcessReady()`する前に というゲームサーバーコンテナがありません。原因は通常、コンテナイメージまたはゲームサーバーにあります。コンテナが終了した理由、またはゲームサーバーが準備状況を報告しなかった理由について説明します。

### フリートイベントログを確認する
<a name="containers-deployment-validation-debug-events"></a>

フリートイベントログには、デプロイ中にAmazon GameLift Servers観察された内容が記録されます。コンソールのフリートの**イベント**タブで表示するか、 を呼び出します[describe-fleet-events](https://docs.aws.amazon.com/cli/latest/reference/gamelift/describe-fleet-events.html)。次のイベントコードは、失敗したデプロイに関連しています。
+ `GAME_SERVER_CONTAINER_GROUP_CRASHED` および `PER_INSTANCE_CONTAINER_GROUP_CRASHED` - コンテナグループが終了したか、起動に失敗しました。Amazon GameLift Servers にコンテナの終了コードがある場合、イベントメッセージにコードが含まれます。
+ `GAME_SERVER_CONTAINER_GROUP_REPLACED_UNHEALTHY` および `INSTANCE_REPLACED_UNHEALTHY` – は、コンテナグループまたは正常でないインスタンスをAmazon GameLift Servers置き換えました。これらは、デプロイが失敗している間にフリートのロケーション間で繰り返される可能性があります。
+ `SERVER_PROCESS_MISCONFIGURED_CONTAINER_PORT` – ゲームサーバーコンテナは、コンテナグループ定義で宣言されたポートと一致しないポートを使用しました。
+ `LOCATION_STATE_UPDATING` および `LOCATION_STATE_ACTIVE` - これらは、各場所のデプロイを括弧で囲むため、他のイベントを、それらを生成したデプロイと並べるのに役立ちます。
+ `COMPUTE_LOG_UPLOAD_FAILED` – コンテナのログ収集が機能しなくなったため、そのコンテナからのログが不完全または欠落している可能性があります。

### コンテナログの読み取り
<a name="containers-deployment-validation-debug-logs"></a>

が各コンテナの標準出力Amazon GameLift Serversを送信するコンテナフリートの`LogConfiguration`セット: `CLOUDWATCH` (デフォルト）、`S3`、または `NONE`。デプロイが失敗したときにコンテナ出力を使用`S3`できるように、 `CLOUDWATCH`または に設定します。たとえば、コンテナのエントリポイントがイメージにないファイルを参照しているため、ゲームサーバーの実行を開始する前にコンテナが失敗した場合、この出力は失敗の唯一のレコードです。コンテナのログ記録の詳細については、「」を参照してください[ログ記録の違い: マネージド EC2 フリートとコンテナフリート](logging-server-messages-ec2-vs-containers.md)。

### 障害のあるコンテナに接続する
<a name="containers-deployment-validation-debug-connect"></a>

`MAINTAIN` 障害戦略を使用してデプロイした場合は、 Amazon GameLift Servers を保持して直接検査するコンテナに接続できます。これを使用して、ファイルのアクセス許可を確認し、イメージに実際に含まれているファイルを確認し、手動でゲームサーバー実行可能ファイルを実行して、レポートの内容を確認します。コンテナに接続する手順については、「」を参照してください[コンテナに接続する](containers-remote-access.md)。

### デプロイに関する一般的な問題
<a name="containers-deployment-validation-debug-causes"></a>

以下の症状は、デプロイの失敗や遅延、および通常の原因でよく見られます。

**コンテナはすぐに開始および終了します。**  
コンテナのエントリポイントを実行できない場合は、以下を確認してください。  
+ 起動スクリプトとゲームサーバーの実行可能ファイルがイメージで実行可能とマークされていることを確認します。
+ 実行可能ファイルの CPU アーキテクチャがフリートのインスタンスタイプと一致することを確認します。
+ イメージに、実行ファイルに必要なインタープリタと共有ライブラリが含まれていることを確認します。
Amazon GameLift Servers が実行できるイメージの構築については、「」を参照してください[Amazon GameLift Servers 用のコンテナイメージを構築する](containers-prepare-images.md)。

**デプロイは遅くなりますが、何も失敗しません。**  
`WITH_PROTECTION` デプロイは、検証中とフリートのコンテナを置き換えるときに、保護されたゲームセッションが終了するのを待ちます。長いデプロイを失敗として扱う前に、フリートのアクティブなゲームセッションを確認してください。検証の待機時間の詳細については、「」を参照してください[検証にかかる時間](#containers-deployment-validation-timeouts)。

## 新しいデプロイを開始してデプロイをキャンセルする
<a name="containers-deployment-validation-cancel"></a>

デプロイをキャンセルしてフリートを以前の設定に戻すには、コンソールでフリートを呼び出す`UpdateContainerFleet`か編集して、変更を元に戻す新しいデプロイを開始します。最も一般的なケースは、新しいコンテナグループ定義バージョンです。この手順は元に戻します。 は、進行中のデプロイで最後にアクティブになったときにフリートが使用したバージョンを `RollbackGameServerBinaryArn`および としてAmazon GameLift Servers記録するため`RollbackPerInstanceBinaryArn`、どのバージョンに戻るか調べる必要はありません。デプロイによってログ設定や接続ポート範囲などの他の設定も変更された場合は、それらを同じ`UpdateContainerFleet`リクエストに戻します。

開始する前に、 AWS CLI アカウントの を設定し、フリートのホーム を特定します AWS リージョン。この手順では、復元するために、進行中のデプロイと以前のコンテナグループ定義バージョンが必要です。`list-fleet-deployments` を使用してデプロイ ID を検索します。手順については、「[デプロイステータスを追跡する](#containers-deployment-validation-status)」を参照してください。

コマンドで、{{fleet-id}} をフリート ID に、{{deployment-id}} を進行中のデプロイ ID に、{{fleet-home-region}} をフリートのホームに置き換えます AWS リージョン。

**進行中のデプロイを以前のコンテナバージョンに置き換えるには (AWS CLI)**

1. 返すバージョンを取得するには、次の AWS CLI コマンドを使用します。

   ```
   aws gamelift describe-fleet-deployment \
       --fleet-id {{fleet-id}} \
       --deployment-id {{deployment-id}} \
       --region {{fleet-home-region}}
   ```

   レスポンスで、 は、フリートが最後にアクティブになったときに使用したゲームサーバーコンテナグループ定義バージョン`RollbackGameServerBinaryArn`を保持します。フリートにインスタンスごとのコンテナグループがある場合、 はそのバージョン`RollbackPerInstanceBinaryArn`を保持します。

1. 次の AWS CLI コマンドを使用して、そのバージョンで新しいデプロイを開始します。{{rollback-game-server-cgd-arn}} をステップ 1 `RollbackGameServerBinaryArn`の値に置き換えます。フリートにインスタンスごとのコンテナグループがある場合は、 `RollbackPerInstanceBinaryArn` 値`--per-instance-container-group-definition-name`も渡します。

   ```
   aws gamelift update-container-fleet \
       --fleet-id {{fleet-id}} \
       --game-server-container-group-definition-name {{rollback-game-server-cgd-arn}} \
       --region {{fleet-home-region}}
   ```

1. 以前のデプロイが`CANCELLED`ステータスを報告し、新しいデプロイが終了した`COMPLETE`ときにレポートすることを確認します。

**注記**  
この方法でデプロイをキャンセルしても、すぐに停止することはありません。新しいデプロイは、検証を含む他のデプロイと同じステップを実行するため、フリートの解決に時間がかかります。フリートが正常に実行されたバージョン。通常、 はすばやく検証します。

## 関連トピック
<a name="containers-deployment-validation-related"></a>

詳細については、以下のトピックを参照してください。
+ [Amazon GameLift Servers マネージドコンテナフリートを更新する](containers-update-fleet.md)
+ [コンテナに接続する](containers-remote-access.md)
+ [Amazon GameLift Servers 用のコンテナイメージを構築する](containers-prepare-images.md)
+ [ログ記録の違い: マネージド EC2 フリートとコンテナフリート](logging-server-messages-ec2-vs-containers.md)
+ [Amazon CloudWatch で Amazon GameLift Servers を監視する](monitoring-cloudwatch.md)
+ [Amazon GameLift Servers におけるコンテナの仕組み](containers-howitworks.md)