# Express Mode 以外のリソースの更新
<a name="express-service-advanced-customization"></a>

Express Mode は、ユーザーに代わって AWS リソースを自動的にプロビジョニングし管理することでデプロイを簡素化しますが、責任モデルを理解することが大切です。Express Mode は Amazon ECS サービス、ロードバランサー、自動スケーリングポリシーなどのリソースを作成し設定しますが、すべてのリソースは AWS アカウントに残り、アクセスして直接管理できます。これらのリソースは、AWS コンソール、AWS CLI、または API を使用して Express Mode の外部で変更できますが、Express Mode のサービスを管理する機能に影響する可能性があります。このセクションでは、Express Mode が管理するリソース、Express Mode の外部で安全に変更を行う方法、および変更による影響について説明します。

## 責任共有モデルを理解する
<a name="express-service-shared-responsibility"></a>

Express Mode の責任境界は、API の使用によって定義されます。Express Mode API は、複数の AWS サービス間で調整された更新により、ユーザーに代わってリソースを管理します。標準 AWS サービス API を使用すると、個々のリソースを直接制御できます。これにより、Express Mode が設定用に提供するパラメータのセットを超えて、すべてのリソースのすべてのパラメータを制御できます。どちらの API セットも、アカウント内の同じ基盤となるインフラストラクチャで動作し、どちらもリクエストしたオペレーションを実行します。AWS には、リクエストしたオペレーションを実行する責任があります。Express Mode は、直接 API を使用したリソースの変更が Express Mode の設定と競合するかどうかを検証せず、サービス機能を中断する可能性のある変更を妨げることもありません。つまり、変更を加えることができ、その変更は保持されます。Express Mode の更新の一部としてリクエストされない限り、Express Mode は変更を上書きしません。ユーザーには、直接 API を使用した変更が Express Mode の設定にどのように影響するかを理解し、結果として生じる競合やサービスの問題を解決する責任があります。

Express Mode が設定するデフォルトと、それがオーケストレーションするリソースの詳細については、「[Amazon ECS Express Mode サービスによって作成されたリソース](express-service-work.md)」を参照してください。

## Express Mode サービスで Amazon ECS 機能を利用する前に、何かする必要はありますか?
<a name="express-service-migration"></a>

いいえ。Express Mode にはグラデュエーションパスやブレークグラスはありません。Amazon ECS 機能セットはすべて、Express Mode サービスで常に使用できます。サービスでこれ以上 Express Mode の更新が発生しないようにするには、いくつかオプションがあります。リソースのマネージドタグを削除することで、Amazon ECS は Express Mode サービスとしてそれを識別して操作できなくなります。あるいは、IAM を使用して、ユーザーのアクセス許可を Express Mode API に制限することもできます。

## Express Mode 外での更新の例
<a name="express-service-customization-examples"></a>

### Express Mode サービスへのサイドカーの追加
<a name="express-service-add-sidecar"></a>

任意のサイドカーコンテナをサービスに追加できます。この例は、Fluent Bit ログ記録サイドカーを追加する方法を示しています。

サイドカーコンテナを使用してタスク定義を定義し、`taskDefinitionArn` パラメータを使用して Express Mode サービスに提供できます。Express Mode では、設定したサイドカーコンテナを含め、タスク定義をそのまま使用します。詳細については、「[独自のタスク定義を使用して Express Mode サービスを作成](express-service-getting-started.md#express-service-create-byotd)」を参照してください。

または、次の手順で説明するように、Express Mode が作成したタスク定義を直接編集してサイドカーを追加することもできます。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. Express Mode サービスがあるクラスターを選択し、**[サービス]** パネルで Express Mode サービスを選択します。

1. **[リソース]** タブに移動し、タスク定義を選択します。

1. **[JSON]** タブを選択し、**[新しいリビジョンを作成]** というラベルが付いた上部ボタンの下矢印を選択します。ここには、**JSON で新しいリビジョンを作成する**というアクションがあります。

1. プライマリコンテナ定義の前後にサイドカーコンテナを追加します。詳細については、「[Amazon ECS タスク定義の例: FireLens にログをルーティングする](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/firelens-taskdef.html)」を参照してください。

1. この例のように、ログ記録サイドカーがある場合は、プライマリコンテナで `logDriver` を変更します。

   ```
   "logConfiguration": {
       "logDriver": "awsfirelens"
   }
   ```

1. Express Mode サービスのデフォルト設定を前提として、プライマリコンテナ memoryReservation を 1998 に設定し、Fluent Bit コンテナ memoryReservation を 50 に設定します。これにより、2 つのコンテナの合計メモリ予約数は Fargate タスクで実行している量 (デフォルトの Express Mode サービスの場合は 2048) を超えません。

1. 新しいリビジョンを作成します。

1. **[デプロイ]** ドロップダウンをクリックし、**[サービスの更新]** を選択します。

1. 更新する**クラスター**と**サービス**を選択し、**[新しいデプロイを適用する]** を選択します。先ほど作成したタスク定義のリビジョンが自動で選択されるはずです。**[更新]** を選択します。

1. デプロイが行われていることを確認します。このサービスのタスクに 2 つのコンテナが追加されました。Express Mode コンソールまたは API による追加の更新は、直接競合しない限り、タスク定義への変更を上書きしません。この場合だと、例えば、Express Mode に新しいロググループとログストリーム名を指定した場合、logDriver は `awslogs` に更新されます。

### サービスへのカスタムドメインの追加
<a name="express-service-add-custom-domain"></a>

**前提条件:** このガイドでは、ドメインが ACM 証明書を使用して Route 53 によって管理されるホストゾーンであることを前提としています。ドメインが他の場所でホストされている場合は、Application Load Balancer DNS レコードを指す CNAME が必要です。

1. コンソール ([https://console.aws.amazon.com/ecs/v2](https://console.aws.amazon.com/ecs/v2)) を開きます。

1. ナビゲーションペインで **[Clusters]** (クラスター) を選択してください。

1. Express Mode サービスがあるクラスターを選択し、**[サービス]** パネルで Express Mode サービスを選択します。

1. **[リソース]** タブに移動し、リスナールールを選択します。

1. **[アクション]**、**[ルールを編集]** の順に選択します。

1. 現在のホストヘッダー値 (アプリケーション URL) をコピーし、ルールを**削除**します。これは各タイプのいずれか 1 つしか持てないためです。

1. **ホストヘッダー**タイプの条件を追加し、アプリケーション URL をホストヘッダー条件値として貼り付けます。

1. **[OR 条件値の追加]** をクリックします。

1. ここにカスタムドメインを入力します。

1. **[次へ]**、**[変更を保存]** の順にクリックします。

1. 次に、Application Load Balancer リスナーの **[証明書]** タブを選択します。

1. **[証明書の追加]** をクリックします。ここでは、証明書をリスナーにインポートできます。

1. Route 53 ホストゾーンで、**[レコードの作成]** をクリックして、サービスへのルーティングレコードを作成します。

1. シンプルルーティングレコードを選択します。

1. レコード名を追加します。

1. レコードタイプを選択します。

1. トラフィックを **Application Load Balancer と Classic Load Balancer へのエイリアス**にルーティングします。

1. リージョンを選択します。

1. Express Mode サービスが使用するロードバランサーを選択します。

数分かけて伝播した後、サービスはカスタムドメインでトラフィックを受信し始めます。Application Load Balancer に多くの証明書を追加する場合、または Application Load Balancer からの多くの Express Mode サービスを処理する場合は、Application Load Balancer の証明書のサービス制限を引き上げることを検討してください。