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
54
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
【FinOps】データドリブンな意思決定を目指して
z63d
1
390
現場のトークンマネジメント
dak2
1
190
GitHub Copilot 最新アップデート – 「一歩先」の実践活用術
moulongzhang
5
1.9k
Zenoh on Zephyr on LiteX
takasehideki
2
110
気軽に使える"情報のハブ"としてのNotion活用 〜フロー情報の集積点 と、 Claude Code × Notion AI〜
syucream
1
200
AIチャット検索改善の3週間
kworkdev
PRO
2
190
BPaaSで進むAIオペレーションの現在地 AI実装が効く領域とスケーラビリティの選定と実装
kentarofujii
0
200
MUSUBI 田中裕一『AIと共に行う「しごとのリデザイン」- スモールバックオフィス編』AI Ops Lab #4
musubi
0
320
AI-DLCを “そのまま導入しなかった”話 ~組織に合わせてアジャストした 私たちの実践共有~
hiroramos4
PRO
1
430
Agile and AI Redmine Japan 2026
hiranabe
4
490
Kiro Ambassador を目指す話
k_adachi_01
0
130
When Platform Engineering Meets GenAI
sucitw
0
180
Featured
See All Featured
KATA
mclloyd
PRO
35
15k
The SEO Collaboration Effect
kristinabergwall1
1
490
Crafting Experiences
bethany
1
190
The #1 spot is gone: here's how to win anyway
tamaranovitovic
3
1.1k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.8k
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.6k
Large-scale JavaScript Application Architecture
addyosmani
515
110k
The Cult of Friendly URLs
andyhume
79
6.9k
Designing for Timeless Needs
cassininazir
1
260
Music & Morning Musume
bryan
47
7.2k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
370
Odyssey Design
rkendrick25
PRO
2
710
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/
まとめ • 運用していく上ではディレクトリ構造が結構大切 • 実際の案件に合わせてパターンを選択しましょう • 子モジュールでの共通化をもっと頑張りたい
終わり