Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
20200617_ビヨンド勉強会_24_Terraformにおけるディレクトリ構造のプ...
Search
nezumisannn
June 17, 2020
Technology
340
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
39
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
58
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
420
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
120
20240530_ビヨンド勉強会#41_ビヨンドのエンジニア新卒研修における取り組み
nezumisannn
0
140
20230511_AWSにおけるコンテナサービスの選択とIaC実装例.pdf
nezumisannn
0
1.5k
リーダーになって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
120
Other Decks in Technology
See All in Technology
絵ではじめるKubernetesセキュリティ
aoi1
4
680
現場で役立つ技術負債の効果的な返済方法
masuda220
PRO
9
4.6k
AIを活用するために決めた "やらないこと" - 価値に注目する / Not betting on AI
soudai
PRO
3
560
The Knowledge Spine: A Machine-Executable Ontology for Governed Marketing Activation
vananth22
0
110
AIエージェントの自己改善をどう設計するか / How to Design Self-Improvement for AI Agents
22mi
25
16k
バイブコーディング時代のWebアプリ開発入門~Cloud Runで学ぶセキュアなビルドとデプロイ
waiwai2111
1
140
2026-09-18 gotanda.sre Terraformで複数環境作ったり、複数Stateに分割したりそれとTerragrunt / Terraform multi envs and multi states
masasuzu
3
590
ソフトウェアDNAとクラウドエージェントのススメ
cloudace
0
120
Deployment の 先にある AI Agent 基盤 - kagent vNext、Agent Substrate、Hermes から読み解く Agent Runtime の現在地 / k8s-matsuri-2-ai-agent-platform-amsy810
masayaaoyama
4
670
安心して変更できるWebフロントエンドの作り方
pirosikick
5
2.8k
新機種発売前に見直そう!端末移行で再ログインが要るアプリ・要らないアプリは何が違うのか 〜シームレスに再開できる設計と実装〜
zozotech
PRO
0
210
Minecraft JavaのMODをSwiftで作る
1mash0
0
180
Featured
See All Featured
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Mobile First: as difficult as doing things right
swwweet
225
10k
Collaborative Software Design: How to facilitate domain modelling decisions
baasie
1
320
Paper Plane
katiecoart
PRO
4
53k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
How GitHub (no longer) Works
holman
316
150k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
580
Ecommerce SEO: The Keys for Success Now & Beyond - #SERPConf2024
aleyda
1
2.2k
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
360
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
500
Reality Check: Gamification 10 Years Later
codingconduct
0
2.3k
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/
まとめ • 運用していく上ではディレクトリ構造が結構大切 • 実際の案件に合わせてパターンを選択しましょう • 子モジュールでの共通化をもっと頑張りたい
終わり