こんにちは
春の訪れを喜びつつ冬の思い出が頭を駆け巡ってしまう技術部の山本です
ECS の UpdateService API がアップデートされました
3/10のアップデート
UpdateService API のドキュメント
抜粋
Posted On: Mar 9, 2022
Amazon Elastic Container Services (Amazon ECS) now supports updating Elastic Load Balancers, Service Registries, Tag Propagation, and ECS Managed Tags for an existing ECS service. The added flexibility makes it easier for customers to update their Amazon ECS service configurations, without having to recreate their services, thus reducing operational overhead and potential service disruption.
Amazon ECS supports updating service parameter configuration programmatically via UpdateService API or through the AWS Management console. Previously, customers could configure the following parameters only at the time of service creation and could not update them thereafter: loadBalancers, propagateTags, enableECSManagedTags, and serviceRegistries. To update these parameters, customers needed to recreate or replace their ECS service with a new version of the service created with these parameters configured. This resulted in potential service disruption and operational overhead for spinning up a new service and switching traffic to it. Today, we are announcing support for these parameters in the Amazon ECS Update Service API, which makes updating ECS services a hassle-free experience. Customers can thus easily perform functions such as enforcing their tagging policies on ECS tasks for cost allocation or resource organization purposes by simply updating the propagateTags parameter on their existing ECS service.
Support for additional parameters in Amazon ECS Update Service API is now available across all AWS Regions using AWS Copilot CLI, AWS CloudFormation, AWS SDK, and AWS CLI. To learn more, please see API reference documentation.
アップデートの内容を意訳する
UpdateService API を使用して
既存のECSサービスの以下設定を更新出来るようになりました
- Elastic Load Balancer(との紐付け設定)
- サービスレジストリ(サービス検出)
- タグ伝播
- ECS で管理されたタグ
上記の設定値は以前は サービスを作成し直さないと変更できませんでした
試してみる
準備 -- サービス作成 (すでにUpdateService API を実行するECSサービスがある場合は不要)
UpdateService API の検証用にFargate のサービスを作成します
すでにUpdateService API を実行するECSサービスがある場合は不要です
タスク定義とロードバランサーは予め準備ください
サービス名は "ServiceAPI-Update" とします
デプロイメントタイプはローリングアップデートを選択します
※AWS Code Deploy と紐付けていると以下の変更が出来ません
- Elastic Load Balancer(との紐付け設定)の変更
- サービスレジストリ(サービス検出) の変更
ECS で管理されたタグを有効にします
またサービスからのタグの伝搬を有効にします
ロードバランサーを紐付けます
ロードバランサー名：ServiceAPI-Update
サービスの検出 (オプション)を有効にします
名前空間名：serviceapiupdate としました
準備 -- 作成したサービスの確認 (すでにUpdateService API を実行するECSサービスがある場合は不要)
タスクが2つ起動しています
タスクにECS で管理されたタグ が付いています
サービスからタスクにタグが伝搬されています
ロードバランサーと紐付いています
サービス検出が有効になっています
Route53 にホストゾーンが出来ています(サービス検出が有効になったため)
AWS Cloud Map に名前空間(とサービス)が出来ています(サービス検出が有効になったため)
準備 -- 変更先となる名前空間の作成 (サービス検出を変更する場合は必須)
AWS Cloud Map のサービス画面から 変更先となる名前空間を作成します
作成した名前空間の画面右下にある「サービスの作成」ボタンを押します
以下のように作成ください
TTL は ECSサービスのAレコードに付ける TTL としてください(60秒は仮置です)
準備 -- 変更先となるロードバランサーの作成 (Elastic Load Balancerとの紐付け設定を変更する場合は必須)
EC2 のサービス画面からロードバランサーとターゲットグループを作成します
詳細は割愛します
注意：
ターゲットグループは「ターゲットの種類」を「IP」にして作成し
ロードバランサーのリスナールールと紐付けておきます
準備 -- AWSマネージメントコンソールからは変更不可なことを確認
AWSマネージメントコンソールのECSサービスの「更新」ボタンから設定変更が出来ないことを確認しておきます
ロードバランサーとの紐付けやサービスの検出は変更ボタン等がありません
ECS で管理されたタグやタグの伝搬については項目がありません
今回のアップデートはAWSマネジメントコンソールは対象外です
UpdateService API を試す
UpdateService API を試すために
aws ecs update-service コマンドを使用します
アップデートされたオプションは以下になります
- [--service-registries
] - [--load-balancers
] - [--propagate-tags
] - [--enable-ecs-managed-tags | --no-enable-ecs-managed-tags]
AWS CLI のバージョンでは、1.22.69以降、2.4.24以降でこの新機能が使えます
https://github.com/aws/aws-cli/blob/ee8c7e8bfa629129e2630e3a89a467b3b7db985c/CHANGELOG.rst
api-change:ecs: Amazon ECS UpdateService API now supports additional parameters: loadBalancers, propagateTags, enableECSManagedTags, and serviceRegistries
https://github.com/aws/aws-cli/blob/ac9a474d131ec376dffbd78fe5f5bbaf01022188/CHANGELOG.rst
- api-change:
ecs: Amazon ECS UpdateService API now supports additional parameters: loadBalancers, propagateTags, enableECSManagedTags, and serviceRegistries
タグ伝搬の変更
タグ伝搬の設定を変更してみます
- 変更前：サービスに付与しているタグをタスクに伝搬
- 変更後：タスク定義に付与しているタグをタスクに伝搬
--propagate-tags TASK_DEFINITION を指定して設定を変更します
※ サービスにするときは SERVICE, タグ伝搬をやめるときは NONE を使います
--force-new-deployment を使って強制的にタスクを置き換えます
aws ecs update-service \ --cluster "FargateクラスターのARN" \ --service "作成したサービス名" \ --propagate-tags TASK_DEFINITION \ --force-new-deployment
コマンドを実行した結果をマネージメントコンソールから見ると変更されていました
参考：
変更前↓
「ECS で管理されたタグ」の変更
- 変更前：ECS で管理されたタグを付与
- 変更後：ECS で管理されたタグを付与しない
--no-enable-ecs-managed-tags パラメータを使用してECS で管理されたタグを付与しないようにします
※付与するようにするときは --enable-ecs-managed-tags を使います
--force-new-deployment を使って強制的にタスクを置き換えます
aws ecs update-service \ --cluster "FargateクラスターのARN" \ --service "作成したサービス名" \ --no-enable-ecs-managed-tags \ --force-new-deployment
コマンドを実行した結果をマネージメントコンソールから見ると変更されていました
参考：
変更前↓
ロードバランサーの変更
ECSサービスを起動するロードバランサーを切り替えます
aws ecs update-service \ --cluster "FargateクラスターのARN" \ --service "作成したサービス名" \ --load-balancers targetGroupArn="ターゲットグループのARN",containerName="タスク定義のコンテナ名",containerPort="コンテナのトラフィックポート"
- パラメータ：targetGroupArn はロードバランサーが ALB または NLB の時に指定します
- パラメータ：loadBalancerName はクラシックロードバランサーが対象の時に指定します
ALB で検証しているので targetGroupArn を指定しています
コマンドを実行した結果をマネジメントコンソールから見ると
変更先のロードバランサーに紐付けているターゲットグループにコンテナが起動していました
動作:
変更先のロードバランサーにコンテナが起動して Healthy になるまでの間
変更前のロードバランサーでコンテナが Healthy になっていました
変更先のロードバランサーにコンテナが起動して Healthy になると
変更前のロードバランサーからコンテナが 切り離されました
サービス検出の変更
サービス検出を変更します
aws ecs update-service \ --cluster "FargateクラスターのARN" \ --service "作成したサービス名" \ --service-registries registryArn='AWS Cloud Map サービスのARN'
※「AWS Cloud Map サービスのARN」は以下の形式となります
arn:aws:servicediscovery:リージョン:アカウント番号:service/サービスID
例：
arn:aws:servicediscovery:ap-northeast-1:123456789012:namespace/ns-xxxxxxxxxxxxxxxx
なお(AWS Cloud Map)サービスIDは以下の画面にあります
※AWS Cloud Map に作成した名前空間の一番下にある サービス名をクリックするとこの画面に行きます
コマンドを実行した結果をマネジメントコンソールから見ると
ECS の サービス画面から サービス検出の項目を見たときに新しいサービスの検出名に変わっていました
またRoute 53 の変更先ホストゾーンに Aレコードが出来ていました
Route 53 の変更元ホストゾーンの Aレコードは消えていました
Cloud Map の名前空間とサービスは自身で削除する必要があります(詳しくは関連記事を参照)
動作:
ロードバランサーに新しいサービス検出名のコンテナが起動して Healthy になるまでの間
ロードバランサーで既存のサービス検出名のコンテナが Healthy になっていました
ロードバランサーに新しいサービス検出名のコンテナが起動して Healthy になると
ロードバランサーから既存のサービス検出名のコンテナが 切り離されました
また--service-registriesに空のリストを渡すことで既存のサービス検出を削除できます
# サービス検出の変更 aws ecs update-service \ --cluster "FargateクラスターのARN" \ --service "作成したサービス名" \ --service-registries
コマンドを実行した結果をマネジメントコンソールから見ると
ECS の サービス画面から サービス検出の項目が無くなっていました
Route 53 の対象ホストゾーンから Aレコードが消えていました
Cloud Map の名前空間とサービスは自身で削除する必要があります(詳しくは関連記事を参照)
アップデートされた ECS の UpdateService API を試して気付いた注意点
試して気付いた注意点がいくつかあったのでまとめます
- AWSマネジメントコンソールからは変更できないので UpdateService API から変更する必要があります
- AWS CLI のバージョンでは、1.22.69以降、2.4.24以降でこの新機能が使えます
- ECSサービスをCode Deploy と紐付けている場合は ロードバランサーとサービス検出の変更ができません
- サービス検出を変更する場合には事前にAWS Cloud Mapで名前空間とサービスの作成が必要です
- ロードバランサーを変更する場合はターゲットグループは「ターゲットの種類」を「IP」にして事前に作成し変更先のロードバランサーのリスナールールと紐付けておきます
- 以下を変更する際には
--force-new-deploymentパラメータを使って強制的にタスクを置き換える必要があります- タグ伝播
- ECS で管理されたタグ
- 以下を変更する際には
--force-new-deploymentパラメータを付けなくてもタスクが自動で置き換わります- Elastic Load Balancer(との紐付け設定)
- サービスレジストリ(サービス検出)
おわり。
関連記事
以上
山本 哲也 (記事一覧)
カスタマーサクセス部のエンジニア。2024 Japan AWS Top Engineers に選んでもらいました。
今年の目標は Advanced Networking – Specialty と Machine Learning - Specialty を取得することです。
山を走るのが趣味です。今年の目標は 100 km と 100 mile を完走することです。 100 km は Gran Trail みなかみで完走しました。残すは OSJ koumi 100 で 100 mile 走ります。実際には 175 km らしいです。「草 100 km / mile」 もたまに企画します。
基本的にのんびりした性格です。座右の銘は「いつか着く」
