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.5k
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
380
2023-12-18 SRETT8 Terraform使いがPulumiに入門する
masasuzu
0
1.9k
2023-12-01 吉祥寺.pm ベストプラクティスと組織とIaC
masasuzu
1
1.5k
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.6k
Other Decks in Technology
See All in Technology
The Rise of LLMOps
asei
9
1.9k
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
220
プロダクト活用度で見えた真実 ホリゾンタルSaaSでの顧客解像度の高め方
tadaken3
0
260
TypeScriptの次なる大進化なるか!? 条件型を返り値とする関数の型推論
uhyo
2
1.8k
iOS/Androidで同じUI体験をネ イティブで作成する際に気をつ けたい落とし穴
fumiyasac0921
1
110
Mastering Quickfix
daisuzu
1
340
SDNという名のデータプレーンプログラミングの歴史
ebiken
PRO
2
190
Exadata Database Service on Dedicated Infrastructure(ExaDB-D) UI スクリーン・キャプチャ集
oracle4engineer
PRO
2
3.2k
Amazon Forecast亡き今、我々がマネージドサービスに頼らず時系列予測を実行する方法
sadynitro
0
150
初心者向けAWS Securityの勉強会mini Security-JAWSを9ヶ月ぐらい実施してきての近況
cmusudakeisuke
0
150
あなたの知らない Function.prototype.toString() の世界
mizdra
PRO
4
1.2k
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
440
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Scaling GitHub
holman
458
140k
Designing on Purpose - Digital PM Summit 2013
jponch
115
7k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
For a Future-Friendly Web
brad_frost
175
9.4k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
Building Your Own Lightsaber
phodgson
103
6.1k
Six Lessons from altMBA
skipperchong
27
3.5k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
The Cult of Friendly URLs
andyhume
78
6k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
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 まとめ • すっきりとした結論ではないが、正直正解はない • サービス規模や性質によって変わる
• 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい ◦ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト