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

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

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

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

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)

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

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

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

コード例 Provider 変数 resource data source

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式をプロンプトで試す . . . お別れの呪文

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

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

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

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をロックする ことでズレや予期せぬリソース削除 から守る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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