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を管理している話
Search
kanga333
October 02, 2019
Technology
4
3.6k
個々のアプリのリポジトリでTerraformを管理している話
2019/10/02(水) 19:00〜
Terraform meetup tokyo#2 LT
https://terraform-jp.connpass.com/event/142041/
kanga333
October 02, 2019
Tweet
Share
More Decks by kanga333
See All by kanga333
Athenaを使ったバッチ処理のTIPS
kanga333
0
830
docker_and_make
kanga333
1
390
CoreOS Container Linuxで始めるベアメタルKubernetes
kanga333
3
8.9k
10分で詰め込むHadoop
kanga333
0
150
ORCについて調べた
kanga333
0
220
burrow_monitoring
kanga333
0
830
j2hの紹介
kanga333
0
6.2k
Other Decks in Technology
See All in Technology
Uncle Bobの「プロフェッショナリズムへの期待」から学ぶプロの覚悟
nakasho
2
110
業務効率化をさらに加速させる、ノーコードツールとStep Functionsのハイブリッド化
smt7174
2
130
Performance Insights 廃止から Database Insights 利用へ/transition-from-performance-insights-to-database-insights
emiki
0
190
E2Eテスト設計_自動化のリアル___Playwrightでの実践とMCPの試み__AIによるテスト観点作成_.pdf
findy_eventslides
2
600
M5製品で作るポン置きセルラー対応カメラ
sayacom
0
170
綺麗なデータマートをつくろう_データ整備を前向きに考える会 / Let's create clean data mart
brainpadpr
3
380
速習AGENTS.md:5分で精度を上げる "3ブロック" テンプレ
ismk
1
550
そのWAFのブロック、どう活かす? サービスを守るための実践的多層防御と思考法 / WAF blocks defense decision
kaminashi
0
150
衛星画像超解像化によって実現する2D, 3D空間情報の即時生成と“AI as a Service”/ Real-time generation spatial data enabled_by satellite image super-resolution
lehupa
0
140
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
1.2k
スタートアップにおけるこれからの「データ整備」
shomaekawa
2
350
実装で解き明かす並行処理の歴史
zozotech
PRO
1
690
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
45
2.5k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
Leading Effective Engineering Teams in the AI Era
addyosmani
1
23
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
GraphQLの誤解/rethinking-graphql
sonatard
73
11k
Context Engineering - Making Every Token Count
addyosmani
5
230
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
37
2.6k
Why You Should Never Use an ORM
jnunemaker
PRO
59
9.6k
How GitHub (no longer) Works
holman
315
140k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
個々のアプリのリポジトリでTerraformを管理している話 kagawa shoichi (@kanga333) 2019/10/2 Terraform meetup tokyo#2 LT
⾃⼰紹介.tfvars twitter = "@kanga333" company = "Speee,Inc." job = "Infra
Engineer" team = "UZOU(AdTech)" 好きなTerraformの機能はfor_each 今の会社/チームに参加して半年くらい
はじめに UZOUでは各アプリケーションリポジトリ毎に terraform ディレクトリを切って Terraform設定を分散して管理しています 例えばアドサーバ/クローラー/管理画⾯/バッチなど機能別で別れています ⼀⽅で⾃分の今までの経験で多かった構成はインフラ/SREチームがオーナーの統⼀的な Terraformリポジトリという構成でした 後者に慣れ親しんでいたので前者の構成に最初は抵抗があったんですが実際やってみると 良さがわかったので簡単にご紹介します
普通?のTerraform管理⽅法 普通の基準は主観です hoge-terraform みたいな共通リポジトリに設定を集約 SRE/インフラチームに類する⼈たちがオーナ moduleを作ってある程度Dryにする アプリケーション軸か使⽤するサービス軸でmain.tfは分ける
UZOUでのTerrform管理⽅法 各アプリケーション毎にTerraform設定を分散して管理 例えばアドサーバのコードのリポジトリと⼀緒に以下のtfリソースを管理 ELB/AutoScaling/DatadogMonitor/etc... アプリケーションを実⾏するために必要なインフラリソースほぼ全て main.tfは各アプリ毎で1つ ワークスペースのような形で各環境間でtfvarsだけ変えている リポジトリをまたいだ共通モジュールは今の所ない あんまりDryにはしていない 歴史的にフルスタックエンジニアxN⼈のチームで運⽤されていたので⾃然とこうなった
良かったこと アプリケーションが使⽤するインフラリソースがわかりやすい Terraform変更の影響範囲が明確 Terraformのアップグレードを必要に応じてできるし簡単 Plan早い アプリの変更とインフラの変更を⼀緒にレビューできる
良くないこと コピペベースなので同じような修正が何度も必要 何度も terraform 0.12upgrade が必要 書き⽅にムラがでやすい CI/CDが⼤変 現状JenkinsジョブをポチってPlan/Applyする感じなのでいい感じにしたい... インフラ構成全体の把握に時間がかかる
⼯夫してる点 AWSのタグを使って管理しているリポジトリを明確にする これどこで管理してるんだっけ?を防⽌ 全体像を把握する際はAWS側の画⾯やサービスを駆使する - TrustedAdvisor/AWSConfig/GuardDuty/CostExplorer
今の構成でも上⼿くいっている理由 チーム状況とフィットしている みんなTerraform設定を書く インフラチーム的なものは無い そもそもチームの⼈数は5⼈ システム規模はそれなりに⼤きいけどもめちゃくちゃデカイ訳ではない ⼤体インスタンス60 ~ 70台くらい
とはいえ今後このままで⾏くのか? インフラ的なメンバー増えたら統⼀リポジトリに寄せるのはあり得る その場合はstate mv祭りだなぁ... マイクロサービス的に各サービス毎のチームができたら今の構成でも良い気もする 必要になったら考える
⽉並みな結論 個々のチーム状況にあったリポジトリ設計が⼤事 コンウェイまじコンウェイ チーム状況が変われば抵抗のあった構成でも案外フィットするケースもある 将来チーム状況が変化した際にどう対応できるか考えておく