github actionsとaws ecsの連携

tldr

やりたいこと

• codedeployの再実行
• serviceの終了

stg

• stg用codedeployの再実行

prod

• stg用サービスがあれば削除
• prod用codedeployの再実行

優先順

1. stgはrolling updateが実行されればよい。これはcodedeployだと思っているが確信がない、調査
2. prodはblue/green deployを実行するのだが、その際にinstanceのメモリ容量の上限により、stgのタスクが実行されている場合は終了し、その後にprodのdeployを実行する必要がある

そうだったのね。必要数は1にしてある。てことは1個すでに存在していれば無視しそう。

1455045343504242959のインスタンスが現在実行されている。
rolling updateのserviceを更新して、強制デプロイを実行する

デフォルトでは、ローリング更新プログラムのデプロイタイプを使用するサービスが新しいデプロイを開始すると、必要な数に達するまで、サービススケジューラは新しいタスクを起動します。

https://docs.aws.amazon.com/ja_jp/AmazonECS/latest/userguide/deployment-type-ecs.html

primaryとactive2つのデプロイがある

3725306918409588244のデプロイidのインスタンスが実行されている。
さっきと違うのでデプロイは行われたようだ

サービスの設定で必要なタスクの数を0にしていたのを忘れていた。
1に変更した。

rolling updateでタスク必要数が１なら、０になって１が新しく作成されるのかと思ってた。
違うようだ。動きを見てると、１→２→１。

イメージ
１(old)→０→１(new)

実際
１(old)→2(old & new)→1(new)

多分こう

https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/update/update-intro/
これはk8sだが、大枠は一緒だろう

localでk8sで遊んでみるのもよさそうだな
おうちk8sもやってみたいんだよな

用途としてはあっていたけど、認識が間違っていた。
ec2インスタンスを２分割にして使っている関係上、2コンテナ実行できる。
blue/green deployは2コンテナ立ち上がり、１コンテナ残る想定だった。
rolling updateは1コンテナが消え、新しい１コンテナが立ち上がる、つまり１コンテナ立ち上がる余裕があればいけると思っていた。
しかし、blue/green deployはblueを消さずに残しておく、greenへのテスト接続ができる、blueとgreenへのトラフィックの分散を徐々に行うというような機能がメイン。
そして、rolling updateは2コンテナ一瞬立ち上がるが、両方が立ち上がった時点でトラフィックを切り替えるだけ。
という認識になった。
つまり、どちらにしろ２コンテナ立ち上げる必要がある。これが認識間違い。
用途としての正しさはblue/greenでは、blueが最初に起動している必要がある。これ最初に詰まった。
rolling updateは初期コンテナを必要としないので例えば、productionとstagingの両方を起動している状態でstagingのみ一旦削除して、もう一度立ち上げ直すことができる。
あれ？コンテナを停止したら、もう一回勝手に立ち上がるのか？と思ったけど、auto scalingしてないので起動しなかった。サービスごと毎回作り直したほうが簡単そうだな。

おうちk8sやりたいな。もう少ししたらだな。今月中には買えるだろう。ただ机の上が悲惨だな