terraformでECSのクラスタ、サービスのモジュールの構成を変更した

terraformでECSのclusterとserviceを作成するにあたって実際の運用を通して少し変わってきたのでまとめておく。

最初のterraformのmodule構成で起きた問題点

以前は、aws_ecs_clusterとaws_autoscaling_groupを同一moduleにおいていた。

問題その1: インスタンスの設定が無停止で変更できない

これだと、何が問題かというと、autoscaling groupで立ち上がるインスタンスの設定はlaunch configurationというものに書くんだけどそれを書き換えたい場合に、既存のautoscaling groupが一時的に死んでしまい無停止で交換ができないようになってしまっていた。 clusterとautoscalingの関係を1:1と捉えてしまっていたのが問題で、1:Nということを分かっていれば無停止で構成変更ができるように出来ていた。

問題その2: spot fleetなど別の方法でクラスタに所属させられない

あと、こんな風にautoscalingじゃなくて、spot fleetでやりたいという場合には、clusterを再作成しないといけなくなってしまう問題があることも分かった。clusterに所属させられるのはautoscalingだけとして（別の方法があるのは頭では分かっていたけど）やってしまったのがダメだった。

変更後

• clusterはモジュール化しない
• autoscaling_group、spotfleetでそれぞれモジュール化

ECSのclusterはただの名前を持った箱ぐらいの概念で、各インスタンスのエージェントによって、インスタンスがその箱に自ら入りにいくという感じ。なので、前回のようにclusterとautoscalingを同じモジュールにするというのはよくなかった。

このような構成にすることで、autoscalingなインスタンス、spot fleetなインスタンス、何なら手動で立ち上げたEC2インスタンスだって所属させたり減らしたりすることができる。

無停止のインスタンス入れ替えも、新しいインスタンスを所属させたあとに、せっせと古い方のインスタンスをドレイニングしていって全部移し終わったら丸ごとautoscalingやspot fleetのモジュールごと削除していけばOKとなる。

まとめ

インフラもアプリ開発でやっているようなオブジェクト指向とか、クラスとインスタンスの関係みたいなものを意識するとすごくうまく共通化できたり問題が解決できたりしておもしろい。あの頃の経験も無駄ではなかった