22/8/25 HashiTalks:Japanにて発表
ベストなTerraformディレクトリ構成を考察してみたThursday, August 25, 2022Haruka Sakihara
View Slide
自己紹介Haruka Sakihara• アクセンチュア株式会社テクノロジーコンサルティング本部所属• 普段はクラウドインフラ構築の支援をしております• アプリケーション……プライベートだとGo, 仕事だと少しPython• インフラ……ほとんどAWSTwitter:@saki_engineerGitHub: @saki-engineering
Terraformのディレクトリ構成、迷いませんか？
Terraformコードのディレクトリ構成パターンTerraformのディレクトリ構成は様々なパターンが考えられますが、ここでは以下2パターンについて考察していきたいと思います。パターン1のディレクトリ構成 パターン2のディレクトリ構成stg、prdのような環境ごとにディレクトリを分ける構成DB, EC2インスタンスのようなリソースごとにディレクトリを分ける構成
パターン1: 環境ごとにディレクトリを分ける構成ある環境を表すIaCコードを1カ所(envs/xxx)にまとめる方式です。複数環境から利用されるコードはモジュール化してmodules配下に配置することもあります。modules配下複数環境から使われる共通モジュールを配置envs配下各環境内で必要なリソース定義を記述(共通モジュール呼び出しもあり)envs/stg直下module “db” {source = “../../modules/db”}module “ec2” {source = “../../modules/ec2”}module “network” {source = “../../modules/network”}
パターン2: リソースごとにディレクトリを分ける構成一方こちらはまずリソースごとに最上位ディレクトリを切り、その中に各環境ごとのリソース定義を記述する方式です。db配下各環境ごとのDB設定を記述ec2/stg直下resource “aws_instance“ “my_server” {// stg用の設定}network/stg直下resource “aws_vpc“ “my_vpc” {// stg用の設定}db/stg直下resource “aws_db_instance“ “my_db” {// stg用の設定}ec2配下各環境ごとのインスタンス設定を記述network配下各環境ごとのネットワーク設定を記述
ディレクトリ構成の比較本セッションでは、「環境ごとにディレクトリを切るパターン」「リソースごとにディレクトリを切るパターン」それぞれを3つの観点から比較していきます。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切るリソースごとにディレクトリを切る
apply回数での比較パターン1構成の場合、stg環境構築の際に必要なterraform applyの回数は1回で済みます。一方パターン2構成の場合、stg環境関連リソースのコードを含んだディレクトリの数だけterraformapplyが必要です。パターン1のディレクトリ構成 パターン2のディレクトリ構成stg環境構築のためには、envs/stg直下でのterraform apply1回で済むこれら3つすべてでterraform applyを実行する必要がある(ただし、スクリプトやOSS(Atlantis)を導入することでまとめてapplyも実現可能)
ディレクトリ構成の比較パターン1の構成だとapplyは1度で済みます。パターン2では複数回のapplyが必要ですが、それをカバーするスクリプトやOSSを活用することでデメリットをカバーすることができます。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済むリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)〇 △
ディレクトリ構成の比較次に、「生成されるstateファイル」という観点で比較していきます。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済むリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)〇 △
tfstateファイルの比較実際にリソース作成が行われて実環境の構成が変化した際には、Terraformはその変更内容をtfstateファイル中に書き込み反映させる作業を行います。AWS CloudAvailability Zone aAvailability Zone btfstateファイル• AZ-aにEC2インスタンスが2→3個• AZ-bにEC2インスタンスが2個.tfファイル• AZ-aにEC2インスタンスが3個• AZ-bにEC2インスタンスが2個1. terraform applyの実行3. リソース作成2. 差分の検知 4. リソース作成結果の反映同内容
tfstateファイルの比較applyコマンドを実行するディレクトリというのは、tfstateファイルが管理するコード範囲とイコールになります。そのため、ディレクトリを細かく区切るということはtfstateファイルを区切るということと同一であり、planやapplyの速度に影響を及ぼします。stg環境用のtfstateファイルができるstg環境にあるDB用のtfstateファイルができるstg環境にあるインスタンス用のtfstateファイルができるstg環境にあるNW用のtfstateファイルができるパターン1のディレクトリ構成 パターン2のディレクトリ構成
tfstateファイルの比較applyコマンドを実行するディレクトリというのは、tfstateファイルが管理するコード範囲とイコールになります。そのため、ディレクトリを細かく区切るということはtfstateファイルを区切るということと同一であり、planやapplyの速度に影響を及ぼします。stg環境用のtfstateファイルができるstg環境にあるDB用のtfstateファイルができるstg環境にあるインスタンス用のtfstateファイルができるstg環境にあるNW用のtfstateファイルができるDBのみの変更の場合でも、他リソース情報を含んだこのtfstateファイルを扱う必要があるDBのみの変更の場合は、このtfstateのみ扱えばよいパターン1のディレクトリ構成 パターン2のディレクトリ構成
ディレクトリ構成の比較パターン1の構成よりもパターン2の構成のほうが、tfstateファイルを細かく区切ることができるため、plan/applyの高速化が見込めます。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済む大きくなるためplan/apply速度が落ちるリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)小さく済むためplan/apply速度も速い〇×△〇
ディレクトリ構成の比較まとめ最後に、「複数人の開発者がいるチームでTerraformのコードを扱う際に、同時作業がどれだけ可能になるか」という観点で比較していきます。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済む大きくなるためplan/apply速度が落ちるリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)小さく済むためplan/apply速度も速い〇×△〇
同時作業数の比較 – パターン1構成の場合最上位ディレクトリを環境ごとに切る場合には、envs/stg直下とenvs/prd直下にそれぞれstateファイルが生成されることになります。そのため、ある環境内にあるリソースの変更はすべて同時にplan/applyされることになります。…stg用のstate…prd用のstatestateファイル構成 リソース変更の際に参照されるstateファイル2つのリソース変更を吸収する1つのstateが
同時作業数の比較 – パターン1構成の場合リソースごとにディレクトリを切る場合には、各環境・各リソースごとにstateが生成されます。そのため、異なるリソースの変更は異なるstateを用いてplan/applyが実行されます。…db/stg用のstate…db/prd用のstate…ec2/prd用のstate…ec2/stg用のstate…network/prd用のstate…network/stg用のstatedbの変更はこのstateが吸収インスタンスの変更はこのstateが吸収stateファイル構成 リソース変更の際に参照されるstateファイル
同時作業数の比較Terraformにおいて、あるコードが同じstateファイルに属しているというのは「plan/applyが同時に行われる」というだけでなく、Lock機能によって並列作業可能なapply数が制限されるということも意味します。envsstg……ステージング環境用のコードを格納prd……本番環境用のコードを格納stg環境用のstateファイルができるprd環境用のstateファイルができる1つの同じstateファイルに属しているコードは……• まとめてplan/applyが行われる• このコードに対して複数個同時にapplyができないように、Lockがかかる
(余談)planの並行作業Terraformで複数個のplanを同時並行して行うと、どれか一つのapplyが行われるとその他のplan結果が正しくないものになるという問題があります。AWS CloudTerraformコードインスタンス1個PR1PR2実環境Terraformコードインスタンス3個plan結果インスタンス+1個plan結果インスタンス-1個plan実行plan実行AWS Cloudapply実行plan結果インスタンス+1個OutDated!
ディレクトリ構成の比較まとめTfstateファイルを細かく区切ることで、apply時にかかるロックの範囲をも細かく区切ることができます。結果、同時作業可能数がパターン2のほうが多くなることとなります。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済む大きくなるためplan/apply速度が落ちる同環境内では別作業を同時にできないリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)小さく済むためplan/apply速度も速い同環境内でもリソースが別なら同時に作業可能〇××△〇〇
ディレクトリ構成の比較まとめ従来なら考えずらかったパターン2のディレクトリ構成も、複数人で使用するワークフロー構築・Atlantisの使用前提で考えると十分メリットがある構成と言えると思います。パターン2のディレクトリ構成パターン1のディレクトリ構成コンセプトapply回数tfstateファイルの大きさ同時作業可能数環境ごとにディレクトリを切る1回で済む大きくなるためplan/apply速度が落ちる同環境内では別作業を同時にできないリソースごとにディレクトリを切る複数回必要(スクリプトやAtlantis使用なら1回で済む)小さく済むためplan/apply速度も速い同環境内でもリソースが別なら同時に作業可能〇××△〇〇
Thank Youご意見、ご質問ありましたらお気軽にご連絡下さい[email protected]Haruka Sakihara(崎原 晴香)
harukasakihara
cimadai
nwiizo
aki_iinuma
yutoy
takasehideki
knsg16
route06
tomoaki25
clairegiordano
cybozuinsideout
kenchan
line_developers_tw
brad_frost
andyhume
samlambert
speakerdeck
vanstee
hatefulcrawdad
eitanlees
tammyeverts
holman
jeffersonlam
chrisshort
mongodb