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