Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

SUZUKI Masashi

June 22, 2023
Tweet

More Decks by SUZUKI Masashi

Other Decks in Technology

Transcript

  1. © 2022 3-shake Inc. 2 自己紹介 • 所属 ◦ Sreake

    事業部 2022/6入社 ◦ AWS上で動くサービスのインフラ構築 /運用支援が主 • Skills ◦ AWS ▪ ほんのちょっとだけわかる ◦ Google Cloud ▪ 最近あまり触ってない ◦ Terraform ▪ 最近書くコードの9割はHCL すずきまさし (@masasuz)
  2. © 2022 3-shake Inc. 4 tfstateとは • Terraformが管理しているリソースの状態を表す json形式のファイル •

    tfファイルで宣言したリソースと実際のリソースの紐づけを保存している • terraformコマンドを実行する際に tfstateとtfファイルと実際のリソースの状態をそれぞれ参照している • `一般的には`直接変更せずterraformコマンドを通して変更する • `一般的には`ユーザはtfstateを直接見ることはない • Backend Configuration - Configuration Language | Terraform | HashiCorp Developer
  3. © 2022 3-shake Inc. 5 tfstateの課題 本日はこれらの課題について考えていきたいと思う • tfstateの管理場所 ◦

    保存場所はどうする ? • tfstateを管理するリソースの管理 ◦ tfstateを保存するS3バケットはどうやって管理する ? • tfstateの分割単位 ◦ 開発環境と本番環境同じ構成だけどどうやって分ける ? ◦ 管理リソースが増えてくると意味がある単位で分けて見通しを良くしたいよね ?
  4. © 2022 3-shake Inc. 6 tfstateの管理場所をどうするか問題 • local • S3/Google

    Cloud Storage • GitLab • Terraform Cloud 主な保存場所
  5. © 2022 3-shake Inc. 7 tfstateの管理場所をどうするか問題 • デフォルトで同じディレクトリの terraform.tfstateに保存される •

    1人もしくは変更頻度が著しく低い状況など特殊なとき使える • git管理して複数人で使うこともできるが、ロックの仕組みが無いので、衝突が発生しうる • 基本的には複数人で terraformを使用するときは非推奨 local
  6. © 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
  7. © 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
  8. © 2022 3-shake Inc. 17 tfstateをどう分割するか問題 • 環境ごとにディレクトリを分割 • 環境ディレクトリを実行単位とする。

    • 環境の切り替えはディレクトリ移動 • 環境ごとの差分が大きいときに使う • 記述量が多くなる ◦ 共通部分をModule化することである程度 は記述を減らせる ディレクトリ分離パターン
  9. © 2022 3-shake Inc. 18 tfstateをどう分割するか問題 • backend-configオプションとvars-fileオプションを組み合 わせて、環境を切り替える。 •

    ${ENVDIR}/terraform.tfvarsに環境ごとの差分パラメータ を定義 • ${ENVDIR}/backend.tfvarsに環境ごとのtfstate保存先を 定義 • 環境差分が少ないときに使う • 記述量が少なくてすむ • 差分が多くなるとcount, forでの分岐地獄になり読みにくく なる • オプションを毎回付けないといけないのが少し煩雑 backend-configパターン
  10. © 2022 3-shake Inc. 20 tfstateをどう分割するか問題 • workspacesは同じような環境を複製するときに使う。 • シングルテナント環境を量産する場合や開発環境を複数作る場合などに使う。

    • 開発環境、本番環境という形で分割する目的には推奨されてない • 自分自身がworkspacesを実運用で使ったことがないので多くは語れない。 • State: Workspaces | Terraform | HashiCorp Developer workspace(おまけ)
  11. © 2022 3-shake Inc. 21 環境分離以外の分割をどうするか問題 • 管理するリソースが増えると plan/applyの時間が増える。 ◦

    この時間が意外に馬鹿にできない。 ◦ 並列数増やしても限界がある • 記述量も増えて見通しが悪くなる。 • ある程度大きくなったら tfstateを分割して、リソースの管理範囲を分割する。 • ディレクトリもしくはレポジトリを分割することで tfstateを分割する • が、これをどうやって分割するかが自分の中で答えが出ていない
  12. © 2022 3-shake Inc. 23 環境分離以外の分割をどうするか問題 プロバイダー単位で分割する • 例 ◦

    AWS ◦ Datadog アプリケーションリソースとアプリケーションの監視を近いところにおいたほうが見通しがよいのではという観 点もある プロバイダーで分割
  13. © 2022 3-shake Inc. 27 まとめ • すっきりとした結論ではないが、正直正解はない • サービス規模や性質によって変わる

    • 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい ◦ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト