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
SRETT#6_Terraformのtfstateについて考える
Search
SUZUKI Masashi
June 22, 2023
Technology
2
2.3k
SRETT#6_Terraformのtfstateについて考える
SUZUKI Masashi
June 22, 2023
Tweet
Share
More Decks by SUZUKI Masashi
See All by SUZUKI Masashi
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
370
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
1.8k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.4k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
400
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.4k
2015-12-12-chiba.pm7
masasuzu
0
3.4k
2015-09-17_gotanda.pm6
masasuzu
0
3.5k
2015-07-10-kichijoji.pm4_yurui_template
masasuzu
0
1.3k
2015-06-25_gotanda.pm5
masasuzu
0
1.5k
Other Decks in Technology
See All in Technology
ガチ勢によるPipeCD運用大全〜滑らかなCI/CDを添えて〜 / ai-pipecd-encyclopedia
cyberagentdevelopers
PRO
3
210
AIを駆使したゲーム開発戦略: 新設AI組織の取り組み / sge-ai-strategy
cyberagentdevelopers
PRO
1
130
生成AIとAWS CDKで実現! 自社ブログレビューの効率化
ymae
2
330
visionOSでの空間表現実装とImmersive Video表示について / ai-immersive-visionos
cyberagentdevelopers
PRO
1
110
LeSSに潜む「隠れWF病」とその処方箋
lycorptech_jp
PRO
2
120
プロダクト成長に対応するプラットフォーム戦略:Authleteによる共通認証基盤の移行事例 / Building an authentication platform using Authlete and AWS
kakehashi
1
150
わたしとトラックポイント / TrackPoint tips
masahirokawahara
1
240
30万人が利用するチャットをFirebase Realtime DatabaseからActionCableへ移行する方法
ryosk7
5
350
ガバメントクラウド単独利用方式におけるIaC活用
techniczna
3
270
Forget efficiency – Become more productive without the stress
ufried
0
140
分布で見る効果検証入門 / ai-distributional-effect
cyberagentdevelopers
PRO
4
700
グローバル展開を見据えたサービスにおける機械翻訳プラクティス / dp-ai-translating
cyberagentdevelopers
PRO
1
150
Featured
See All Featured
Being A Developer After 40
akosma
86
590k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Docker and Python
trallard
40
3.1k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
107
49k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Fireside Chat
paigeccino
32
3k
Making the Leap to Tech Lead
cromwellryan
132
8.9k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
37
1.8k
Transcript
3-shake SRE Tech Talk #6 Terraformのtfstateを考える
© 2022 3-shake Inc. 2 自己紹介 • 所属 ◦ Sreake
事業部 2022/6入社 ◦ AWS上で動くサービスのインフラ構築 /運用支援が主 • Skills ◦ AWS ▪ ほんのちょっとだけわかる ◦ Google Cloud ▪ 最近あまり触ってない ◦ Terraform ▪ 最近書くコードの9割はHCL すずきまさし (@masasuz)
3-shake SRE Tech Talk #6 Terraformのtfstateを考える
© 2022 3-shake Inc. 4 tfstateとは • Terraformが管理しているリソースの状態を表す json形式のファイル •
tfファイルで宣言したリソースと実際のリソースの紐づけを保存している • terraformコマンドを実行する際に tfstateとtfファイルと実際のリソースの状態をそれぞれ参照している • `一般的には`直接変更せずterraformコマンドを通して変更する • `一般的には`ユーザはtfstateを直接見ることはない • Backend Configuration - Configuration Language | Terraform | HashiCorp Developer
© 2022 3-shake Inc. 5 tfstateの課題 本日はこれらの課題について考えていきたいと思う • tfstateの管理場所 ◦
保存場所はどうする ? • tfstateを管理するリソースの管理 ◦ tfstateを保存するS3バケットはどうやって管理する ? • tfstateの分割単位 ◦ 開発環境と本番環境同じ構成だけどどうやって分ける ? ◦ 管理リソースが増えてくると意味がある単位で分けて見通しを良くしたいよね ?
© 2022 3-shake Inc. 6 tfstateの管理場所をどうするか問題 • local • S3/Google
Cloud Storage • GitLab • Terraform Cloud 主な保存場所
© 2022 3-shake Inc. 7 tfstateの管理場所をどうするか問題 • デフォルトで同じディレクトリの terraform.tfstateに保存される •
1人もしくは変更頻度が著しく低い状況など特殊なとき使える • git管理して複数人で使うこともできるが、ロックの仕組みが無いので、衝突が発生しうる • 基本的には複数人で terraformを使用するときは非推奨 local
© 2022 3-shake Inc. 8 tfstateの管理場所をどうするか問題 • 標準的(当社比) • S3はDynamoDBを使用してstate
lockを実現する • Google Cloud Storageは単体でstate lockをサポートしている • tfstateの参照権限をクラウド側の権限管理で制御する • Backend Type: s3 | Terraform | HashiCorp Developer • Backend Type: gcs | Terraform | HashiCorp Developer S3/GCS
© 2022 3-shake Inc. 9 tfstateの管理場所をどうするか問題 • tfstateを管理するリソースを管理する必要がない • GitLabを使っている場合親和性が高い
• GitLab-managed Terraform state | GitLab GitLab
© 2022 3-shake Inc. 10 tfstateの管理場所をどうするか問題 • tfstateを管理するリソースを管理する必要がない • 500
Managed Rsourcesまで無料で使える ◦ 以前は5ユーザまでの制限だった ◦ HashiCorp Terraform: Enterprise Pricing, Packages & Features • web上からリソース差分の確認、 applyが可能 • Terraform Cloud | Terraform | HashiCorp Developer Terraform Cloud
© 2022 3-shake Inc. 11 tfstateを管理するリソースをどう管理する問題 S3/GCSを使う際に考えないといけない問題 GitLabやTerraform Cloudを使う場合には起きない 以下の方法が考えられる
• terraform + local state管理 • CloudFormation • aws/gcloudコマンド
© 2022 3-shake Inc. 12 tfstateを管理するリソースをどう管理する問題 • terraformを使うので変更管理ができる • stateファイルはgitで管理
• かたくなにterraformでリソース管理したい人向け terraform + local state 管理
© 2022 3-shake Inc. 13 tfstateを管理するリソースをどう管理する問題 • AWS限定 • IaCツールを2種類使うそこはかとない気持ち悪さはある
CloudFormation
© 2022 3-shake Inc. 14 tfstateを管理するリソースをどう管理する問題 • クラウドのCLIコマンドで作成する ◦ スクリプト化してTerraformを管理するレポジトリと一緒に
git管理する • 基本的には一度作れば変更はしないのでこれで十分 aws/gcloud コマンド
© 2022 3-shake Inc. 15 tfstateをどう分割するか問題 第一に考えるのが環境の分離。この分離の仕方だけ他とは系統が違うので独立して説明する。 一部差分があるだけで、以下のような形でほぼ同じ構成の環境を作ることはよくある。 • 開発環境
• ステージング環境 • 本番環境
© 2022 3-shake Inc. 16 tfstateをどう分割するか問題 環境を分離するパターンとして 2つ紹介する • ディレクトリ分離パターン
• backend-configパターン 環境分離パターン
© 2022 3-shake Inc. 17 tfstateをどう分割するか問題 • 環境ごとにディレクトリを分割 • 環境ディレクトリを実行単位とする。
• 環境の切り替えはディレクトリ移動 • 環境ごとの差分が大きいときに使う • 記述量が多くなる ◦ 共通部分をModule化することである程度 は記述を減らせる ディレクトリ分離パターン
© 2022 3-shake Inc. 18 tfstateをどう分割するか問題 • backend-configオプションとvars-fileオプションを組み合 わせて、環境を切り替える。 •
${ENVDIR}/terraform.tfvarsに環境ごとの差分パラメータ を定義 • ${ENVDIR}/backend.tfvarsに環境ごとのtfstate保存先を 定義 • 環境差分が少ないときに使う • 記述量が少なくてすむ • 差分が多くなるとcount, forでの分岐地獄になり読みにくく なる • オプションを毎回付けないといけないのが少し煩雑 backend-configパターン
© 2022 3-shake Inc. 19 tfstateをどう分割するか問題 設定ではbackendをs3と指定しておき中身はオプションで指定する。 terraform init –reconfigureして適用する環境を切り替えることができる。
plan/applyはvars-fileを指定して環境ごとのパラメータを差し替える。 backend-configパターン
© 2022 3-shake Inc. 20 tfstateをどう分割するか問題 • workspacesは同じような環境を複製するときに使う。 • シングルテナント環境を量産する場合や開発環境を複数作る場合などに使う。
• 開発環境、本番環境という形で分割する目的には推奨されてない • 自分自身がworkspacesを実運用で使ったことがないので多くは語れない。 • State: Workspaces | Terraform | HashiCorp Developer workspace(おまけ)
© 2022 3-shake Inc. 21 環境分離以外の分割をどうするか問題 • 管理するリソースが増えると plan/applyの時間が増える。 ◦
この時間が意外に馬鹿にできない。 ◦ 並列数増やしても限界がある • 記述量も増えて見通しが悪くなる。 • ある程度大きくなったら tfstateを分割して、リソースの管理範囲を分割する。 • ディレクトリもしくはレポジトリを分割することで tfstateを分割する • が、これをどうやって分割するかが自分の中で答えが出ていない
© 2022 3-shake Inc. 22 環境分離以外の分割をどうするか問題 自分の中でおぼろげに浮かんだ観点をあげる • プロバイダー •
管理権限 • 変更頻度 分割する観点
© 2022 3-shake Inc. 23 環境分離以外の分割をどうするか問題 プロバイダー単位で分割する • 例 ◦
AWS ◦ Datadog アプリケーションリソースとアプリケーションの監視を近いところにおいたほうが見通しがよいのではという観 点もある プロバイダーで分割
© 2022 3-shake Inc. 24 環境分離以外の分割をどうするか問題 チームの権限で分割する。ディレクトリではなくレポジトリ自体も分割するとよりよい • 例 ◦
ネットワーク ⇒ インフラチーム ◦ アプリケーション ⇒ 開発チーム 管理権限で分割
© 2022 3-shake Inc. 25 環境分離以外の分割をどうするか問題 変更をあまりしないリソースを変更が頻繁なリソースと一緒の plan/applyするのは無駄なので変更の頻度で tfstateを分割する •
例 ◦ 変更が少ない ⇒ DB/ネットワーク ◦ 変更が多い ⇒ EC2/ECS 変更頻度で分割
© 2022 3-shake Inc. 26 環境分離以外の分割をどうするか問題(補足) terraform_remote_stateを使うことで、参照元の Terraformでoutputした内容を別のTerraformで動 的に利用することができる。 ここで注意したいのは参照の方向性を
1方向にす るようにtfstateを分割し、相互参照しないようにす ること tfstate間のリソース参照
© 2022 3-shake Inc. 27 まとめ • すっきりとした結論ではないが、正直正解はない • サービス規模や性質によって変わる
• 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい ◦ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト