複数のtfstateでデプロイする際に、Plan時とApply時の差分が発生する可能性とその対処
かいものCIなどで👇などを利用してPRのPush時にコメントして Merge時にApplyする運用は割と標準的な運用スタイル
かいものしかし、複数のPRが走っていて、PushとMergeの間に別のPRがMergeされてしまうと、想定と異なったApplyがされる可能性がある。
PR-AとPR-Bがあったとして、
1. PR-A Plan < VPC-1のCIDRを変えるよ
2. PR-B Plan < VPC-1のTagを変えるよ
3. PR-B Merge < VPC-1のTagを変えたよ
4. PR-A Merge < VPC-1のCIDRを変えるよ
この順で処理させると、Tagの変更は適用されますが、意図した変更にはなってないはず。
もし、Tagの値を元にCIDRを決めるようなロジックを組んでた場合、CIDRの値も変わってくるはず
かいもの🤓 < じゃあ全PRすべてRebaseしてからMergeすることを強制したらええねん
これはPRの待ち行列が発生してしまいます。
複数のDeveloperがPRを柔軟にマージできないと、tfstateの増加に対し開発速度がスケールされない。
特にTerraformの適用はそれなりに時間がかかるので、あなたの待ちPRが4つなので20分後ぐらいにまた確認してね運用になっちゃいます。
多くのパターンにおいては、上記のようなことは発生しづらいはずで、エッジケースのために待ち行列を作るのはイケてない
かいもの解決策として、Applyはシングルスレッドで動作するようにして
PRのPush時にPlanの出力をHash化してキャッシュしておく。
PRのMerge時に、一度PlanしてPush時の出力と変化がないかを確認する
変化があれば、AbortしてPRの作成者に通知する
で、これらをGHAのMergeQueueなどで運用すればうまくいく(はず)
かいもの問題は、applyがAbortされた場合、PRはマージされてしまう点
かいものボツ案
依存関係のあるtfstateを完璧にあぶり出すことができるのであれば、
tfstateの名前を持ったGHAのConcurrencyを定義してやればいけるかなと思ったけど、
concurrency.groupはexact matchしかできなそうなので無理筋かな
concurrency:
groupd: apply-dependson-tfstate1-tfstate2
tfstate1とtfstate2どちらかにだけ依存関係を持つCIを止めれないし、そもそもPlanとApplyが違っちゃうよね問題に対するソリューションではない