$30 off During Our Annual Pro Sale. View Details »

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. 3-shake SRE Tech Talk #6
    Terraformのtfstateを考える

    View Slide

  2. © 2022 3-shake Inc. 2
    自己紹介
    ● 所属
    ○ Sreake 事業部 2022/6入社
    ○ AWS上で動くサービスのインフラ構築 /運用支援が主
    ● Skills
    ○ AWS
    ■ ほんのちょっとだけわかる
    ○ Google Cloud
    ■ 最近あまり触ってない
    ○ Terraform
    ■ 最近書くコードの9割はHCL
    すずきまさし (@masasuz)

    View Slide

  3. 3-shake SRE Tech Talk #6
    Terraformのtfstateを考える

    View Slide

  4. © 2022 3-shake Inc. 4
    tfstateとは
    ● Terraformが管理しているリソースの状態を表す json形式のファイル
    ● tfファイルで宣言したリソースと実際のリソースの紐づけを保存している
    ● terraformコマンドを実行する際に tfstateとtfファイルと実際のリソースの状態をそれぞれ参照している
    ● `一般的には`直接変更せずterraformコマンドを通して変更する
    ● `一般的には`ユーザはtfstateを直接見ることはない
    ● Backend Configuration - Configuration Language | Terraform | HashiCorp Developer

    View Slide

  5. © 2022 3-shake Inc. 5
    tfstateの課題
    本日はこれらの課題について考えていきたいと思う
    ● tfstateの管理場所
    ○ 保存場所はどうする ?
    ● tfstateを管理するリソースの管理
    ○ tfstateを保存するS3バケットはどうやって管理する ?
    ● tfstateの分割単位
    ○ 開発環境と本番環境同じ構成だけどどうやって分ける ?
    ○ 管理リソースが増えてくると意味がある単位で分けて見通しを良くしたいよね ?

    View Slide

  6. © 2022 3-shake Inc. 6
    tfstateの管理場所をどうするか問題
    ● local
    ● S3/Google Cloud Storage
    ● GitLab
    ● Terraform Cloud
    主な保存場所

    View Slide

  7. © 2022 3-shake Inc. 7
    tfstateの管理場所をどうするか問題
    ● デフォルトで同じディレクトリの terraform.tfstateに保存される
    ● 1人もしくは変更頻度が著しく低い状況など特殊なとき使える
    ● git管理して複数人で使うこともできるが、ロックの仕組みが無いので、衝突が発生しうる
    ● 基本的には複数人で terraformを使用するときは非推奨
    local

    View Slide

  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

    View Slide

  9. © 2022 3-shake Inc. 9
    tfstateの管理場所をどうするか問題
    ● tfstateを管理するリソースを管理する必要がない
    ● GitLabを使っている場合親和性が高い
    ● GitLab-managed Terraform state | GitLab
    GitLab

    View Slide

  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

    View Slide

  11. © 2022 3-shake Inc. 11
    tfstateを管理するリソースをどう管理する問題
    S3/GCSを使う際に考えないといけない問題
    GitLabやTerraform Cloudを使う場合には起きない
    以下の方法が考えられる
    ● terraform + local state管理
    ● CloudFormation
    ● aws/gcloudコマンド

    View Slide

  12. © 2022 3-shake Inc. 12
    tfstateを管理するリソースをどう管理する問題
    ● terraformを使うので変更管理ができる
    ● stateファイルはgitで管理
    ● かたくなにterraformでリソース管理したい人向け
    terraform + local state 管理

    View Slide

  13. © 2022 3-shake Inc. 13
    tfstateを管理するリソースをどう管理する問題
    ● AWS限定
    ● IaCツールを2種類使うそこはかとない気持ち悪さはある
    CloudFormation

    View Slide

  14. © 2022 3-shake Inc. 14
    tfstateを管理するリソースをどう管理する問題
    ● クラウドのCLIコマンドで作成する
    ○ スクリプト化してTerraformを管理するレポジトリと一緒に git管理する
    ● 基本的には一度作れば変更はしないのでこれで十分
    aws/gcloud コマンド

    View Slide

  15. © 2022 3-shake Inc. 15
    tfstateをどう分割するか問題
    第一に考えるのが環境の分離。この分離の仕方だけ他とは系統が違うので独立して説明する。
    一部差分があるだけで、以下のような形でほぼ同じ構成の環境を作ることはよくある。
    ● 開発環境
    ● ステージング環境
    ● 本番環境

    View Slide

  16. © 2022 3-shake Inc. 16
    tfstateをどう分割するか問題
    環境を分離するパターンとして 2つ紹介する
    ● ディレクトリ分離パターン
    ● backend-configパターン
    環境分離パターン

    View Slide

  17. © 2022 3-shake Inc. 17
    tfstateをどう分割するか問題
    ● 環境ごとにディレクトリを分割
    ● 環境ディレクトリを実行単位とする。
    ● 環境の切り替えはディレクトリ移動
    ● 環境ごとの差分が大きいときに使う
    ● 記述量が多くなる
    ○ 共通部分をModule化することである程度
    は記述を減らせる
    ディレクトリ分離パターン

    View Slide

  18. © 2022 3-shake Inc. 18
    tfstateをどう分割するか問題
    ● backend-configオプションとvars-fileオプションを組み合
    わせて、環境を切り替える。
    ● ${ENVDIR}/terraform.tfvarsに環境ごとの差分パラメータ
    を定義
    ● ${ENVDIR}/backend.tfvarsに環境ごとのtfstate保存先を
    定義
    ● 環境差分が少ないときに使う
    ● 記述量が少なくてすむ
    ● 差分が多くなるとcount, forでの分岐地獄になり読みにくく
    なる
    ● オプションを毎回付けないといけないのが少し煩雑
    backend-configパターン

    View Slide

  19. © 2022 3-shake Inc. 19
    tfstateをどう分割するか問題
    設定ではbackendをs3と指定しておき中身はオプションで指定する。
    terraform init –reconfigureして適用する環境を切り替えることができる。
    plan/applyはvars-fileを指定して環境ごとのパラメータを差し替える。
    backend-configパターン

    View Slide

  20. © 2022 3-shake Inc. 20
    tfstateをどう分割するか問題
    ● workspacesは同じような環境を複製するときに使う。
    ● シングルテナント環境を量産する場合や開発環境を複数作る場合などに使う。
    ● 開発環境、本番環境という形で分割する目的には推奨されてない
    ● 自分自身がworkspacesを実運用で使ったことがないので多くは語れない。
    ● State: Workspaces | Terraform | HashiCorp Developer
    workspace(おまけ)

    View Slide

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

    View Slide

  22. © 2022 3-shake Inc. 22
    環境分離以外の分割をどうするか問題
    自分の中でおぼろげに浮かんだ観点をあげる
    ● プロバイダー
    ● 管理権限
    ● 変更頻度
    分割する観点

    View Slide

  23. © 2022 3-shake Inc. 23
    環境分離以外の分割をどうするか問題
    プロバイダー単位で分割する
    ● 例
    ○ AWS
    ○ Datadog
    アプリケーションリソースとアプリケーションの監視を近いところにおいたほうが見通しがよいのではという観
    点もある
    プロバイダーで分割

    View Slide

  24. © 2022 3-shake Inc. 24
    環境分離以外の分割をどうするか問題
    チームの権限で分割する。ディレクトリではなくレポジトリ自体も分割するとよりよい
    ● 例
    ○ ネットワーク ⇒ インフラチーム
    ○ アプリケーション ⇒ 開発チーム
    管理権限で分割

    View Slide

  25. © 2022 3-shake Inc. 25
    環境分離以外の分割をどうするか問題
    変更をあまりしないリソースを変更が頻繁なリソースと一緒の plan/applyするのは無駄なので変更の頻度で
    tfstateを分割する
    ● 例
    ○ 変更が少ない ⇒ DB/ネットワーク
    ○ 変更が多い ⇒ EC2/ECS
    変更頻度で分割

    View Slide

  26. © 2022 3-shake Inc. 26
    環境分離以外の分割をどうするか問題(補足)
    terraform_remote_stateを使うことで、参照元の
    Terraformでoutputした内容を別のTerraformで動
    的に利用することができる。
    ここで注意したいのは参照の方向性を 1方向にす
    るようにtfstateを分割し、相互参照しないようにす
    ること
    tfstate間のリソース参照

    View Slide

  27. © 2022 3-shake Inc. 27
    まとめ
    ● すっきりとした結論ではないが、正直正解はない
    ● サービス規模や性質によって変わる
    ● 選んだ技術要素に関しては選定理由を説明できるようにはしておきたい
    ○ 可能であれば選ばなかった技術に関しても検討内容を残しておくとベスト

    View Slide