継続的な改善のためのmodulesの適切な分割単位 - NIFTY Tech Talk #23

イベント
これから始めるTerraform超入門！ NIFTY Tech Talk #23
https://nifty.connpass.com/event/337326/

登壇者
ニフティ株式会社
島田 大徳

Transcript

1. 継続的な改善のための modulesの適切な分割単位 ニフティ株式会社 Hironori Shimada 1
2. 島田 大徳 ニフティ株式会社 システム統括部 基幹システムグループ サービスインフラチーム Terraform歴 3年 フロントエンド勉強中 ポケモンカードゲーム やってます 2
3. インフラストラクチャは最後まで残る ライフタイムが長いと生じる問題 気軽に作り直せない アプリケーションが役目を終えても残り続ける 担当者が変わるたび維持が難しくなっていく → 理解しやすく、適切な単位で影響範囲を区切りたい 3
4. "適切な分割単位"は難しい → 完璧な正解は現状ありません(多分) 4
5. 組織とAWSアカウント チームは払い出された awsアカウントを管理している (運用チームは基本ない) たいてい1システムにつき 2~6アカウントを申請 dev, stg, prod 機密情報レベル2種 組織変更などでシステムが 別のチームに移ることもある 5
6. 例えば # 開発環境.tf resource "aws_s3_bucket" "this" { bucket = "unique-dev" } resource "bastion" "this" {} # 本番環境.tf resource "aws_s3_bucket" "this" { bucket = "unique-prod" } # resource "bastion" "this" {} aws_s3_bucket.this のbucketはグローバルに一意 bastion.this は開発環境のみに必要 6
7. パターン 1. workspaceを使う 2. tfbackend、tfvarsを使う 3. ディレクトリ+modulesを使う 7
8. workspaceのパターン 1つのアカウントに複数の環境を 作る場合に主に利用する アカウントが分かれている場合 backendも分けたい 他2つとは若干用途が違う 8
9. tfbackend、tfvarsで分けるパターン . ├── backend.tf ├── dev.tfbackend ├── dev.tfvars ├── main.tf ├── prod.tfbackend ├── prod.tfvars ├── providers.tf ├── terraform.tf └── variables.tf moduleを自由に使うことができ重複が減る 基本同じリソースが作成されることが保証できる ファイル数が少なくて済む 9
10. ディレクトリ+modulesで分けるパターン . ├── dev │ ├── backend.tf │ ├── main.tf │ ├── providers.tf │ ├── service1.tf │ └── terraform.tf └── modules └── service1 ├── main.tf ├── outputs.tf └── variables.tf より柔軟 reconfigureしなくていい (root moduleが分かれる) 10
11. 適切な分割単位 プロダクト、システムなど ユーザストーリーのように 縦方向に管理したい リソース(VPC、networkなど) style guideでも vpc, queue, function のように例が書いてある 実際には影響範囲の 管理が難しい 11
12. よく採用する構造について . ├── dev │ ├── api.tf │ ├── github.tf │ ├── main.tf │ └── web.tf ├── modules │ ├── api │ │ └── main.tf │ ├── github │ │ ├── api.tf │ │ └── main.tf │ └── web │ └── main.tf └── prod 柔軟にリソースを追加できる 12
13. 運用上の課題 重複が多い 汎用のmoduleを作り始めると見分けがつかなくなる HCP Terraform Private Registryなど使うと良さそう 複数のmoduleにまたがるリソースの管理 他のmoduleのoutputを使う場合など 複数のシステム+複数サブシステム+サブサブシステム moduleの名前が長くなるため気をつける必要がある 例えば modules/service1_api とするか、 modules/service1/api.tf とするか 13
14. 結論 認知負荷を下げ、継続的に改善可能にする tfファイルが肥大化したら分割する import, mv, rm を活用する DRYを追求するより、分割単位を意識する Terraform Stacksに期待 HCP Terraformでpublic beta提供 ただしコンポーネントの分割についてはこれまで通り 適切な単位を考える必要がありそう 14