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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
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
38
20250723_Conohaウェビナー_高騰する海外クラウド費用を劇的カット_サーバーコスト最適化のポイント解説と成功事例のご紹介.pdf
nezumisannn
0
57
20241204_ビヨンド勉強会_44_AWS_Service_Catalogを利用したIaCのテンプレート化とTerraformによるデプロイ.pdf
nezumisannn
0
400
20240828_ビヨンド勉強会_42_EKS_on_FargateでWebサービスを公開するために覚えておきたいこと.pdf
nezumisannn
0
110
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
110
Other Decks in Technology
See All in Technology
Sansan Engineering Unit 紹介資料
sansan33
PRO
1
4.9k
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
170
モダンフロントエンド 開発研修
recruitengineers
PRO
4
590
Redmine 7.0 新機能・機能強化解説(OSC2026京都ダイジェスト版)
vividtone
1
240
オートロックマンションなのに、各部屋は施錠なし!? 攻撃者が組織内ネットワークで大暴れする理由 / The Front Door Is Locked, but the Rooms Are Wide Open: Why Attackers Move Freely Inside Enterprise Networks
nttcom
1
1.6k
【CEDEC2026】グラフィックスエンジニアのためのニューラルシェーディング入門
cygames
PRO
0
130
AIコーディングの次。コードレビューと理解負荷を解消して組織の開発生産性を高める
moongift
PRO
2
2.4k
猫付きpingコマンドを自作
uyuki234
0
150
Issue設計から始める仕様駆動開発 / 20260731 Mizuki Hirata
shift_evolve
PRO
1
150
Breaking the Seal: Static Deobfuscation of Compiled V8 JavaScript Bytecode Malware
hshrzd
0
700
ガバメント AI 源内を地方自治体は活用できるのか可能性と課題、期待について
takeda_h
1
390
システム思考で問題に対処する
yussak
0
220
Featured
See All Featured
Noah Learner - AI + Me: how we built a GSC Bulk Export data pipeline
techseoconnect
PRO
0
350
Hiding What from Whom? A Critical Review of the History of Programming languages for Music
tomoyanonymous
3
1.1k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
380
Thoughts on Productivity
jonyablonski
76
5.3k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
660
sira's awesome portfolio website redesign presentation
elsirapls
0
320
My Coaching Mixtape
mlcsv
0
210
From Legacy to Launchpad: Building Startup-Ready Communities
dugsong
0
290
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Faster Mobile Websites
deanohume
310
32k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
The browser strikes back
jonoalderson
0
1.5k
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/
まとめ • 運用していく上ではディレクトリ構造が結構大切 • 実際の案件に合わせてパターンを選択しましょう • 子モジュールでの共通化をもっと頑張りたい
終わり