90

.tfstateファイルをGitにコミットするかどうかという質問に少し戸惑っています。Terraformのドキュメントには次のように記載されています。

また、Terraform はデフォルトでいくつかの状態をterraform.tfstateファイルに入れます。この状態ファイルは非常に重要です。さまざまなリソース メタデータを実際のリソース ID にマップして、Terraform が何を管理しているかを認識できるようにします。このファイルは保存して、Terraform を実行する可能性のあるすべての人に配布する必要があります。通常はそれほど大きくないため、単純にバージョン管理に入れることをお勧めします。

一方、 Terraformの状態を使用する場合のベスト プラクティスに関する受け入れられ、支持された回答は次のとおりです。

Terraform 構成を使用して、さまざまなインフラストラクチャに多くのボックスをプロビジョニングすることができ、それぞれが異なる状態を持つ可能性があります。複数の人が実行することもできるため、この状態は中央の場所 (S3 など) にある必要がありますが、gitではありません。

（私ではなく、元の著者による強調）

誰が正しいのですか? もしそうなら、なぜですか?

4

4 に答える 4

68

.tfstateファイルを Gitに保存しない理由はいくつかあります。

  1. 実行後に変更をコミットしてプッシュするのを忘れる可能性が高いterraform applyため、チームメイトは古いファイルを持つことになり.tfstateます。また、これらの状態ファイルをロックしないと、2 人のチーム メンバーが同じファイルで同時に Terraform を実行すると.tfstate、互いの変更を上書きする可能性があります。a) Terraform リモート状態.tfstateを使用して S3 バケットにファイルを保存することで、両方の問題を解決できます。これは、実行するたびにファイルを自動的にプッシュ/プルします。b) terragruntなどのツールを使用して、ファイルをロックします。.tfstateterraform apply.tfstate
  2. .tfstateファイルにはシークレットが含まれている場合があります。たとえば、aws_db_instanceリソースを使用する場合、データベースのパスワードを指定する必要があり、Terraform はそれを平文で.tfstateファイルに保存します。これは、Terraform に代わってそもそも悪い習慣であり、暗号化されていないシークレットをバージョン管理に保存すると、さらに悪化するだけです。少なくとも.tfstateファイルを S3 に保存する場合は、保管時の暗号化を有効にし (SSL は動作中の暗号化を提供します)、IAM ポリシーを構成してアクセスできるユーザーを制限できます。これは理想とはかけ離れており、この問題について議論している未解決の問題が修正されるかどうかを確認する必要があります。

詳細については、Terraform の状態を管理する方法とTerraform: Up & Runningを確認してください。

于 2016-08-03T16:23:24.857 に答える
59

TL;DR:

重要！ソース管理に保存すると、潜在的に機密性の高いデータが公開され、古いバージョンの状態に対して Terraform を実行するリスクが生じる可能性があります。やらないでください。

Terraform は、ソース管理に状態を保存することを推奨しなくなりました。あなたの「良い」オプションは、リモートまたはローカルです。

リモート状態は、ローカルとソース管理への保存の両方に比べて大きな利点をもたらします。これらの詳細は以下のとおりです。

元の答え:

Yevgeniyの答えは良いものです。Terraform がドキュメントを次のように更新したため、この問題はやや議論の余地がなくなりました。

また、Terraform は、既定でいくつかの状態を terraform.tfstate ファイルに入れます。この状態ファイルは非常に重要です。さまざまなリソース メタデータを実際のリソース ID にマップして、Terraform が何を管理しているかを認識できるようにします。このファイルは保存して、Terraform を実行する可能性のあるすべての人に配布する必要があります。通常、Terraform を使用する場合は、リモート状態をセットアップすることをお勧めします。これは、状態ファイルに保存されている潜在的なシークレットがバージョン管理にチェックインされないことを意味します

そのため、確立されたベスト プラクティスと公式の推奨事項の間に矛盾はなくなりました。

2019-05-17 更新

ドキュメントの最新バージョンでは、これは次のように変更されています。

... この状態はデフォルトで「terraform.tfstate」という名前のローカル ファイルに保存されますが、リモートで保存することもできるため、チーム環境でより適切に機能します。...

アドバイスが、状態を保存するための推奨される方法であるソース管理に戻ることはないと思います。

上記のドキュメントの引用にもかかわらず、リモート状態はソロ開発者として依然として有益です

リモート状態では、単独の開発者は次のことができます。

  • 複数のデバイスから Terraform コードを操作/実行する
  • 選択したバックエンドに応じて、簡単にバックアップし、状態ファイルを失わないように保護します
  • 出力を介してアーキテクチャのセクションを分離する
  • 選択したバックエンドに応じて、保存時に状態ファイルを自動的に暗号化します
于 2017-01-05T10:18:59.413 に答える
11

これはおそらく好みの問題ですが、git (またはその他のソース管理) は状態ファイルの保存に特に適したオプションではないと思います。状態ファイルは、コンパイル済みのバイナリのように記述しているコードの出力であるためです。最小化された JS または CSS にコンパイルされた LESS。

その上、コード内で実際に変更されたものではなく、実行中のものへの出力として、状態ファイル内で非常に急速に変更される可能性があり、全体がやや厄介になります。

ただし、別のラップトップ/マシンで開発している場合は、これらの状態ファイルをリモートのチーム メンバーや他のデバイスと共有する何らかの方法が必要です。また、Terraform は状態ファイルを使用して状態ファイルを使用して管理しているものを解決し、状態ファイルのつま先を踏まないようにするため、これらを保存してバックアップする方法が必要になります。その他のツーリング。

S3 はおそらく、現時点でそれらを配置できる最適な場所だと思います。それはほとんど無料で、耐久性は可用性と同様に優れています。リモート状態リソースを使用する Terraform では、非常に優れたネイティブ サポートがあります。そしておそらく最も重要なのは、S3 バケットを作成するだけで開始できることです。まず Terraform を使用せずにConsulまたはetcdクラスターを構築する必要がある (そうしないと、それらを作成するための状態をどこに保存するかという鶏が先か卵が先かという問題が発生します)。これらの製品のいずれかを使用するつもりであっても、少し面倒です。

明らかに、OpenStack を使用している場合は、Swiftが適切な代替手段になるはずです (私は使用していませんが)。私は Hashicorp のAtlasも使用したことがありませんが、そのサービスに喜んでお金を払うなら、それも同様に役立つかもしれません。

于 2016-07-21T06:59:08.990 に答える