‣
また見たい思ったインターネット上の記事を クリップ しています。
📎 クリップした記事
- moduleは複雑になりがちだし、気づけばそこからも参照されてる？という共通化が生まれるリスクがある。
- 複雑化がますことで、Aだけ新しくしたいけど、moduleを変更するとBもCも変更が生まれる問題
- ブランチ戦略などでmainじゃなけばBにはapplyしなければいいけど、そうなると特定のブランチが大きく育つ and 他の変更を追加できない。
- moduleにrequire要素を追加すると、もしほかでも参照していたら、関係ないworkspaceまで変更がうまれる。（そもそもそれをするなだけど）
- module間の依存。例えばネットワークとRunなどがあり、思想を作り上げて浸透させるのは難しい。
- 会社によるがサービスが増えれば増えるほど、そういった依存が増えていく。増えると最後あとできれいにすることにとても神経を使う
など確かにmoduleはとても複雑になる。導入時点のメンバーが使えていればいいけど、全員がTFに親しんでない環境では、そういった複雑さは触ったり、理解したりする心理的ハードルはあがっちゃうよねぇ。
tfvarsを使うことで得られるメリットは、moduleという考え方や依存に悩まなくていいことかな。
AでもBでも同じ物書く（例えばIAM作ってRoleを割り当てるmoduleなど）ことあると、共通化したくなることもあるかもしれないけど、そういった共通化を防ぐことにはとてもメリットあるよね。
読む・書くに関しては言いなーと思う一方で、運用し続ける（数年）視点で考えると、後でつらくなる課題もありそう。まぁtfmigrate使うとか、state rm and importで頑張るでも全然よさそうだけどね。
moduleでもtfvarsでも解決できないことは、`count=0` とか count=1 とかでDevでは作る、Prodでは作らないとかをコントロールすることになる事かな。
↑を解決するには、もう少し意味ある単位でmodule化してversion管理して、prodのroot moduleではrun v1、devのroot moduleではrun v2を参照するとか、ヴァージョン管理の複雑さは生まれるけど、そういう方法かな。どこの複雑さやどんなリスクを許容して、どんなメリットを受けるかだと思うので、組織にあった形になっているとしたらとても良いなーという雑感想
🏷️ タグ
クリップ
クリップ
🗞 登場した用語まとめ
Infrastructure as Code
Infrastructure as Code
Terraform
Terraform