Terraformでmoduleを使わずに複数環境を構築して感じた利点

Terraform活用大全 - IaCの今。 Lunch LT(https://findy.connpass.com/event/298972/) 登壇資料

参照先Zenn記事 https://zenn.dev/smartround_dev/articles/5e20fa7223f0fd

Transcript

1. #Terraform_findy Terraformでmoduleを使わずに 複数環境を構築して感じた利点 株式会社スマートラウンド 山原 崇史(@shonansurvivors)
2. 自己紹介 株式会社スマートラウンド SRE/CorporateITグループ エンジニアリングマネージャー 山原 崇史 (やまはら たかし)　 経歴等 　・SIer → 銀行 → Web系ベンチャー数社 → 現職 　・2023 Japan AWS Top Engineers 　・AWS Startup Community Core Member 好きな技術領域 　AWS / Terraform / GitHub Actions shonansurvivors
3. 事業およびプロダクト紹介 ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる smartroundが実現する世界 　統一化・標準化されたデータ管理によって、スタートアップと投資家双方の業務を効率化
4. アジェンダ 1. TerraformでAWSの複数環境を構築する方法 ◦ moduleを使う手法 ◦ moduleを使わない手法 ◦ FAQ 2. moduleを使わないことで感じた利点 3. まとめ
5. 1. Terraformで複数環境を構築する方法 (moduleを使う手法/使わない手法)
6. moduleを使う手法 環境別のディレクトリを作成し、その配下の main.tfから、それぞれ共通の moduleを呼び出す -- <project-name>/ -- envs/ -- dev/ -- backend.tf -- providers.tf -- versions.tf -- main.tf -- stg/ -- backend.tf -- providers.tf -- versions.tf -- main.tf -- prod/ -- backend.tf -- providers.tf -- versions.tf -- main.tf -- modules/ -- <module-name>/ -- main.tf -- variables.tf -- outputs.tf -- README.md -- (other modules/)
7. moduleを使わない手法 backendとtfvarsを切り替えることで、同一ディレクトリ内の同一 tfを複数の環境に適用する -- terraform.sh -- <project-name>/ -- backend.tf -- dev.tfbackend -- stg.tfbackend -- prod.tfbackend -- variables.tf -- dev.tfvars -- stg.tfvars -- prod.tfvars -- terraform.sh -> ../terraform.sh -- providers.tf -- versions.tf -- vpc.tf -- ecs.tf -- ecs_iam.tf -- (other tfs) -- <component-name>/ -- (some files) -- (other components/) terraform { backend "s3" {} } bucket = "example-dev-terraform-state" key = "example.tfstate" encrypt = true profile = "example-dev" region = "ap-northeast-1" dynamodb_table = "terraform-state-lock" $ terraform init \ -backend-config=dev.tfbackend 1. 接続先AWSアカウントや tfstate保存先を決定 env = "dev" # 略 variable "env" { type = string } # 略 $ terraform plan \ -var-file=dev.tfvars 2. 環境ごとに変えたい値は tfvarsから読み込み
8. moduleを使わない手法 backendとtfvarsを切り替えることで、同一ディレクトリ内の同一 tfを複数の環境に適用する -- terraform.sh -- <project-name>/ -- backend.tf -- dev.tfbackend -- stg.tfbackend -- prod.tfbackend -- variables.tf -- dev.tfvars -- stg.tfvars -- prod.tfvars -- terraform.sh -> ../terraform.sh -- providers.tf -- versions.tf -- vpc.tf -- ecs.tf -- ecs_iam.tf -- (other tfs) -- <component-name>/ -- (some files) -- (other components/) $ terraform init \ -backend-config=dev.tfbackend 1. 接続先AWSアカウントや tfstate保存先を決定 $ terraform plan \ -var-file=dev.tfvars 2. 環境ごとに変えたい値は tfvarsから読み込み 毎回-backend-configと-var-fileを 正しく指定するのは 手間かつミスも起こり得るので、 1 & 2 を実施するラッパーを用意 $ ./terraform.sh dev plan 第一引数に環境名を取り、 以降はTerraformコマンドを指定
9. FAQ • workspacesを使わないのはなぜ？ • moduleの利点でもある、設定の強制ができないのでは？毎回ベタ書きするの？ • tfstateを分割する時のアプローチは？ • Terraform CloudやAtlantisのような自動plan/applyサービスでも問題無く扱えるの？ 本セッションは時間が限られているため Zenn記事を参照ください https://zenn.dev/smartround_dev/articles/5e20fa7223f0fd (ラッパースクリプトのサンプルもあります )
10. 2. (独自の)moduleを使わないことで 感じた利点
11. moduleに付随する要素 moduleに付随する様々な要素については、これといったスタンダードは無い認識 moduleの粒度 variablesの 命名規則や 用途 . variablesの型に objectを 採用しているか 否か moduleから moduleを 呼び出すことを 許容しているか 他 組織・人によって 様々なコードが 生まれる(※) ※それ自体に良し悪しは無い
12. 独自のmoduleを使わない(作らない)場合 • 先ほどの各要素が絡まないため、誰が書いてもある程度同じコードに収斂する (と思う) • そうした生まれたコードは、現場固有の「慣れ」を必要とせずに読める (と思う)ので Terraform初学者や新規メンバーがキャッチアップしやすい • そのプロジェクトで初めて採用する AWSサービスのリソースを記述するようなときも、 既存のどのmodule内に書くか新規moduleにするかの検討が不要で、早く書き始められる
13. 3. まとめ
14. まとめ • 複数環境を扱う方法として、環境別ディレクトリと moduleを使うのではなく、 backendとtfvarsを切り替える方法がある • 独自moduleを作成・利用しないことで、キャッチアップしやすいコードになった (と感じる) • 独自moduleの設計を考慮しなくて良い分、早くコードを書き始められるようになった (と思う) 今後新規にTerraformを導入するプロジェクトがあれば、今回のようなファイル構成についても 検討の俎上に載せてもらえたら幸いです。
15. ご清聴ありがとうございました！ Startup comes first! Join our team! jobs.smartround.com