はじめに
以前、ECSの概念まわりをざっくりと記事（ AWSのECS関連の概念を簡単に整理）にしましたが、
実際にECSを使用する機会があったので、
実際に立て方や設定方法などを忘れないうちに記載しておきます。
今回やったことの大枠の流れ
Codecommit上でソース管理し、ECRでイメージを管理しているので、
大枠の流れとしては以下になります。
・Codecommitからイメージの作成
・ECRへPush
・イメージをタスク定義に適用
・サービスにタスク定義を適用
なお、
・Codecommitからイメージの作成
・ECRへPush
についてはタイトルとずれるのでまた後日まとめることにします。
今回はECRにある最新のイメージをタスク、サービスに適用するにはどうするかを
中心にまとめます。
そのため、ECRには最新のイメージがあがっている想定で見てください。
イメージをタスク定義に適用
まず、最新のイメージをコンテナクラスタに適用するためには、
タスク定義を変更します。
変更にあたってはイメージIDが必要になるので、
ECRなどからメモっておいてください。
123456.dkr.ecr.ap-north-east-1.amazonaws.com/test/test:タグ
的なやつです。
なお、すでにあるタスク定義を流用してイメージのみ更新する場合は、
タスク定義一覧から流用元のタスク定義をクリックの上、「新しいリビジョンの作成」を選択します。
今回自分が実施したのは流用のパターンですので、
こちらの手順に沿っていきます。
リビジョン（revision）とは元々「修正」「改訂」といった意味がある。
とWeblio辞書が言っているので既存の流用ではリビジョンを更新するんですね。
「新しいリビジョンの作成」をクリックすると、
流用元の設定が適用された設定が画面が表示されます。
今回は新しいイメージをあてたいだけなので、下にスクロールしていくと、
コンテナの定義の欄があります。
ここで、このタスク定義に適用するイメージを選択することが可能です。
実際に見てもちょっとわかりにくいのですが、
黒塗りにしているコンテナ名のところがリンクになっているので、
クリックするとさらに画面が表示されます。
クリック後の画面にて、先程メモしておいたイメージIDを貼り付けます。
貼り付けたら更新をクリック。
これでタスクのリビジョンの作成が完了しました。
このリビジョンを指定してサービスを適用、インスタンスを立ち上げれば、
このタスクが実行されるので、
コンテナイメージも更新されているというわけです。
サービスにタスク定義を適用
次にサービスに先程のリビジョンのを適用して、
新規でたてるインスタンスのコンテナイメージを更新します。
更新したいクラスターを選択し、
サービス一覧を確認します。
変更したいサービスをクリックし、「更新」をクリックします。
すると以下のような画面が表示されます。（黒塗りばかりで申し訳ないですが）
タスク定義の欄にリビジョンとありますが、
ここから先程変更したリビジョンへプルダウンで変更することが可能です。
なお、最新のリビジョンには(latest)の文言がついています。
※リビジョンの数値はカウントアップで作成の度に増えていきます。
ここを最新のリビジョンに変更のうえ、次のステップへ進んでいき「サービスの更新」を押せば、
リビジョンの変更の完了です。
これで新規でたてたインスタンスには新しいタスクイメージが適用されることになります。
なお、「新規でたてたインスタンスには新しいタスクイメージが適用されることになります」なので、
既存のインスタンスではまだ古いタスクイメージが適用されいます。
そのため、先程のサービスの設定にある「新しいデプロイの強制」にチェックをつけてあげれば、
自動的にドレイニングと新規タスクの立ち上げを実施してくれ、
新しいタスクイメージが適用された状態に更新してくれます。
ただ、タスクは削除⇒作成の順で実行されるため、
クラスタにインスタンスが1台しかない場合は、自動で更新がされません。
一時的にタスクの数を2、Auto Scalingグループを2台にするなどして対応しましょう。
Auto Scalingグループ
基本的にはここまでのコンテナタスク周りの設定でイメージの更新は可能です。
ただ、ECSでは当然ながらEC2インスタンスを使用しています。
このインスタンス周りの設定を変更することもあると思うので、
Auto Scalingグループについてもまとめておきます。
ちなみにEC2画面のメニューの1番下にあります。
Auto Scalingグループでは、
・起動設定
・キャパシティ（最小／最大）
・インスタンスの保護
・その他AZ,サブネット
といった部分の設定が可能です。
起動設定とは、
Auto Scalingグループでインスタンスを起動する際に、
どういったインスタンスを起動（AMIの指定など）するのかといった部分をコントロールするものです。（後述）
その他にはキャパシティによって何台のインスタンスを起動するのかをコントロールし、
また、インスタンスの保護によって意図したインスタンスのみ削除（意図しないインスタンスの保護）を
実施することができます。
例えば、サービスを止めずにインスタンスのAMIを切り替えようとした場合、
以下のような手順で実施することが可能です。
・Auto Scalingグループに紐づく起動設定を検索
・起動設定のコピーで変更したいAMIへ変更、保存
・新規で作成した起動設定をAuto Scalingグループに設定
・Auto Scalingグループのキャパシティを既存の倍（じゃなくてもいいが）にする
・ECS画面からサービスのタスク数を倍（じゃなくてもいいが）にする
・タスクが倍になるまで待つ
・Auto Scalingグループのインスタンスタブから、旧タスクインスタンスのスケールインの保護を解除し、
新タスクインスタンスにスケールインの保護を設定する
・Auto Scalingグループに設定のキャパシティとサービスのタスク数を元の数に戻す
これによって新タスクインスタンスはスケールインからの保護で守られているので、
旧インスタンスだけ削除することが可能です。
また、一旦新、旧両方のタスクが立ち上がった状態になってからスケールインを実施するので、
サービスも止めずに切り替えることが可能です。
起動設定
先程記載したように、起動設定ではAuto Scalingグループでインスタンスを起動する際に、
どういったインスタンスを起動するのかといった部分をコントロールします。
具体的にはAMI、インスタンスタイプ、キーペア、セキュリティグループといった項目の設定が可能です。
ちなみに、詳細設定にある【ユーザーデータ】で指定されたECS_CLUSTERに、
この起動設定で起動したインスタンスは紐づきます。
指定をしない場合は、Defaultのクラスタに紐づくそうです。
おわり
だいぶ一連の流れや役割を理解することができたので、
タスク、イメージに関する変更であれば、タスク定義、サービスの修正が必要で、
タスクを起動するインスタンスに関する変更であればAuto Scalingグループ、起動設定の修正が必要と整理することができました。