SRETT#6_Terraformのtfstateについて考える

Transcript

1. 3-shake SRE Tech Talk #6 Terraformのtfstateを考える
2. © 2022 3-shake Inc. 2 自己紹介 • 所属 ◦ Sreake 事業部 2022/6入社 ◦ AWS上で動くサービスのインフラ構築 /運用支援が主 • Skills ◦ AWS ▪ ほんのちょっとだけわかる ◦ Google Cloud ▪ 最近あまり触ってない ◦ Terraform ▪ 最近書くコードの9割はHCL すずきまさし (@masasuz)
3. 3-shake SRE Tech Talk #6 Terraformのtfstateを考える
4. © 2022 3-shake Inc. 4 tfstateとは • Terraformが管理しているリソースの状態を表す json形式のファイル • tfファイルで宣言したリソースと実際のリソースの紐づけを保存している • terraformコマンドを実行する際に tfstateとtfファイルと実際のリソースの状態をそれぞれ参照している • `一般的には`直接変更せずterraformコマンドを通して変更する • `一般的には`ユーザはtfstateを直接見ることはない • Backend Configuration - Configuration Language | Terraform | HashiCorp Developer
5. © 2022 3-shake Inc. 5 tfstateの課題 本日はこれらの課題について考えていきたいと思う • tfstateの管理場所 ◦ 保存場所はどうする ? • tfstateを管理するリソースの管理 ◦ tfstateを保存するS3バケットはどうやって管理する ? • tfstateの分割単位 ◦ 開発環境と本番環境同じ構成だけどどうやって分ける ? ◦ 管理リソースが増えてくると意味がある単位で分けて見通しを良くしたいよね ?
6. © 2022 3-shake Inc. 6 tfstateの管理場所をどうするか問題 • local • S3/Google Cloud Storage • GitLab • Terraform Cloud 主な保存場所
7. © 2022 3-shake Inc. 7 tfstateの管理場所をどうするか問題 • デフォルトで同じディレクトリの terraform.tfstateに保存される • 1人もしくは変更頻度が著しく低い状況など特殊なとき使える • git管理して複数人で使うこともできるが、ロックの仕組みが無いので、衝突が発生しうる • 基本的には複数人で terraformを使用するときは非推奨 local
8. © 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
9. © 2022 3-shake Inc. 9 tfstateの管理場所をどうするか問題 • tfstateを管理するリソースを管理する必要がない • GitLabを使っている場合親和性が高い • GitLab-managed Terraform state | GitLab GitLab
10. © 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
11. © 2022 3-shake Inc. 11 tfstateを管理するリソースをどう管理する問題 S3/GCSを使う際に考えないといけない問題 GitLabやTerraform Cloudを使う場合には起きない 以下の方法が考えられる • terraform + local state管理 • CloudFormation • aws/gcloudコマンド
12. © 2022 3-shake Inc. 12 tfstateを管理するリソースをどう管理する問題 • terraformを使うので変更管理ができる • stateファイルはgitで管理 • かたくなにterraformでリソース管理したい人向け terraform + local state 管理
13. © 2022 3-shake Inc. 13 tfstateを管理するリソースをどう管理する問題 • AWS限定 • IaCツールを2種類使うそこはかとない気持ち悪さはある CloudFormation
14. © 2022 3-shake Inc. 14 tfstateを管理するリソースをどう管理する問題 • クラウドのCLIコマンドで作成する ◦ スクリプト化してTerraformを管理するレポジトリと一緒に git管理する • 基本的には一度作れば変更はしないのでこれで十分 aws/gcloud コマンド
15. © 2022 3-shake Inc. 15 tfstateをどう分割するか問題 第一に考えるのが環境の分離。この分離の仕方だけ他とは系統が違うので独立して説明する。 一部差分があるだけで、以下のような形でほぼ同じ構成の環境を作ることはよくある。 • 開発環境 • ステージング環境 • 本番環境
16. © 2022 3-shake Inc. 16 tfstateをどう分割するか問題 環境を分離するパターンとして 2つ紹介する • ディレクトリ分離パターン • backend-configパターン 環境分離パターン
17. © 2022 3-shake Inc. 17 tfstateをどう分割するか問題 • 環境ごとにディレクトリを分割 • 環境ディレクトリを実行単位とする。 • 環境の切り替えはディレクトリ移動 • 環境ごとの差分が大きいときに使う • 記述量が多くなる ◦ 共通部分をModule化することである程度 は記述を減らせる ディレクトリ分離パターン
18. © 2022 3-shake Inc. 18 tfstateをどう分割するか問題 • backend-configオプションとvars-fileオプションを組み合 わせて、環境を切り替える。 • ${ENVDIR}/terraform.tfvarsに環境ごとの差分パラメータ を定義 • ${ENVDIR}/backend.tfvarsに環境ごとのtfstate保存先を 定義 • 環境差分が少ないときに使う • 記述量が少なくてすむ • 差分が多くなるとcount, forでの分岐地獄になり読みにくく なる • オプションを毎回付けないといけないのが少し煩雑 backend-configパターン
19. © 2022 3-shake Inc. 19 tfstateをどう分割するか問題 設定ではbackendをs3と指定しておき中身はオプションで指定する。 terraform init –reconfigureして適用する環境を切り替えることができる。 plan/applyはvars-fileを指定して環境ごとのパラメータを差し替える。 backend-configパターン
20. © 2022 3-shake Inc. 20 tfstateをどう分割するか問題 • workspacesは同じような環境を複製するときに使う。 • シングルテナント環境を量産する場合や開発環境を複数作る場合などに使う。 • 開発環境、本番環境という形で分割する目的には推奨されてない • 自分自身がworkspacesを実運用で使ったことがないので多くは語れない。 • State: Workspaces | Terraform | HashiCorp Developer workspace(おまけ)
21. © 2022 3-shake Inc. 21 環境分離以外の分割をどうするか問題 • 管理するリソースが増えると plan/applyの時間が増える。 ◦ この時間が意外に馬鹿にできない。 ◦ 並列数増やしても限界がある • 記述量も増えて見通しが悪くなる。 • ある程度大きくなったら tfstateを分割して、リソースの管理範囲を分割する。 • ディレクトリもしくはレポジトリを分割することで tfstateを分割する • が、これをどうやって分割するかが自分の中で答えが出ていない
22. © 2022 3-shake Inc. 22 環境分離以外の分割をどうするか問題 自分の中でおぼろげに浮かんだ観点をあげる • プロバイダー • 管理権限 • 変更頻度 分割する観点
23. © 2022 3-shake Inc. 23 環境分離以外の分割をどうするか問題 プロバイダー単位で分割する • 例 ◦ AWS ◦ Datadog アプリケーションリソースとアプリケーションの監視を近いところにおいたほうが見通しがよいのではという観 点もある プロバイダーで分割
24. © 2022 3-shake Inc. 24 環境分離以外の分割をどうするか問題 チームの権限で分割する。ディレクトリではなくレポジトリ自体も分割するとよりよい • 例 ◦ ネットワーク ⇒ インフラチーム ◦ アプリケーション ⇒ 開発チーム 管理権限で分割
25. © 2022 3-shake Inc. 25 環境分離以外の分割をどうするか問題 変更をあまりしないリソースを変更が頻繁なリソースと一緒の plan/applyするのは無駄なので変更の頻度で tfstateを分割する • 例 ◦ 変更が少ない ⇒ DB/ネットワーク ◦ 変更が多い ⇒ EC2/ECS 変更頻度で分割
26. © 2022 3-shake Inc. 26 環境分離以外の分割をどうするか問題(補足) terraform_remote_stateを使うことで、参照元の Terraformでoutputした内容を別のTerraformで動 的に利用することができる。 ここで注意したいのは参照の方向性を 1方向にす るようにtfstateを分割し、相互参照しないようにす ること tfstate間のリソース参照
27. © 2022 3-shake Inc. 27 まとめ • すっきりとした結論ではないが、正直正解はない • サービス規模や性質によって変わる • 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい ◦ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト