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

2021年9月30日AWS Dev Day Online Japanの登壇資料
動画はこちら: https://www.youtube.com/watch?v=0IQ4IScqQws

Transcript

1. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   「それ、どこに出しても恥ずかしくない
   Terraformコードになってるか？」
   Yuki Yoshida
   Amazon Web Services Japan
   AppDevConsultant Professional Services
   I - 2
   

   View Slide

2. Yuki Yoshida(吉⽥ 祐樹)
   AppDev Consultant@Professional Services
   Amazon Web Service Japan K.K.
   得意分野︓
   アプリケーションのモダナイズ、チームのアジャイル化
   ⼤規模なインフラコード化と⾃動化
   好きなAWSサービス︓
   AWS Amplify AWS AppSync
   

   View Slide

3. 想定聴講者
   • Terraformを用いてチーム開発したことがある
   • AWSのサービス（IAM、Amazon DynamoDB、Amazon Simple Storage
   Serviceなど）を利用したことがある
   ゴール
   • 本番環境でTerraformを用いたチーム開発手法を知る
   • 実案件でTerraformの実装方式を選択することが出来るようになる
   今日話さないこと
   • Terraform Cloud、Terraform Enterprise、env0などを使った自動化
   • Terragrunt
   本セッションについて
   

   View Slide

4. 父「最近なにしてる？」
   ワイ「インフラのコード化とかのコーチングしてるよ、Terraformが多いかな」
   父「なるほどな。TerraformもGAしてバージョン1になったし波を感じるな」
   ワイ「そうね、でも最近TFファイルが増えすぎて不注意の事故起こしちゃってさ」
   父「おぉ、そりゃ大変だ。ファイルが多すぎるならモジュール化したらどうだ？」
   ワイ「モジュール化？」
   父「お、おう。さすがに公式のドキュメントは読んでからやってるよな？」
   ワイ「公式のドキュメント？」
   父「えーっと、じゃー実践Terraform*1とか読んだのか？」
   ワイ「実践Terraform？」
   父「お前さ・・・」
   父「それ、どこに出しても恥ずかしくないTerraformコードになってるか？」
   ある日の父との会話
   *1:実践Terraform AWSにおけるシステム設計とベストプラクティス(ISBN-10: 4844378139)
   

   View Slide

5. Terraform得意な人はもうそれだけで尊い
   • 「コンパイラがわかるコードは誰にでも書ける。
   すぐれたプログラマは人間にとってわかりやすいコードを書く」*1
   • 人間にとってわかりやすいコードを書くためにはポリモーフィズムなどソフトウェア開発の知識が必要
   • Terraform単体の知識はそこまで必要じゃない
   • Terraform単体の知識よりも、Terraform Provider、そしてProvider（例えばAWSサービス）の知識が必要
   （必要な知識を比率化すると、1:3:6くらい）
   • Terraform × AWSの確かな経験を持っているというのは、それだけで非常に貴重な存在（大事にしてあげて）
   • Terraformに黄金パターンは存在しない
   • 書籍やネットに情報はたくさんあるしコミュニティも活発で事例はたくさんある
   • 情報がたくさんあり「Terraform × AWS」において本当に必要な情報が見つけにくい
   • 公式Docや「実践Terraform*2」などを熟読して実践してる人が少ない
   • ということで
   様々な現場で学んだTerraform × AWSのプラクティスを紹介します
   *1:リファクタリング(第2版): 既存のコードを安全に改善する Martin Fowler(ISBN-10: 4274224546)
   *2:実践Terraform AWSにおけるシステム設計とベストプラクティス(ISBN-10: 4844378139)
   

   View Slide

6. • Terraformの概要
   • State管理のベストプラクティス
   • ファイル構成の基本
   • ファイル構成のプラクティス
   • まとめ
   Agenda
   

   View Slide

7. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   Terraform概要
   

   View Slide

8. インフラを安全かつ効率的に管理するためのツール
   Terraformとは
   • 宣言的
   「これから何が起きるのか」
   • HCL(HashiCorp Configuration Language)
   

   View Slide

9. コード例
   Provider
   変数
   resource
   data source
   

   View Slide

10. 01: terraform fmt
    02: terraform init
    03: terraform plan
    04: terraform apply
    05: terraform state mv
    06: terraform import
    07: terraform state show
    08: terraform state pull
    09: terraform validate
    10: terraform console
    .
    .
    .
    99: terraform destroy
    よく使うTerraformコマンドランキング
    毎秒使う
    毎日使う
    フォーマッター（エディタが自動でやる）
    初期化
    適用したらどうなるかを事前確認
    適用
    Stateのリソース名変更や引越し（リファクタ）
    既存リソースをTerraform管理化にいれる
    stateの部分的な参照
    stateファイルの中身を表示
    構成の有効性チェック
    Terraform式をプロンプトで試す
    .
    .
    .
    お別れの呪文
    

    View Slide

11. Terraform実行時のデータの流れ
    AWS Lambda Amazon DynamoDB
    Amazon
    API Gateway
    Real World
    AWS Lambda Amazon DynamoDB
    Amazon
    API Gateway
    State
    ③read
    terraform.tfstate
    ⑤write
    

    View Slide

12. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    State管理ベストプラクティス
    1. Stateファイルは必ずリモート管理
    2. Stateファイルをロックすることでデプロイの衝突からインフラを守る
    3. Stateファイルは環境毎に分ける
    

    View Slide

13. State管理ベストプラクティス1
    S T A T E フ ァ イ ル は 必 ず リ モ ー ト 管 理
    Remote State
    Local State
    必ずリモート管理（≠git）
    S3を利用する
    • 以下S3のおすすめ設定
    • Stateを配置するS3バケット自体を
    同一Terraformで作成しない
    terraform.tfstate
    terraform.tfstate
    terraform.tfstate
    terraform.tfstate
    

    View Slide

14. State管理ベストプラクティス2-1
    S T A T E フ ァ イ ル を ロ ッ ク す る こ と で デ プ ロ イ の 衝 突 か ら イ ン フ ラ を 守 る
    S3 S3
    DynamoDB
    State
    Lockなし
    同時にapplyやimportをす
    るとリソースとStateファイ
    ルでズレが発生し、予期せ
    ぬリソース削除が発生する
    可能性があります！
    terraform.tfstate terraform.tfstate
    State
    Lockあり
    S3でStateファイルを管理しつつ、
    DynamoDBでStateをロックする
    ことでズレや予期せぬリソース削除
    から守る
    

    View Slide

15. State管理ベストプラクティス2-2
    S T A T E フ ァ イ ル を ロ ッ ク す る こ と で デ プ ロ イ の 衝 突 か ら イ ン フ ラ を 守 る
    S3
    S3
    DynamoDB
    • 個人開発やPoC
    • チーム開発、本番環境
    • 誰か or CIツールがTerraform実行
    中、他の人 or システムが
    terraformを実行できなくなる
    State
    Lockなし
    State
    Lockあり
    

    View Slide

16. State管理ベストプラクティス3
    S T A T E フ ァ イ ル は 環 境 毎 に 分 け る
    terraform.tfstate
    Dev
    PreProd
    Prod
    terraform.tfstate
    Dev
    PreProd
    Prod
    terraform.tfstate
    terraform.tfstate
    • 「開発環境のstate rmしたは
    ずが誤って本番環境で作業して
    しまいました」などから守る
    

    View Slide

17. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    ファイル構成の基本
    

    View Slide

18. ファイル構成説明のアプリ紹介
    • Amazon EventBridge
    • AWS Lambda
    • IAM Role
    • Amazon CloudWatchのロググループ
    Amazon EventBridge AWS Lambda Amazon CloudWatch
    

    View Slide

19. 【前提条件】最低限必要な記述のサンプル
    全てを一つのファイル
    に記述することも可能
    実行順序が自動で決まる
    依存関係を明示的に指定
    Terraformは最後に実行されたバージョン以
    上のTerraformでないと実行出来ない。
    そのためCIサーバよりも新しいTerraformを
    誰かが実行してしまうとCIサーバ側のバー
    ジョンを上げる手術が必要になる。
    こういった事故を防ぐためにもTerraformの
    バージョンを固定させる。
    Providerバージョンも固定しないと、開発
    環境と本番環境でApply時に明示的に指定し
    ていないパラメータがズレてしまう可能性
    あり。
    Terraform 0.14系から.terraform.lock.hclで
    もProviderのLockが出来るがまだあまり
    本番事例は出ていない（ように見える）
    

    View Slide

20. Amazon EventBridge AWS Lambda
    各コンポーネント毎に1ファイルずつ作成する
    Amazon CloudWatch
    ※本題とズレるのでコードは省略します🙇
    「どんなコンポーネントがTerraformで管理されているのか」は見やすいですよね？
    このまま開発を続けていくとどうなるでしょう？
    Amazon EventBridge AWS Lambda Amazon CloudWatch
    

    View Slide

21. モノリス構成はいつかこうなる
    このようなモノリスなファイル構成を
    本スライドでは「小規模パターン」と呼びます
    • 「ここに全部載ってる」というのは俯瞰しやすい
    • 「本番環境だけコレが必要」
    variable
    に渡す
    • tfvarsファイルを全環境分用意
    全環境分セット
    • 複数環境の場合、State管理設定
    --backend-config
    

    View Slide

22. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    ファイル構成プラクティス
    

    View Slide

23. Terraformモジュールとは
    envs modulesで役割を分ける
    【モノリス】
    【モジュール化後】
    

    View Slide

24. モジュール化するとどうなるか
    環境毎にディレクトリ作成
    モジュール呼び出し
    この方法の特徴
    同じ内容のファイルが環境の数だけ生まれる
    モジュールの変更が全環境に影響を与えてしまう課題がある
    【中規模パターン】
    

    View Slide

25. モジュールを別リポジトリで管理する 【大規模パターン】
    別リポジトリの
    モジュールを呼び出す
    この方法の特徴
    課題を解決
    Terraform × AWSの経験が必要
    initに多くの時間がかかる
    バージョン管理が複雑
    モジュール細分化 envsの分割
    envsの記法の違い（上段: 中規模パターン、下段:大規模パターン）
    

    View Slide

26. 小規模パターン（モノリス） 中規模パターン（別ディレクトリ） 大規模パターン（別リポジトリ）
    パターン一覧のまとめ
    環境が別れない、大きくならないこ
    とがはっきりしているのであれば小
    規模パターンで始めてみても良い
    将来的には大規模になるかもしれな
    い、くらいであれば中規模パターン
    で始めて、後から大規模パターンへ
    移行していく、というのをチームで
    話してみましょう
    中規模と大規模のハイブリッド
    （一部相対パス、一部別リポジトリ）
    構成もよく見ます
    Terraform × AWSの経験があり、ア
    ーキテクチャ設計、ディレクトリ設
    計がチームで合意できれば,
    いきなりここから始めてもOK ここから更にenvs自体を分けたり、
    envsの中を細かくディレクトリを分け
    る、など進化させる
    

    View Slide

27. 人間にとって分かりやすくするために
    Standard Module Structure*1
    環境 × 複数のコンポーネントで分ける
    自動化必須
    ディレクトリ単位のブランチ名を利用するのがオススメ
    *1: https://www.terraform.io/docs/language/modules/develop/structure.html
    

    View Slide

28. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    まとめ
    

    View Slide

29. まとめ
    • Terraform人財を大事に
    リモート管理
    ロック
    最低でも環境毎
    まず中規模パターンから
    • 人間にとって分かりやすいコード
    Standard Module Structure
    

    View Slide

30. Thank you!
    © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    Yuki Yoshida
    Amazon Web Services Japan
    AppDevConsultant Professional Services
    

    View Slide