テクノロジー

全部Terraformで管理してはいけない?「かつての最適解」が生んだ管理の壁と、私たちが引き直した境界線

1: nguyen-oi 2026/05/31 07:07

初期構築の全コード化から運用フェーズでの引き算、どこも通る道なんだな

2: keidge 2026/05/31 07:15

この界隈がインフラと呼んでいるものって、私から見たらすべてソフトウェアに見えるので、ちょっと面白く感じる。

3: crimson_diamond 2026/05/31 07:22

​ECSの環境変数をJira運用する愚かな組織の負債を、Terraformの分断という力技で誤魔化しているだけ。分離に伴うState競合やignore_changes、計算資源割当等の致命的な状態管理の課題解決から逃げた、中身と技術力のないポエム

4: internetkun 2026/05/31 07:44

環境変数の変更くらいならいきなりPull Requestを作れば良いだけじゃない?って提案するだけで解決しそう

5: Sampo 2026/05/31 08:07

昔MSの人がスライドで投影してた振り子の絵を思い出す。「我々は一時期すべてを.NETのマネージドコードにしようとしていましたが、振り子の針は戻りつつあります」って

6: honeybe 2026/05/31 08:19

あ、はい(問題の本質は開発運用フローであってIaCではないが…まぁいいか)

7: soxandcity 2026/05/31 10:00

元のリポジトリでCODEOWNERSの設定をすれば良かったのでは。 リポジトリまたいでterraformが分散してるとさすがに厳しいでしょう。

8: morucy 2026/05/31 10:11

チーム間の責任分界点を明確にしようねとか運用フローをちゃんとしようねってだけで、terraformあんまり関係ない気がする。IaCじゃなくても多分この問題は起きてる。

9: sho 2026/05/31 10:36

オーソドックス。待ち時間はチーム境界で発生するので、スピードを重視する組織では当然こういう対策になる。Terraform関係ない

10: dorapon2000 2026/05/31 10:58

“Terraformでは「静」のリソース管理に特化し、ECSタスク定義やStep Functionsの設定といった「動」のリソースは、アプリケーションのリポジトリ側で管理し、SE自身が自律的にデプロイできる体制への移行を進めています。”

11: diffie 2026/05/31 11:07

似た話で、terraformってtfstate範囲のリソースを全部あるべき姿に変えちゃうので、例えばAさんがXアプリを修正中、BさんがYアプリを修正中とかだとつらい(BさんYデプロイでAさんXアプリが戻る)。アプリ関連はtf外としたい

12: hatahata_chan 2026/05/31 11:42

cognitoとかdb系のうっかり削除防止⇨データリソース化の話かと思ったら運用の話だった。スピードのためなら他にも方法がありそう

13: for-my-internet-demo 2026/05/31 14:47

たくさんの人同じ感想抱いたみたいだが、iac関係ないもうちょい変な何か

14: tinsep19 2026/05/31 15:54

AWS Protonが同じ問題意識だったけど、サービス廃止になった。

15: ToTheEndOfTime 2026/05/31 16:49

terraform職人ファイト!

16: kanetann 2026/05/31 19:33

こういうときにこそecspressoよね

17: ftype 2026/06/01 15:56

PR作ればいいだけでワロタ