terraform moduleの難しさについて。同意見ですw > 無理に向き合わない
インフラのモジュール化むずすぎワロタｗ 中間言語でポリシーと分離するって、それ天才の発想じゃんｗｗｗ
terraformのモジュールは結合と分割を扱うにはセンスが悪いので、単に繰り返しの単位として使う方がいい stateを分割するならディレクトリ分けてリモート参照の方がいいと思う しかし素のtfには機能が足りてない
わかる。公開モジュールは自分たちが求めている抽象化レベルと合わないことが多いので、結局は自分たちが繰り返し利用する or 一部設定の標準化を図りたい場合に、ニーズに合わせて用意している。
肥大化したCFnは苦痛。でもCDKも維持管理考えると苦痛。CFnを長々書いてた方が引き継ぎも容易。最適解があったら教えてください。
わかる
自分の感覚逆かなー。インフラエンジニアが詳細いじりたい人が多い印象。全部同じ構成で作っちゃえばいいじゃん、と思う。アプリケーションに比べてちょっとした違いでコスト差が大きい、とかもあるのかな
「02-05章 まとめ」がすごく良い。こういった違いがあるのに、雑に as "Code" を目指すのは間違いだと思うんだよなぁ。IaC は銀の弾では無い。
public module使うなは完全同意。Terraform RegistryとGitHubリポジトリが連携されてるmoduleを使ってた時に、リポジトリが非公開になったせいでRegistryからも消えてCIがぶっ壊れたことがある
うすうすそう思っていたけど、言語化されてよかった
同じような方針だわ Terraformと同じくAnsible Galaxyもほぼ使わなかった 完全にコントロールできないものは困る 書くのがかったるい問題についてはAIが解決してくれた
たしかに。何も隠蔽できないので、信頼できる自前のモジュールを使うのが手堅い選択肢になる
流石の言語化
よかったー！
わかりすぎるーー！
とても良い資料だわ！！！
わかる気はするが、クロスアカウントでのRAM作業やPHZ共有とか他社接続時のステップに合わせた作業状態の管理便利です
素晴らしい言語化だ。さすがだ。
なぜインフラコードのモジュール化は難しいのか - アプリケーションコードとの本質的な違いから考える
terraform moduleの難しさについて。同意見ですw > 無理に向き合わない
インフラのモジュール化むずすぎワロタｗ 中間言語でポリシーと分離するって、それ天才の発想じゃんｗｗｗ
terraformのモジュールは結合と分割を扱うにはセンスが悪いので、単に繰り返しの単位として使う方がいい stateを分割するならディレクトリ分けてリモート参照の方がいいと思う しかし素のtfには機能が足りてない
わかる。公開モジュールは自分たちが求めている抽象化レベルと合わないことが多いので、結局は自分たちが繰り返し利用する or 一部設定の標準化を図りたい場合に、ニーズに合わせて用意している。
肥大化したCFnは苦痛。でもCDKも維持管理考えると苦痛。CFnを長々書いてた方が引き継ぎも容易。最適解があったら教えてください。
わかる
自分の感覚逆かなー。インフラエンジニアが詳細いじりたい人が多い印象。全部同じ構成で作っちゃえばいいじゃん、と思う。アプリケーションに比べてちょっとした違いでコスト差が大きい、とかもあるのかな
「02-05章 まとめ」がすごく良い。こういった違いがあるのに、雑に as "Code" を目指すのは間違いだと思うんだよなぁ。IaC は銀の弾では無い。
public module使うなは完全同意。Terraform RegistryとGitHubリポジトリが連携されてるmoduleを使ってた時に、リポジトリが非公開になったせいでRegistryからも消えてCIがぶっ壊れたことがある
うすうすそう思っていたけど、言語化されてよかった
同じような方針だわ Terraformと同じくAnsible Galaxyもほぼ使わなかった 完全にコントロールできないものは困る 書くのがかったるい問題についてはAIが解決してくれた
たしかに。何も隠蔽できないので、信頼できる自前のモジュールを使うのが手堅い選択肢になる
流石の言語化
よかったー！
わかりすぎるーー！
とても良い資料だわ！！！
わかる気はするが、クロスアカウントでのRAM作業やPHZ共有とか他社接続時のステップに合わせた作業状態の管理便利です
素晴らしい言語化だ。さすがだ。