やること
- ECSリソース操作に関してはAWSコンソール上で行う
- ECSクラスタを作成
- ECSタスクを作成 (自前ビルドしたイメージを起動)
- ECSサービスを作成
- 起動したコンテナのログを確認 CloudWatchLogs
- 終了したコンテナの再起動確認
- タスクのイメージを更新
ECSの概念についてはこちらの記事で Amazon EC2 Container Service(ECS)の概念整理
環境
- AWSコンソールにログインできる (今回使うリソースの作成権限があるユーザで)
- ECRに標準出力するイメージを持つリポジトリがある ここで作ったechoalpine使う
作業
ECSクラスタを作成する
何はともあれクラスタを作ってみる
コンソールの検索バーからECSと検索してECS画面に遷移
クラスタを選択して、クラスタの作成
クラスタのテンプレート選択
- ネットワークのみ (AWS Fargeteを使用)を選択して次のステップ
クラスタの設定
CIDRブロックは余ってるのを使う
- クラスタ名:
ecs-cluster-echoalpine - VPC作成:
チェックする - CIDRブロック:
11.0.0.0/16 - サブネット1:
11.0.0.0/24 - サブネット2:
11.0.1.0/24
作成
ECSタスクを作成
AWSコンソールからタスク定義のページへ遷移 -> 新しいタスク定義の作成
起動タイプの互換性の選択
- Fargate
タスクとコンテナの定義の設定
- タスク名:
echoalpine-task - タスクロール:
ecsTaskExecutionRole ネットワークモード:
awsvpcタスクメモリ:
2GBタスクCPU:
1 vCPU
コンテナの追加から
- コンテナ名: echoalpine
- イメージ: AWSアカウントID.dkr.ecr.イメージのあるECRリージョン.amazonaws.com/echoalpine:1.0.0
- メモリ制限: 128
- 環境変数追加: MY_ENV_VAL VALUE "This is my env val !!"
指定箇所以外はデフォルトの指定
作成
タスクを作成するとCloudWatchロググループも作成される
今回のロググループ名は/ecs/echoalpine-taskだった
サービスの作成
クラスタ一覧から作成したクラスタを選択して遷移するとサービスというタブが開いていると思うのでサービスの新規作成を行う
作成するサービスで先ほど作成したタスクを利用する
※記述していない箇所はデフォルトの設定
サービスの設定
起動タイプ: Fargate
タスク定義(Family):
echoalpine-taskタスク定義(Revision):
1(latest)プラットフォームのバージョン:
LATESTクラスタ:
ecs-cluster-echoalpineサービス名:
echoalpine-serviceタスクの数:
1
ネットワーク構成
- クラスタVPC: クラスタ作成時に作成したVPC ここではCIRDブロック11.0.0.0のもの
- サブネット: クラスタ作成時に作成した2つのサブネットを指定
サービスを作成するとAWS Cloud Mapにリソースが作成されるのでサービス削除時にそれも削除するようにする
Auto Scalingオプション
- Service Auto Scaling: サービスの必要数を直接変更しない
入力項目が確認できたらサービスの作成
起動したコンテナのログを確認 CloudWatchLogs
サービスを作成したことで指定タスクのコンテナが立ち上がり、動作している状態になっていると思うのでCloudWatchLogsでコンテナで動かしているシェルの標準出力を確認してみる
CloudWatchページでタスク作成時に生成された/ecs/echoalpine-taskを選択しログを確認する
起動させているコンテナは10秒毎にmy echoalpine container!! 1.0.0と出力し、10回出力するとkiss of death...と言い残し一生を終えるドラマチックなセミみたいなコンテナ
恐らくCloudWatchでその出力が確認できる (タスク定義でイメージをechoalpineにしていれば)
タスク定義で環境変数MY_ENV_VALを指定したので、このシェルが
echo my echoalpine container!! 1.0.1 $MY_ENV_VAL
となれば出力はmy echoalpine container!! 1.0.1 This is my env val !!となる
終了したコンテナの再起動確認
セミコンテナは10回echoすると死んでしまうので、ECSのサービスがよしなに復活させてくれているか確認する
特に行う操作は無く、コンテナが再起動されると新しいログストリームが作成されるのでその中で再び同じ動作をしているか確認する
DockerイメージのCMDで指定しているプロセスが終わったらしっかりと再起動されているので嬉しくなった
動作させる新しいDockerイメージが用意できたのでタスクの新しいリビジョンを作成し、サービスで新しいリビジョンのタスクを使うように変更
(web)サービス等を運用していると動作可能な新しいイメージが出来ると思うので、それの適用を行う
新しいイメージの指定はタスク定義のechoalpine-taskの中に入って最新のリビジョンを選択してから新しいリビジョンの作成を行う
変更する部分はコンテナの中身
登録されているechoalpineを選択しイメージを新しいバージョンにする
# before
xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/echoalpine:1.0.0
# after
xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/echoalpine:1.0.1
1.0.0を1.0.1にした
コードは書かないが、echo.shのecho "my echoalpine container!! 1.0.0"をecho "my echoalpine container!! 1.0.1 $MY_ENV_VAL"に変更した
echoalpineの記事
イメージのみを更新したら作成
そうすると1つだったリビジョンが2つに増えている
ここまでがタスクの更新だが、これだけでは動いているコンテナの動作は変わらない
1.0.1を動かすためにはサービスの更新を行う
クラスタecs-cluster-echoalpine -> サービスechoalpine-serviceを選択
右上の更新ボタンを押すと、サービスの作成で行った画面に登録した情報が入っている状態になっている
タスク定義(Family)はechoalpine-taskのまま
タスク定義(Revision)を2(latest)に設定
それ以外は何も変更せずにサービスの更新を行う
少し待っていると新しいCloudWatchのログストリームが生成され
my echoalpine container!! 1.0.1 This is my env val !!
と出力されるようになっている
動作させているコンテナを停止させる
サービスのタスクの数を0にして更新するとコンテナの動作は止まる
まとめ
確かめたかったことは自前ビルドしたDockerイメージを使ってみること、プロセスが終了したときの再起動処理、標準出力へのログ確認、イメージ新バージョンになった時の更新、コンテナに環境変数渡せるか
この記事ではやってないけどALBから指定ポートへのルーティングも出来ていたのでとりあえず良さそう
懺悔
AWSコンソールを操作しているのに画像が1枚もないのは甘え