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
20200617_ビヨンド勉強会_24_Terraformにおけるディレクトリ構造のプ...
Search
nezumisannn
June 17, 2020
Technology
330
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
20200617_ビヨンド勉強会_24_Terraformにおけるディレクトリ構造のプラクティスと記述事例.pdf
nezumisannn
June 17, 2020
More Decks by nezumisannn
See All by nezumisannn
20250930_Conohaウェビナー_生成AI_Terraform_ConoHa_VPSサーバー_セットアップ入門編
nezumisannn
1
37
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
55
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
390
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
110
20240530_ビヨンド勉強会#41_ビヨンドのエンジニア新卒研修における取り組み
nezumisannn
0
140
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
1.4k
リーダーになって1年経過して_取り組んできたことと大事にしている考え方_の裏側_.pdf
nezumisannn
0
92
20211118_GKEにおける高負荷時のPodとWorker_Nodeの挙動について.pdf
nezumisannn
0
180
20211014_Alibaba_Cloud_Container_Service_for_KubernetesにおけるServerless_Kubernetesの概要とManaged_Kubernetesとの違い.pdf
nezumisannn
0
110
Other Decks in Technology
See All in Technology
AIが実装を自走する時代の認知負債との戦い
lycorptech_jp
PRO
2
830
穢れた技術選定について
watany
18
5.7k
そのドキュメント、自動化しませんか?
yuksew
1
330
Amplify Gen2でbackend.tsにCDKを定義する/しない事によるCDKの挙動の違いとユースケース
smt7174
1
440
41歳でAWSが好きすぎてITエンジニアになったおっさんの話
yama3133
0
210
OpenTelemetryにおけるGoのゼロコード・コンパイル時計装について #fukuokago
quiver
0
130
AmplifyHostingConstructからSSRフレームワークのためのホスティング設計を考察する/amplify-hosting-construct
fossamagna
1
260
AI x 開発生産性を取り巻く予算戦略と投資対効果
i35_267
1
330
AIが当たり前の組織で エンジニアはどう育つか
nishihira
1
210
SRE本の知られざる名シーン / The Hidden Gems of Google SRE Book
nari_ex
2
430
発表と総括 / Presentations and Summary
ks91
PRO
0
150
AIとハーネスで育てるトランスコンパイラ / 20260722 Yasushi Katayama
shift_evolve
PRO
0
160
Featured
See All Featured
The B2B funnel & how to create a winning content strategy
katarinadahlin
PRO
1
420
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
510
Amusing Abliteration
ianozsvald
1
230
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.3k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
190
Optimising Largest Contentful Paint
csswizardry
37
3.8k
WENDY [Excerpt]
tessaabrams
11
38k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
130k
Paper Plane
katiecoart
PRO
2
52k
Code Review Best Practice
trishagee
74
20k
The untapped power of vector embeddings
frankvandijk
2
1.8k
Transcript
Terraformにおけるディレクトリ構造の プラクティスと記述事例 ビヨンド勉強会 #24 2020/06/17 株式会社ビヨンド 寺岡 佑樹
自己紹介 resource “my_profile” “nezumisannn” { name = “Yuki.Teraoka” nickname =
“ねずみさん家。” company = “beyond Co., Ltd.” job = “Site Reliability Engineer” twitter = “@yktr_sre” skills = [“Terraform”,”Packer”] }
Terraformにおけるディレクトリ構造 • 皆さんはどうしていますか? • (恐らく) 構築するインフラの環境や組織体制によって異なる • 複数のプラクティスと現実解としての戦略を共有したい
インフラ構成
考えられるプラクティス 1. 1 モジュール + 1 tfstate パターン 2. 1
モジュール (tfファイル分割) + 1 tfstate パターン 3. 1 モジュール (環境分割) + N tfstate パターン 4. N モジュール (環境分割) + N tfstate パターン 5. 1 モジュール (子モジュール) + 1 tfstate パターン 6. N モジュール (子モジュール) + N tfstate パターン
プラクティス評価基準 • DRYなコードを書けるか • オペレーションミスを抑えられるか • 運用フェーズで管理しやすいか
1 モジュール + 1 tfstate パターン • 最小モジュールとして main.tf /
variables.tf / outputs.tf を記述していく ◦ インフラの規模が小さければ最小の労力で記述できる ◦ 規模が大きいとmain.tfが肥大化する + 共通化できない ◦ 間違った環境に反映してしまうミスが起こる可能性が高い ◦ 実際はこの設計で事足りる構成はほぼないと言ってもいい $ tree . ├── main.tf ├── outputs.tf └── variables.tf
1 モジュール(tfファイル分割) + 1 tfstate パターン • 環境・リソースごとにtfファイルを分割する ◦ 1つのtfファイル内の記述はシンプルになるが共通化できない
◦ 間違った環境に反映してしまうミスが起こる可能性が高い ◦ 1 tfstateで全リソースを管理するため 1環境のオペミスが全環境に及ぶ $ tree . ├── dev_vpc.tf ├── outputs.tf ├── prd_vpc.tf ├── mng_vpc.tf └── variables.tf
1 モジュール(環境分割) + N tfstate パターン • WorkSpaceを利用して環境ごとにtfstateを分割する ◦ 複数環境のインフラ構成において最小の労力で記述できる理想とするパターン
◦ 環境ごとにtfstateが分割されているため影響範囲を局所化できる ◦ 特定環境のみ存在するリソースがあるなどの環境差分を許容できず運用が難しい $ tree . ├── vpc.tf ├── outputs.tf ├── terraform.tfstate.d │ ├── dev │ │ └── terraform.tfstate │ ├── mng │ │ └── terraform.tfstate │ └── prd │ └── terraform.tfstate └── variables.tf
N モジュール(環境分割) + N tfstate パターン • WorkSpaceは利用せずディレクトリ自体を分割する ◦ 環境ごとにtfstateが分割されているため影響範囲を局所化できる
◦ 大きな環境差分を許容できるがコード自体が冗長になってしまう ◦ 環境ごとにApplyする必要がありApply漏れが発生する可能性がある % tree . ├── develop │ ├── terraform.tfstate │ ├── variables.tf │ └── vpc.tf ├── manage │ ├── terraform.tfstate │ ├── variables.tf │ └── vpc.tf └── production ├── terraform.tfstate ├── variables.tf └── vpc.tf
1 モジュール(子モジュール) + 1 tfstate パターン • 環境ごとの共通部分を子モジュールとして切り出す ◦ コードの冗長性をなくしながら大きな環境差分も許容できる
◦ 1 tfstateで全リソースを管理するため 1環境のオペミスが全環境に及ぶ ◦ 特定の環境のみ先行して Applyするといったことができない $ tree . ├── dev_vpc.tf ├── mng_vpc.tf ├── modules │ └── vpc │ ├── main.tf │ ├── outputs.tf │ └── variables.tf ├── outouts.tf ├── prd_vpc.tf ├── terraform.tfstate └── variables.tf
N モジュール(子モジュール) + N tfstate パターン • 環境ごとのディレクトリ分割と共通部分の子モジュールのハイブリット ◦ コードの冗長性をなくしながら大きな環境差分も許容できる
◦ tfstate分割による影響範囲の局所化が可能で特定環境のみ Applyも可能 ◦ 子モジュールの切り出し方が難しくしっかり設計しないと運用が破綻する $ tree . ├── develop │ ├── terraform.tfstate │ ├── variables.tf │ └── vpc.tf ├── manage │ ├── terraform.tfstate │ ├── variables.tf │ └── vpc.tf ├── modules │ └── vpc │ ├── main.tf │ ├── outputs.tf │ └── variables.tf └── production ├── terraform.tfstate ├── variables.tf └── vpc.tf • manageとdevelop / productionでsubnetの構成に差分がある • 同じモジュールを読み込んだときに処理を分岐する ◦ manageの場合はpublicのみ作成して他は作成しない ◦ Conditionalを多用することになり難読化する • public / dmz / privateで子モジュール自体を分けてしまう ◦ 読み込むモジュールが増える ◦ コード量が増加して構成が複雑になる
記述事例 • N モジュール (環境分割) + N tfstate パターンを利用 •
環境差分の許容とtfstateの分割を行いたかった • 環境差分を0にするのは現実的に無理 • N モジュール (子モジュール) + N tfstate パターンは運用しきれなかった
• 環境ごとにリソース単位でファイルを分割している • tfstateはもちろん環境ごとに存在している • 環境横断型のリソースは terraform_remote_stateで管理 ◦ aws_vpc_peering_connection ◦
aws_key_pair • 環境ごとにApplyを実行する必要がある ◦ CI/CDツールでオペミスを減らしている ◦ Terraform Cloud • コードが冗長になることは現状は許容している • 子モジュールの設計を頑張りたい ◦ 特定のチームで中央集権的に管理しないと辛そう ◦ 既存コードのリファクタリングが発生する ◦ terraform state mv 地獄 $ tree . ├── develop │ ├── alb.tf │ ├── ec2.tf │ ├── outputs.tf │ ├── provider.tf │ ├── rds.tf │ ├── remotes.tf │ ├── securitygroup.tf │ ├── terraform.tfstate │ ├── terraform.tfstate.backup │ ├── variables.tf │ └── vpc.tf ├── manage │ ├── ec2.tf │ ├── keys │ │ ├── id_rsa │ │ └── id_rsa.pub │ ├── outputs.tf │ ├── provider.tf │ ├── remotes.tf │ ├── securitygroup.tf │ ├── terraform.tfstate │ ├── terraform.tfstate.backup │ ├── variables.tf │ └── vpc.tf └── production ├── alb.tf ├── ec2.tf ├── outputs.tf ├── provider.tf ├── rds.tf ├── remotes.tf ├── securitygroup.tf ├── terraform.tfstate ├── terraform.tfstate.backup ├── variables.tf └── vpc.tf Terraform Cloudを利用したGitOps CI/CDパイプライン https://speakerdeck.com/nezumisannn/20200522-fgdc-terraform-clo udtegitopswoshi-yong-sitaci-cdhaihurainwogou-zhu-suru ブログも書いてます https://beyondjapan.com/blog/2020/04/terraform-cloud-gitops-cicd/
まとめ • 運用していく上ではディレクトリ構造が結構大切 • 実際の案件に合わせてパターンを選択しましょう • 子モジュールでの共通化をもっと頑張りたい
終わり