はじめてTerraform Moduleを作成した際に感じた疑問点
2.9K Views
July 05, 23
スライド概要
温かい目で見守ってください
関連スライド
各ページのテキスト
はじめてTerraform Moduleを 作成した際に感じた疑問点 waiwai @ystkfujii
自己紹介 ふじいです / : ＠ystkfujii 最近は、Terraform + Ansible でk8sクラスターを作 成する特殊な作業をしています 個人的ニュース 月の土地を買いました ここらへん
はじめに ● 今日話すこと ○ Terraform Moduleとは？ ○ Terraform Moduleの作成時に疑問に思ったこと ● 話さないこと ○ stateファイルに関すること ○ providerに関すること ○ Terraform Cloudがマジ便利だ！ ● 想定聴衆 ○ Terraformを最近触り始めた方 ○ Terraform Moduleってなに？って方
Terraform Moduleとは ● まず、TerraformとはInfrastructure as Code ツールの1種 ○ さまざまなリソースのプロビジョニングおよび管理ができる 参考：Providers ● Terraform Moduleとは、リソースを定義したコードを 1つのディレクトリにまとめたもの 例えば、、、 web-server リソースをコード化 Instance プロビジョニング main.tf variables.tf outputs.tf Loadbalancer Instance 参考：Modules
標準的なModule構造がある ● エントリーポイントとなるリソー ス(Root Module) Sub Module（Nested Module） ○ Root Moduleから参照されるリソースの塊 ○ Root Moduleとの違いはProvider定義の有無 ※注意：Terraform v0.10以前は仕様が異なる Sub Module（右記参照 参考：Legacy Shared Modules with Provider Configurations ※以降、Root ModuleとSub Module含めてModuleと表記 ● Sub Moduleの使用例 Moduleを作成するメリット ○ 構成の整理 ○ 構成のカプセル化 ○ 構成の再利用性 ○ 一貫性の提供 ○ セルフサービス 参考：What are modules for ? 参考：Standard Module Structure
標準的なModule構造がある ● エントリーポイントとなるリソー ス(Root Module) Sub Module（Nested Module） ○ Root Moduleから参照されるリソースの塊 ○ Root Moduleとの違いはProvider定義の有無 注意：Terraform v0.10以前は仕様が異なる よし、Moduleを作ってみよう！ 参考：Legacy Shared Modules with Provider Configurations Sub Module（右記参照 ○ 作成するメリット ■ 構成の整理 ■ 構成のカプセル化 ■ 構成の再利用性 ■ 一貫性の提供 ■ セルフサービス いや、ちょっと待てよ。。。 Sub Moduleの使用例 ※以降、Root ModuleとSub Module含めてModuleと表記 参考：Standard Module Structure
標準的なModule構造がある 疑問１：main.tfが巨大化するのでは？ 疑問２：moduleってどの単位で作成したらいいんだ？ 疑問３：moduleをチームで共有する場合、 どうしたらいいんだ？ 疑問４：sub sub moduleってありだろうか？
疑問１：main.tfが巨大化するのでは？ ループ処理で複製できるとはいえ、 main.tfで全てのリソースを定義すると可読性が悪くなる main.tf 参考: Explore a Scoping Example 読むのがつらい。。。
疑問１：main.tfが巨大化するのでは？ ● ● 対処： ○ １：main.tfのリソースをModuleに切り出す（後述） ■ Moduleのスコープが広すぎる可能性 ○ ２：main.tfの分割 ■ 拡張子tfが処理対象となるので、ファイル名は main.tfでなくてもよい ※JSONもサポートされている ■ リソースの記載順も関係ない 参照：JSON Configuration Syntax ● Terraform側で依存関係を考慮し作成順を決めてくれる たとえば、main.tf以外の名前として ○ リソースの名前： instances.tf ○ それっぽい名前： network.tf、 dependencies.tf リソースの設定変更の際に、変更対象のファイルが一目で分かる名付けが大切
疑問２：Moduleの作成単位 Moduleはリソースの抽象化 そのため、量産すると構成が複雑化 する 逆に、Module内にリソースが増加すると、 Moduleの目的が分かりづらく なる どのような観点で分割していけば良いのか？ 参考: Explore a Scoping Example
疑問２：Moduleの作成単位 ● Module作成時の考慮事項 ○ カプセル化（Encapsulation） ■ ○ 特権（Privileges） ■ ○ リソースのグルーピングは正しいか？ 他チームの管理するリソースが含まれていないか？ 変動性（Volatility） ■ リソースのライフサイクル（デプロイ頻度等）がそろっているか？ 参考：Scope the requirements into appropriate modules
疑問２：Moduleの作成単位 参考：Scope the requirements into appropriate modules 日本語の記事を書いてくれる方も！ Terraform module設計時に考慮すべき３ つの観点
疑問３：Moduleを他のプロジェクトで再利用したい ● ModuleからModuleを参照する方法は 3種類 １：同一リポジトリ内から参照 ※Standard Module Structureを含む ２：別のプライベートリポジトリを参照 チーム内だけ 参照可能 ３：別のパブリックリポジトリを参照 誰でも 参照可能 Moduleの変更容易性 大 小
疑問３：Moduleを他のプロジェクトで再利用したい ● Moduleの公開場所 ○ GitHub ○ Terraform Module Registry ○ などなど 参考：Module Sources ● その他 ○ Terraform Module Registryで公開するためには、リポジトリ名に条件あり terraform-<PROVIDER>-<NAME> ○ チーム全員でインフラを管理する観点での考察 https://tech.layerx.co.jp/entry/2021/11/04/170000 参考：Preparing a Module Repository
疑問４：Sub Sub… Moduleはあり？ Moduleの中にModuleを定義することは可能 ただ、推奨される構成ではない Sub Sub Moduleの例 フラットな構成が推奨される 参考：Module Composition
まとめ ● Terraform Module作成時に感じた疑問点 ○ １：main.tfが巨大化するのでは？ ■ ○ ２：Moduleの作成単位とは？ ■ ○ 考慮事項：Encapsulation / Privileges / Volatility ３：Moduleを他プロジェクトで利用するためには？ ■ ○ Terraformでは、tf拡張子が処理対象となるため、ファイル分割が可能 置き場所：同一リポジトリ /プライベートリポジトリ /パブリックリポジトリ ４：Sub Sub … Moudleはあり？ ■ 可能だが、フラットな構成が推奨される Terraform Moduleには標準的な構造が存在する が、あくまで標準であり、ユースケースに合わせてカスタマイズする必要がある
宣伝：CloudNative Days Fukuoka 2023
記載されている会社名、商標名、またはサービス名は、 各社の商標登録または商標です。