Trraformについて概要まとめ

課題感

各種AWSサービス（ES2, ECS, RDSなど）の設定など開発の際に必要になるインフラリソースの設定、管理が各場所に散らばっている。

• 設定の見直しやバージョンアップの管理がしずらい、手動設定のミスが発生する可能性がある

• リソースの依存関係の管理がしづらい。

• テストやステージングのための同一環境の構築が面倒

• インフラの専門知識がないと環境構築ができない

解決策

IaC (Infrastructure as code)
＝＞ インフラ情報をテキストファイル管理 × Gitにてバージョン管理

• 設定の見直しやバージョンアップの管理がしずらい、手動設定のミスが発生する可能性がある

  • コードで一括ビルド、停止、Gitでバージョン管理ができる

• リソースの依存関係の管理がしづらい。

  • 一か所でテキストに必要な情報を記載のみを記載しているので依存関係が追いやすい

  • Trraform側で依存関係を自動判断してくれる

    • TFファイルの実行順序も自動判断してくれる

• テストやステージングのための同一環境の構築が面倒

  • コードをコピペするだけでOK

• インフラの専門知識がないと環境構築ができない

  • 最初のビルドや停止など簡単な項目だけであれば、各種インフラリソースの深い理解が必要なくなる。初期のハードルが低くなる。

Terraformの特徴

「Puppet」「Chef」「Ansible」などに比べてクラウド環境の構築に強み
AWSに限るのであればAWS CloudFormationが類似機能

どんな風に記載するか、何ができるかの例）

Terraformの課題

• 同一ファイル内にあるTFファイルのみを実行する

  • TFファイルが増えてきてもディレクトリ管理ができない

    • ネーミングルールでサフィックスつけたりするのが一般的

    • ディレクトリを無理やり分けることもできる

      • 同じリソース管理ファイルが複数生まれる可能性あり

      • 実行処理量が少なくなる

      • 環境が分離することで意図しない範囲に影響することなくなる

      • 同じリソースに変更加えたい場合対応漏れ発生する可能性あり

スライドではベストプラクティスはなく
開発規模ごとにどう分けるかを示していた。

ベストプラクティスの提案例
https://dev.classmethod.jp/articles/directory-layout-bestpractice-in-terraform/
モジュールという機能を使って各環境で変わる設定値を variables.tf で管理する。

参考

「それ、どこに出しても恥ずかしくないTerraformコードになってるか？」