[TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) >  [[Tags/クリップ|クリップ]] - ==index== 📎 クリップした記事 🏷️ タグ 🗞 登場した用語まとめ > [!important] > また見たい思ったインターネット上の記事を [[Tags/クリップ|クリップ]] しています。 ### 📎 クリップした記事 > [!info] Terraformでmoduleを使わずに複数環境を構築する > Terraformを使って複数の環境を扱う代表的な方法として、環境ごとにディレクトリを分けつつ、そこから共通のmoduleを呼び出すというものがあります。 > [https://zenn.dev/smartround_dev/articles/5e20fa7223f0fd](https://zenn.dev/smartround_dev/articles/5e20fa7223f0fd) [https://speakerdeck.com/shonansurvivors/building-multiple-environments-without-using-modules-in-terraform](https://speakerdeck.com/shonansurvivors/building-multiple-environments-without-using-modules-in-terraform) - 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を参照するとか、ヴァージョン管理の複雑さは生まれるけど、そういう方法かな。どこの複雑さやどんなリスクを許容して、どんなメリットを受けるかだと思うので、組織にあった形になっているとしたらとても良いなーという雑感想 ### 🏷️ タグ #### タグ |Name|関連ページ数| |---|---| |[[Tags/クリップ\|クリップ]]|315| ### 🗞 登場した用語まとめ #### 用語 |Name| |---| |[[Terminology/Terraform\|Terraform]]| |[[Terminology/Infrastructure as Code\|Infrastructure as Code]]| [TOP](https://www.notion.so/shinofara-1a690b35713b45bf8ea599bfa73fb7df?pvs=21) >  [[Tags/クリップ|クリップ]]