個々のアプリのリポジトリでTerraformを管理している話

2019/10/02（水） 19:00〜
Terraform meetup tokyo#2 LT
https://terraform-jp.connpass.com/event/142041/

Transcript

1. 個々のアプリのリポジトリでTerraformを管理している話 kagawa shoichi (@kanga333) 2019/10/2 Terraform meetup tokyo#2 LT
2. ⾃⼰紹介.tfvars twitter = "@kanga333" company = "Speee,Inc." job = "Infra Engineer" team = "UZOU(AdTech)" 好きなTerraformの機能はfor_each 今の会社/チームに参加して半年くらい
3. はじめに UZOUでは各アプリケーションリポジトリ毎に terraform ディレクトリを切って Terraform設定を分散して管理しています 例えばアドサーバ/クローラー/管理画⾯/バッチなど機能別で別れています ⼀⽅で⾃分の今までの経験で多かった構成はインフラ/SREチームがオーナーの統⼀的な Terraformリポジトリという構成でした 後者に慣れ親しんでいたので前者の構成に最初は抵抗があったんですが実際やってみると 良さがわかったので簡単にご紹介します
4. 普通？のTerraform管理⽅法 普通の基準は主観です hoge-terraform みたいな共通リポジトリに設定を集約 SRE/インフラチームに類する⼈たちがオーナ moduleを作ってある程度Dryにする アプリケーション軸か使⽤するサービス軸でmain.tfは分ける
5. UZOUでのTerrform管理⽅法 各アプリケーション毎にTerraform設定を分散して管理 例えばアドサーバのコードのリポジトリと⼀緒に以下のtfリソースを管理 ELB/AutoScaling/DatadogMonitor/etc... アプリケーションを実⾏するために必要なインフラリソースほぼ全て main.tfは各アプリ毎で１つ ワークスペースのような形で各環境間でtfvarsだけ変えている リポジトリをまたいだ共通モジュールは今の所ない あんまりDryにはしていない 歴史的にフルスタックエンジニアxN⼈のチームで運⽤されていたので⾃然とこうなった
6. 良かったこと アプリケーションが使⽤するインフラリソースがわかりやすい Terraform変更の影響範囲が明確 Terraformのアップグレードを必要に応じてできるし簡単 Plan早い アプリの変更とインフラの変更を⼀緒にレビューできる
7. 良くないこと コピペベースなので同じような修正が何度も必要 何度も terraform 0.12upgrade が必要 書き⽅にムラがでやすい CI/CDが⼤変 現状JenkinsジョブをポチってPlan/Applyする感じなのでいい感じにしたい... インフラ構成全体の把握に時間がかかる
8. ⼯夫してる点 AWSのタグを使って管理しているリポジトリを明確にする これどこで管理してるんだっけ？を防⽌ 全体像を把握する際はAWS側の画⾯やサービスを駆使する - TrustedAdvisor/AWSConfig/GuardDuty/CostExplorer
9. 今の構成でも上⼿くいっている理由 チーム状況とフィットしている みんなTerraform設定を書く インフラチーム的なものは無い そもそもチームの⼈数は5⼈ システム規模はそれなりに⼤きいけどもめちゃくちゃデカイ訳ではない ⼤体インスタンス60 ~ 70台くらい
10. とはいえ今後このままで⾏くのか？ インフラ的なメンバー増えたら統⼀リポジトリに寄せるのはあり得る その場合はstate mv祭りだなぁ... マイクロサービス的に各サービス毎のチームができたら今の構成でも良い気もする 必要になったら考える
11. ⽉並みな結論 個々のチーム状況にあったリポジトリ設計が⼤事 コンウェイまじコンウェイ チーム状況が変われば抵抗のあった構成でも案外フィットするケースもある 将来チーム状況が変化した際にどう対応できるか考えておく