Soll ich .tfstate-Dateien an Git übergeben?

Ich bin ein bisschen verwirrt über die Frage, ob ich .tfstateDateien auf Git übertragen soll oder nicht. In der Terraform-Dokumentation heißt es:

Terraform fügt der terraform.tfstateDatei standardmäßig auch einen Status hinzu . Diese Statusdatei ist äußerst wichtig. Es ordnet verschiedene Ressourcenmetadaten tatsächlichen Ressourcen-IDs zu, damit Terraform weiß, was es verwaltet. Diese Datei muss gespeichert und an alle verteilt werden, die Terraform ausführen können. Wir empfehlen, es einfach in die Versionskontrolle zu stellen, da es im Allgemeinen nicht zu groß ist.

Auf der anderen Seite heißt es in der akzeptierten und positiv bewerteten Antwort zu Best Practices bei der Verwendung von Terraform :

Die Terraform-Konfiguration kann verwendet werden, um viele Boxen in unterschiedlichen Infrastrukturen bereitzustellen, von denen jede einen anderen Status haben kann. Da dieser Status auch von mehreren Personen ausgeführt werden kann, sollte er sich an einem zentralen Ort (wie S3) befinden, jedoch nicht an Git.

(Hervorhebung durch den ursprünglichen Autor, nicht durch mich)

Wer hat Recht und wenn ja, warum?

TL; DR:

Wichtig! Das Speichern in der Quellcodeverwaltung kann potenziell sensible Daten offenlegen und das Risiko eingehen, Terraform gegen eine alte Version des Status auszuführen. Tu es nicht.

Terraform empfiehlt nicht mehr, den Status in der Quellcodeverwaltung zu speichern. Ihre "guten" Optionen sind remote oder lokal.

Der Remote-Status bietet erhebliche Vorteile gegenüber der lokalen und der Speicherung in der Quellcodeverwaltung. Details dazu finden Sie weiter unten.

Ursprüngliche Antwort:

Jewgenijes Antwort ist gut. Das Problem ist jetzt etwas weniger kontrovers, da Terraform seine Dokumente aktualisiert hat, um Folgendes anzuzeigen:

Terraform fügt der Datei terraform.tfstate standardmäßig auch einen Status hinzu. Diese Statusdatei ist äußerst wichtig. Es ordnet verschiedene Ressourcenmetadaten tatsächlichen Ressourcen-IDs zu, damit Terraform weiß, was es verwaltet. Diese Datei muss gespeichert und an alle verteilt werden, die Terraform ausführen können. Es wird allgemein empfohlen, den Remote-Status einzurichten, wenn Sie mit Terraform arbeiten. Dies bedeutet, dass potenzielle Geheimnisse, die in der Statusdatei gespeichert sind, nicht in die Versionskontrolle eingecheckt werden

Es besteht also keine Meinungsverschiedenheit mehr zwischen etablierten Best Practices und offiziellen Empfehlungen.

Update 2019-05-17

In der neuesten Version der Dokumente wurde Folgendes geändert:

... Dieser Status wird standardmäßig in einer lokalen Datei mit dem Namen "terraform.tfstate" gespeichert. Er kann jedoch auch remote gespeichert werden, was in einer Teamumgebung besser funktioniert. ...

Ich gehe nicht davon aus, dass der Rat jemals wieder zur Quellcodeverwaltung als bevorzugte Methode zum Speichern des Status zurückkehren wird.

Trotz des oben zitierten Dokuments ist der Remote-Status als Solo-Entwickler immer noch von Vorteil

Mit dem Remote-Status kann der Solo-Entwickler:

• Arbeiten Sie an ihrem Terraform-Code und führen Sie ihn auf mehreren Geräten aus
• Einfache Sicherung und Schutz vor Verlust der Statusdatei, abhängig vom gewählten Backend
• Trennen Sie Abschnitte ihrer Architektur über Ausgänge
• Verschlüsseln Sie die Statusdatei im Ruhezustand automatisch , je nachdem, welches Backend ausgewählt wurde

Es gibt einige Gründe, Ihre .tfstateDateien nicht in Git zu speichern :

1. Es ist wahrscheinlich, dass Sie vergessen, Ihre Änderungen nach dem Ausführen festzuschreiben und zu übertragen terraform apply, sodass Ihre Teamkollegen über veraltete .tfstateDateien verfügen . Wenn zwei Teammitglieder Terraform gleichzeitig für dieselben .tfstateDateien ausführen , können Sie die Änderungen des anderen Status überschreiben , ohne diese Statusdateien zu sperren . Sie können beide Probleme lösen, indem Sie a) .tfstateDateien in einem S3-Bucket mit dem Remote-Status Terraform speichern , der die .tfstateDateien bei jeder Ausführung automatisch pusht / zieht , terraform applyund b) ein Tool wie terragrunt verwenden , um Ihre .tfstateDateien zu sperren .
2. Die .tfstateDateien können Geheimnisse enthalten. Wenn Sie beispielsweise die Ressource aws_db_instance verwenden , müssen Sie ein Datenbankkennwort angeben, das von Terraform im Klartext in der .tfstateDatei gespeichert wird. Dies ist zunächst eine schlechte Praxis für Terraform, und das Speichern unverschlüsselter Geheimnisse in der Versionskontrolle macht es nur noch schlimmer. Zumindest wenn Sie .tfstateDateien in S3 speichern , können Sie die Verschlüsselung im Ruhezustand aktivieren (SSL bietet Verschlüsselung während der Fahrt) und IAM-Richtlinien konfigurieren, um den Zugriff einzuschränken. Es ist alles andere als ideal und wir müssen sehen, ob das offene Problem, das dieses Problem bespricht, jemals behoben wird.

Weitere Informationen finden Sie unter Verwalten des Terraform-Status und von Terraform: Up & Running .

Dies wird wahrscheinlich von den Vorlieben abhängen, aber ich würde sagen, dass git (oder eine andere Quellcodeverwaltung) keine besonders gute Option zum Speichern von Statusdateien ist, da sie eine Ausgabe des Codes sind, den Sie schreiben, ähnlich wie eine kompilierte Binärdatei oder sogar minimiertes JS oder WENIGER, kompiliert zu CSS.

Darüber hinaus können sich die Dinge in den Statusdateien als Ausgabe für ausgeführte Dinge ziemlich schnell ändern, anstatt dass Dinge tatsächlich im Code geändert werden, was das Ganze ziemlich umständlich macht.

Sie benötigen jedoch eine Möglichkeit, diese Statusdateien für Remote-Teammitglieder oder sogar andere Geräte freizugeben, wenn Sie auf verschiedenen Laptops / Computern entwickeln. Sie möchten auch eine Möglichkeit zum Speichern und Sichern dieser Dateien, da Sie echte Probleme haben, wenn Sie eine Statusdatei verlieren, da Terraform die Statusdateien verwendet, um herauszufinden, welche Dinge verwaltet werden, um nicht auf die Zehen zu treten andere Werkzeuge.

Ich würde sagen, S3 ist wahrscheinlich der beste Ort, an dem Sie sie jetzt platzieren können. Es ist so gut wie kostenlos, die Haltbarkeit ist ausgezeichnet, ebenso wie die Verfügbarkeit. In Terraform wird es mithilfe der Remote- Statusressource sehr gut nativ unterstützt . Und wahrscheinlich am wichtigsten ist, dass Sie nur einen S3-Bucket erstellen müssen, um loszulegen. Bauen mit einem Konsul oder ETCD Cluster zunächst ohne Terraforming (sonst haben Sie ein Huhn und Ei - Problem von wo speichern Sie den Zustand diejenigen für die Erstellung?) Ist ein bisschen wie ein Schmerz , auch wenn Sie eine dieser beiden Produkte verwenden möchten.

Wenn Sie OpenStack verwenden, sollte Swift natürlich eine gute Alternative sein (obwohl ich es nicht verwendet habe). Ich habe auch nicht Hashicorps Atlas verwendet, aber wenn Sie gerne für diesen Service bezahlen, ist er möglicherweise genauso nützlich.

Ich sehe einen Vorteil darin, terraform.tfstate auf andere Weise als über Git zu teilen .

Zum Beispiel: S3, Dropbox usw. (mit aktivierter Versionierung)

Dann ist es möglich, auf den vorherigen Infrastrukturstatus zurückzusetzen.

Beispiel: Sie setzen das Repository von Commit B auf Commit A zurück. Wenn terraform.tfstate unverändert bleibt, überlegt Terraform, wie Sie alle während des Commits B hinzugefügten Elemente zurücksetzen können. Das Rollback ist einfach.

Falls terraform.tfstate ebenfalls zurückgesetzt wurde, um A festzuschreiben, glaubt terraform, dass terraform.tfstate mit der erforderlichen Konfiguration synchronisiert ist, und wendet das Rollback nicht auf Ihre Infrastruktur an.