Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
「それ、どこに出しても恥ずかしくないTerraformコードになってるか?」 / Ter...
Search
yuukiyo
September 30, 2021
Technology
44
23k
「それ、どこに出しても恥ずかしくないTerraformコードになってるか?」 / Terraform AWS Best Practices
2021年9月30日AWS Dev Day Online Japanの登壇資料
動画はこちら:
https://www.youtube.com/watch?v=0IQ4IScqQws
yuukiyo
September 30, 2021
Tweet
Share
More Decks by yuukiyo
See All by yuukiyo
アジャイル開発は本当に必要なのか、何を解決するのか
yuukiyo
15
14k
Git の最新アップデートから考える開発手法の潮流
yuukiyo
12
16k
痒いところに手が届くAmplify
yuukiyo
1
6k
Dockerイメージのバージョン管理は GitのCommitHashよりもTreeでやると良い
yuukiyo
5
5.3k
Other Decks in Technology
See All in Technology
ISUCONに強くなるかもしれない日々の過ごしかた/Findy ISUCON 2024-11-14
fujiwara3
8
870
【Pycon mini 東海 2024】Google Colaboratoryで試すVLM
kazuhitotakahashi
2
520
安心してください、日本語使えますよ―Ubuntu日本語Remix提供休止に寄せて― 2024-11-17
nobutomurata
1
1k
Terraform未経験の御様に対してどの ように導⼊を進めていったか
tkikuchi
2
450
10XにおけるData Contractの導入について: Data Contract事例共有会
10xinc
6
650
Why App Signing Matters for Your Android Apps - Android Bangkok Conference 2024
akexorcist
0
130
OS 標準のデザインシステムを超えて - より柔軟な Flutter テーマ管理 | FlutterKaigi 2024
ronnnnn
0
160
SREが投資するAIOps ~ペアーズにおけるLLM for Developerへの取り組み~
takumiogawa
1
360
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
410
rootlessコンテナのすゝめ - 研究室サーバーでもできる安全なコンテナ管理
kitsuya0828
3
390
SSMRunbook作成の勘所_20241120
koichiotomo
3
150
マルチプロダクトな開発組織で 「開発生産性」に向き合うために試みたこと / Improving Multi-Product Dev Productivity
sugamasao
1
310
Featured
See All Featured
Building a Modern Day E-commerce SEO Strategy
aleyda
38
6.9k
Building Better People: How to give real-time feedback that sticks.
wjessup
364
19k
Building Flexible Design Systems
yeseniaperezcruz
327
38k
Docker and Python
trallard
40
3.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
Scaling GitHub
holman
458
140k
The Pragmatic Product Professional
lauravandoore
31
6.3k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
How STYLIGHT went responsive
nonsquared
95
5.2k
It's Worth the Effort
3n
183
27k
Statistics for Hackers
jakevdp
796
220k
Six Lessons from altMBA
skipperchong
27
3.5k
Transcript
© 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