.tfstateファイルをGitにコミットする必要がありますか？
コミットするかどうかの質問には少し困惑しています.tfstateファイルをGitに送信するかどうか。 Terraform documentation 状態：
Terraformは、
terraform.tfstateファイルはデフォルトです。この状態ファイルは非常に重要です。さまざまなリソースメタデータを実際のリソースIDにマップして、Terraformが管理対象を把握できるようにします。このファイルを保存し、Terraformを実行する可能性のある人に配布する必要があります。通常は大きすぎないので、単にバージョン管理に入れることをお勧めします。
一方、今では、 Terraformを使用する際のベストプラクティス の受け入れられ、賛成された回答は次のように述べています。
Terraform configを使用して、さまざまなインフラストラクチャに多くのボックスをプロビジョニングできます。各ボックスは異なる状態を持つことができます。複数の人が実行することもできるため、この状態は中央の場所（S3など）にある必要がありますが、notgitです。
（私ではなく、元の著者によるエンファシス）
誰が正しいのですか？
TL; DR：
重要！ソース管理に保存すると、 潜在的に機密データ および古いバージョンの状態に対してTerraformを実行するリスク。しないでください。
Terraformは、ソース管理に状態を保存することを推奨しなくなりました。 「良い」オプションはリモートまたはローカルです。
リモート状態は、ローカルおよびソース管理での保存の両方に対して大きな利点をもたらします。これらの詳細は以下にあります。
元の答え：
Yevgeniyの答えは良いものです。 Terraformはドキュメントを次のように更新しているため、この問題は今やや議論の余地がありません。
Terraformはまた、デフォルトでいくつかの状態をterraform.tfstateファイルに入れます。この状態ファイルは非常に重要です。さまざまなリソースメタデータを実際のリソースIDにマップして、Terraformが管理対象を把握できるようにします。このファイルを保存し、Terraformを実行する可能性のある人に配布する必要があります。通常、Terraformを使用する場合は、リモート状態をセットアップすることをお勧めします。 これは、状態ファイルに保存されている潜在的な秘密はバージョン管理にチェックインされないことを意味します
そのため、確立されたベストプラクティスと公式の推奨事項の間に意見の相違はなくなりました。
2019-05-17を更新
ドキュメントの最新バージョン では、これは次のように変更されました。
...この状態は、デフォルトで「terraform.tfstate」という名前のローカルファイルに保存されますが、リモートで保存することもでき、チーム環境でより適切に機能します。 ...
アドバイスが、状態を保存するための好ましい方法であるソース管理に戻るとは思わない。
上記のドキュメントの引用にもかかわらず、リモート開発者はソロ開発者としてまだ有益です
リモート状態により、ソロ開発者は次のことができます。
- 複数のデバイスからTerraformコードを操作/実行する
- 選択したバックエンドに応じて、状態ファイルを簡単にバックアップおよび保護します
- outputs でアーキテクチャのセクションを分離します
- 保存されている状態ファイルを自動的に暗号化する 、選択したバックエンドに応じて
.tfstateファイルをGitに保存しない理由はいくつかあります。
terraform applyの実行後に変更をコミットしてプッシュすることを忘れてしまう可能性が高いため、チームメイトは.tfstateファイルが古くなっています。また、これらの状態ファイルをロックせずに、2人のチームメンバーが同じ.tfstateファイルでTerraformを同時に実行すると、互いの変更を上書きできます。両方の問題を解決するには、a） Terraform remote state を使用して.tfstateファイルをS3バケットに保存します。これにより、.tfstateファイルが毎回自動的にプッシュ/プルされますterraform applyを実行し、b） terragrunt などのツールを使用して.tfstateファイルのロックを提供します。.tfstateファイルには秘密が含まれている場合があります。たとえば、 aws_db_instance リソースを使用する場合、データベースパスワードを指定する必要があり、Terraformはそれをプレーンテキストで.tfstateファイルに保存します。これはTerraformに代わって悪い習慣であり、暗号化されていないシークレットをバージョン管理に保存すると悪化するだけです。少なくとも.tfstateファイルをS3に保存する場合、静止時の暗号化を有効にし（SSLは移動中に暗号化を提供します）、誰がアクセスできるかを制限するためにIAMポリシーを構成できます。理想からはほど遠いので、この問題について議論する 未解決の問題 が修正されるかどうかを確認する必要があります。
詳細については、 Terraformの状態を管理する方法 およびTerraform：Up＆Runningを確認してください。
これはおそらく好みに落ちるでしょうが、git（またはその他のソース管理）は、コンパイルされたバイナリのように書いているコードの出力であるため、状態ファイルの保存には特に良いオプションではないと思いますCSSにコンパイルされた最小化されたJSまたはLESS。
その上、状態ファイルでは、実行中の物への出力として物事が非常に急速に変化する可能性があり、コード内で実際に物事が変更されるため、物事全体がかなり扱いにくくなります。
ただし、異なるラップトップ/マシンで開発している場合、これらの状態ファイルをリモートチームメンバーや他のデバイスと共有する何らかの方法が必要です。また、Terraformが状態ファイルを使用して管理しているものを解決するために状態ファイルを失うと、いくつかの本当の痛みを感じるので、これらを保存およびバックアップする方法が必要になります。他のツール。
S3はおそらく今すぐに置くことができる最高の場所だと思います。それはほとんど無料で、可用性は可用性と同様に優れています。Terraformでは リモート状態 リソースを使用して、ネイティブサポートが非常に優れています。そしておそらく最も重要なことは、開始するにはS3バケットを作成するだけです。 Consul または etcd クラスターをTerraformなしで最初に構築する必要があります（そうでなければ、それらを作成するための状態をどこに保存するかという鶏と卵の問題があります）。これらの製品のいずれかを使用する場合でも、痛み。
OpenStackを使用している場合は、明らかに Swift が適切な代替手段になります（使用していませんが）。また、私はHashicorpの Atlas を使用していませんが、そのサービスの支払いに満足している場合は、同様に有用かもしれません。
terraform.tfstateをGitではなく他の手段で共有することには利点があると思います。
例：S3、Dropboxなど（バージョニングがオンの場合）
その後、以前のインフラストラクチャ状態にロールバックできます。
たとえば、リポジトリをコミットBからロールバックし、コミットAに戻します。terraform.tfstateが変更されていない場合-terraformは、コミットBで追加したすべての内容をロールバックする方法を考えます。簡単に。
terraform.tfstateもコミットAにロールバックされた場合-terraformは、terraform.tfstateが必要な構成と同期しており、インフラストラクチャにロールバックを適用しないと見なします。