Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ベストな Terraform ディレクトリ構成を考察してみた

ベストな Terraform ディレクトリ構成を考察してみた

22/8/25 HashiTalks:Japanにて発表

Haruka Sakihara

August 25, 2022
Tweet

More Decks by Haruka Sakihara

Other Decks in Technology

Transcript

  1. パターン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配下 各環境ごとのネットワーク設定を記述
  2. ディレクトリ構成の比較 次に、「生成されるstateファイル」という観点で比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの 大きさ

    同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 〇 △
  3. tfstateファイルの比較 実際にリソース作成が行われて実環境の構成が変化した際には、Terraformはその変更内容をtfstate ファイル中に書き込み反映させる作業を行います。 AWS Cloud Availability Zone a Availability Zone

    b tfstateファイル • AZ-aにEC2インスタンスが2→3個 • AZ-bにEC2インスタンスが2個 .tfファイル • AZ-aにEC2インスタンスが3個 • AZ-bにEC2インスタンスが2個 1. terraform applyの実行 3. リソース作成 2. 差分の検知 4. リソース作成 結果の反映 同内容
  4. tfstateファイルの比較 applyコマンドを実行するディレクトリというのは、tfstateファイルが管理するコード範囲とイコー ルになります。そのため、ディレクトリを細かく区切るということはtfstateファイルを区切るとい うことと同一であり、planやapplyの速度に影響を及ぼします。 stg環境用の tfstateファイルができ る stg環境にあるDB用の tfstateファイルができ る

    stg環境にあるインスタンス 用の tfstateファイルができる stg環境にあるNW用の tfstateファイルができ る DBのみの変更の場合でも、 他リソース情報を含んだ このtfstateファイルを扱う必要がある DBのみの変更の場合は、 このtfstateのみ扱えばよい パターン1のディレクトリ構成 パターン2のディレクトリ構成
  5. ディレクトリ構成の比較 パターン1の構成よりもパターン2の構成のほうが、tfstateファイルを細かく区切ることができるた め、plan/applyの高速化が見込めます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの

    大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 〇 × △ 〇
  6. ディレクトリ構成の比較まとめ 最後に、「複数人の開発者がいるチームでTerraformのコードを扱う際に、同時作業がどれだけ可能 になるか」という観点で比較していきます。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの

    大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 〇 × △ 〇
  7. 同時作業数の比較 Terraformにおいて、あるコードが同じstateファイルに属しているというのは「plan/applyが同時 に行われる」というだけでなく、Lock機能によって並列作業可能なapply数が制限されるということ も意味します。 envs stg ……ステージング環境用の コードを格納 prd ……本番環境用の

    コードを格納 stg環境用のstateファイルができる prd環境用のstateファイルができる 1つの同じstateファイルに属しているコードは…… • まとめてplan/applyが行われる • このコードに対して複数個同時に applyができないように、Lockがかかる
  8. (余談)planの並行作業 Terraformで複数個のplanを同時並行して行うと、どれか一つのapplyが行われるとその他のplan結 果が正しくないものになるという問題があります。 AWS Cloud Terraformコード インスタンス1個 PR1 PR2 実環境

    Terraformコード インスタンス3個 plan結果 インスタンス+1個 plan結果 インスタンス-1個 plan実行 plan実行 AWS Cloud apply実行 plan結果 インスタンス+1個 OutDated!
  9. ディレクトリ構成の比較まとめ Tfstateファイルを細かく区切ることで、apply時にかかるロックの範囲をも細かく区切ることができ ます。結果、同時作業可能数がパターン2のほうが多くなることとなります。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの

    大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる 同環境内では 別作業を同時に できない リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 同環境内でも リソースが別なら 同時に作業可能 〇 × × △ 〇 〇
  10. ディレクトリ構成の比較まとめ 従来なら考えずらかったパターン2のディレクトリ構成も、複数人で使用するワークフロー構築・ Atlantisの使用前提で考えると十分メリットがある構成と言えると思います。 パターン2のディレクトリ構成 パターン1のディレクトリ構成 コンセプト apply 回数 tfstate ファイルの

    大きさ 同時作業 可能数 環境ごとに ディレクトリを切る 1回で済む 大きくなるため plan/apply速度が 落ちる 同環境内では 別作業を同時に できない リソースごとに ディレクトリを切る 複数回必要 (スクリプトや Atlantis使用なら 1回で済む) 小さく済むため plan/apply速度も速い 同環境内でも リソースが別なら 同時に作業可能 〇 × × △ 〇 〇