#Terraform_findy Terraformでmoduleを使わずに 複数環境を構築して感じた利点 株式会社スマートラウンド 山原 崇史(@shonansurvivors)

自己紹介 株式会社スマートラウンド SRE/CorporateITグループ エンジニアリングマネージャー 山原 崇史 (やまはら たかし)　 経歴等 　・SIer → 銀行 → Web系ベンチャー数社 → 現職 　・2023 Japan AWS Top Engineers 　・AWS Startup Community Core Member 好きな技術領域 　AWS / Terraform / GitHub Actions shonansurvivors

事業およびプロダクト紹介 ミッション 　スタートアップが可能性を最大限に発揮できる世界をつくる smartroundが実現する世界 　統一化・標準化されたデータ管理によって、スタートアップと投資家双方の業務を効率化

アジェンダ 1. TerraformでAWSの複数環境を構築する方法 ○ moduleを使う手法 ○ moduleを使わない手法 ○ FAQ 2. moduleを使わないことで感じた利点 3. まとめ

1. Terraformで複数環境を構築する方法 (moduleを使う手法/使わない手法)

moduleを使う手法 環境別のディレクトリを作成し、その配下の main.tfから、それぞれ共通の moduleを呼び出す -- / -- 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/ -- / -- main.tf -- variables.tf -- outputs.tf -- README.md -- (other modules/)

moduleを使わない手法 backendとtfvarsを切り替えることで、同一ディレクトリ内の同一 tfを複数の環境に適用する -- terraform.sh -- / -- 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) -- / -- (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から読み込み

moduleを使わない手法 backendとtfvarsを切り替えることで、同一ディレクトリ内の同一 tfを複数の環境に適用する -- terraform.sh -- / -- 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) -- / -- (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コマンドを指定

FAQ ● workspacesを使わないのはなぜ？ ● moduleの利点でもある、設定の強制ができないのでは？毎回ベタ書きするの？ ● tfstateを分割する時のアプローチは？ ● Terraform CloudやAtlantisのような自動plan/applyサービスでも問題無く扱えるの？ 本セッションは時間が限られているため Zenn記事を参照ください https://zenn.dev/smartround_dev/articles/5e20fa7223f0fd (ラッパースクリプトのサンプルもあります )

2. (独自の)moduleを使わないことで 感じた利点

moduleに付随する要素 moduleに付随する様々な要素については、これといったスタンダードは無い認識 moduleの粒度 variablesの 命名規則や 用途 . variablesの型に objectを 採用しているか 否か moduleから moduleを 呼び出すことを 許容しているか 他 組織・人によって 様々なコードが 生まれる(※) ※それ自体に良し悪しは無い

独自のmoduleを使わない(作らない)場合 ● 先ほどの各要素が絡まないため、誰が書いてもある程度同じコードに収斂する (と思う) ● そうした生まれたコードは、現場固有の「慣れ」を必要とせずに読める (と思う)ので Terraform初学者や新規メンバーがキャッチアップしやすい ● そのプロジェクトで初めて採用する AWSサービスのリソースを記述するようなときも、 既存のどのmodule内に書くか新規moduleにするかの検討が不要で、早く書き始められる

3. まとめ

まとめ ● 複数環境を扱う方法として、環境別ディレクトリと moduleを使うのではなく、 backendとtfvarsを切り替える方法がある ● 独自moduleを作成・利用しないことで、キャッチアップしやすいコードになった (と感じる) ● 独自moduleの設計を考慮しなくて良い分、早くコードを書き始められるようになった (と思う) 今後新規にTerraformを導入するプロジェクトがあれば、今回のようなファイル構成についても 検討の俎上に載せてもらえたら幸いです。

ご清聴ありがとうございました！ Startup comes first! Join our team! jobs.smartround.com