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
3.3k
SRETT#6_Terraformのtfstateについて考える
SUZUKI Masashi
June 22, 2023
Tweet
Share
More Decks by SUZUKI Masashi
See All by SUZUKI Masashi
2025-01-31 吉祥寺.pm 37 初めての海外カンファレンス
masasuzu
0
480
2025-01-24-SRETT11-OpenTofuについてそろそろ調べてみるか
masasuzu
0
620
2024-03-29 SRETT9 Cloud SQLの可用性について
masasuzu
0
450
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
2.3k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.6k
SRETT#4黒い画面をもっと効率的に(使って自動化の時間を捻出)
masasuzu
2
440
2022-04-12 吉祥寺.pm 29
masasuzu
0
1.4k
2015-12-12-chiba.pm7
masasuzu
0
3.5k
2015-09-17_gotanda.pm6
masasuzu
0
3.6k
Other Decks in Technology
See All in Technology
システムとの会話から生まれる先手のDevOps
kakehashi
PRO
0
290
DETR手法の変遷と最新動向(CVPR2025)
tenten0727
2
1.4k
C++26アップデート 2025-03
faithandbrave
0
480
Terraform Cloudで始めるおひとりさまOrganizationsのすゝめ
handy
2
180
Spring Bootで実装とインフラをこれでもかと分離するための試み
shintanimoto
7
850
Dynamic Reteaming And Self Organization
miholovesq
3
550
Would you THINK such a demonstration interesting ?
shumpei3
1
220
PagerDuty×ポストモーテムで築く障害対応文化/Building a culture of incident response with PagerDuty and postmortems
aeonpeople
1
320
SnowflakeとDatabricks両方でRAGを構築してみた
kameitomohiro
1
420
地味にいろいろあった! 2025春のAmazon Bedrockアップデートおさらい
minorun365
PRO
1
270
Рекомендации с нуля: как мы в Lamoda превратили главную страницу в ключевую точку входа для персонализированного шоппинга. Данил Комаров, Data Scientist, Lamoda Tech
lamodatech
0
750
持続可能なドキュメント運用のリアル: 1年間の成果とこれから
akitok_
1
190
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
104
19k
StorybookのUI Testing Handbookを読んだ
zakiyama
29
5.6k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
The Cult of Friendly URLs
andyhume
78
6.3k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.2k
BBQ
matthewcrist
88
9.6k
Rails Girls Zürich Keynote
gr2m
94
13k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.1k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
5
520
GraphQLとの向き合い方2022年版
quramy
46
14k
Building Adaptive Systems
keathley
41
2.5k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
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 まとめ • すっきりとした結論ではないが、正直正解はない • サービス規模や性質によって変わる
• 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい ◦ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト