ECS
EC2インスタンスをホストとしてDockerコンテナを容易にクラスタリング・サービス化する。タスクランナーとしても使える。
Getting Started
- ドキュメント: http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/Welcome.html
- 最新AMI: http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
仕様
- タスクのライフサイクル - Amazon EC2 Container Service
- Amazon ECS イベント - Amazon Elastic Container Service
- コンテナインスタンスやタスクの状態変更イベント
タスク定義
タスク定義パラメーター
以下のようなものがある:
volumesFrom
…docker run
の--volumes-from
オプションに相当。
サービス
- サービスロードバランシング - Amazon Elastic Container Service
- 1つのサービスに紐付けられるLBは1つだけ。複数ポートをサーブしたい場合は、サービスを分ける必要がある。
- Amazon ECS タスク配置戦略 - Amazon Elastic Container Service
- タスクをどう配置するか。AZ間で分散する、利用インスタンス数を最小にするなど選べる。
- ECSサービスでは作成時に選択する。
Tips:
- ECSをタスクランナーとして使うときも、サービスを作っておくとタスク定義をテンプレート的に使い回せるので便利
- 「Run more like this」で環境変数など上書きしたタスクを実行することが可能
Features
動的ポートを使ってALBからロードバランス
docker run
の -P
オプションに相当するポートマッピング方式で、ホスト側の任意のエフェメラルポートにコンテナのポートがマッピングされる。
これによってALBからロードバランスすることができる。
これを使うとECSホストとなるインスタンスが1台しかいなくても、コンテナをローリング更新できる。
固定ポート方式だと、ホスト側のポートが被るので新しいコンテナをデプロイできない。
参考:
- Amazon ECSのELB構成パターンまとめ(ALB対応) | Developers.IO
- Dockerコンテナの作成からECSの動的ポート+ALBでロードバランスするまで【cloudpack大阪ブログ】 - Qiita
Service Auto Scaling
コンテナの数を機械的にスケールさせたい場合、クラスタインスタンスのAuto Scalingとは別にService Auto Scalingを設定する必要がある。
参考:
- サービスの Auto Scaling - Amazon Elastic Container Service
- Amazon ECSでAuto Scaling | Amazon Web Services ブログ
- ECSのオートスケール戦略 - Carpe Diem
CloudWatch Logs連携
Logging Driverとしてawslogsを使うことでCloudWatch Logsにログ収集できる。
CloudWatch Event
以下のようなイベントをCloudWatch Eventでトリガにすることができる:
- コンテナの状態変化
- タスクの状態変化
- :
ノウハウ
タスクの異常終了を監視する
上述のCloudWatch EventでLambdaを呼び出し、Lambda側で lastStatus
や exitCode
を判別すれば良い。
TODO: コードサンプルを書く。
参考:
デバッグ出力の有効化
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/docker-debug-mode.html
$ sudo vi /etc/sysconfig/docker
## OPTIONSに下のように"-D"を足す。
OPTIONS="-D --default-ulimit nofile=1024:4096"
$ sudo service docker restart
$ sudo start ecs
EBS Dockerボリュームの変更
デフォルト22Gなのだが、ワークロードが高い場合、Burst Balanceを使い切る可能性がある。
ボリュームを拡張しておくことでキャパシティを上げることができるが、変えたい場合はEC2作成時やLaunch Configurationで変える必要がある。
デバイス名 /dev/xvdcz
のボリュームを変えれば良い。
Terraformの場合、 aws_launch_configuration resourceの ebs_block_device
ブロックで設定する。
resource "aws_launch_configuration" "my_ecs_launch_config" {
:
ebs_block_device {
device_name = "/dev/xvdcz"
volume_type = "gp2"
volume_size = 50
}
}
参考:
ECSログコレクター
http://docs.aws.amazon.com/ja_jp/AmazonECS/latest/developerguide/ecs-logs-collector.html
このスクリプトでインスタンスのログを集めて、診断に役立つようにAWSサポートと共有できるそうだ。
タスク・イメージのクリーンアップ設定
参考:
How-to
IAM設定
Terraformとかで構築してると、IAM設定がよくわからなくて気が狂いそうになる。
1回動くと満足するが、次やるときにはやり方を忘れている。
- ECSサービスに設定するIAMロール
- Amazon ECS サービススケジューラ IAM ロール - Amazon Elastic Container Service
- 2019年1月現在は、指定しなくても勝手にAWSがマネージドなIAMロールを設定してくれるはず。
- ECSタスク実行IAMロール
- Amazon ECS タスク実行 IAM ロール - Amazon Elastic Container Service
- AssumeRoleで
Service: ecs-tasks.amazonaws.com
を許可する - IAMポリシーはマネージドなのがあるので、それをロールにアタッチすればよい
クラスタ更新
やり方:
- Terraform
- ecs-deploy
- AWS CLIとjqを使ってシェルスクリプトで実装された便利ツール
参考:
プライベートレジストリを使う
See プライベートレジストリの認証 - Amazon Elastic Container Service
インスタンスをクラスタから外す
一時的に外したい場合。
- AutoScaling Groupからデタッチ
- ECSクラスタからインスタンスを外す
- Drainingに変えれば良いと思う
インスタンスを減らす
↑の操作は安全だが、台数を減らすのは難しい。
というのはAutoScaling Groupでインスタンスの設定数を減らすことになるのだが、このときどのインスタンスが落とされるかを制御できないからだ。
このときはAutoScaling Groupのライフサイクルフックを設定するのが王道のようだ。
または、落とされたくないインスタンスを保護するという手もある。
参考:
- Amazon ECS におけるコンテナ インスタンス ドレイニングの自動化方法 | Amazon Web Services ブログ
- Amazon EC2 Auto Scaling ライフサイクルフック - Amazon EC2 Auto Scaling (日本語)
コンテナ間でのデータボリュームの共有
参考: