Ursprünglich veröffentlicht auf LinkedIn am 2022-02-14.
In diesen Tagen lerne ich, eine Infrastruktur in GCP aufzubauen. In den letzten Jahren habe ich bereits mit Terraform gearbeitet und habe daher schon einige Erfahrungen damit gesammelt. Aber ich habe terraform_remote_state in der Vergangenheit nicht als Datenquelle verwendet.
Ein Freund hat mir gezeigt, wie man es verwendet, und es hat meine Art, Terraform-Pläne zu schreiben, vollständig verändert. Auch die Struktur meiner Pläne hat sich mit diesem Wissen geändert.
ABER seien Sie vorsichtig, es gibt wichtige Dinge zu beachten, es hat einige Sicherheitsnachteile. Lesen Sie wirklich die Dokumentation, bevor Sie beginnen, es zu verwenden!
“Das Teilen von Daten mit den Ausgaben des Root-Moduls ist praktisch, aber es hat Nachteile. Obwohl terraform_remote_state nur Ausgabewerte freigibt, muss sein Benutzer Zugriff auf den gesamten Status-Snapshot haben, der oft einige sensible Informationen enthält.” Quelle
Seien Sie vorsichtig mit Remote-State-Dateien in Objektspeichern, denn es ist nur ein kleines Konfigurationsproblem, und sensible Daten werden öffentlich…
Dieses Wissen war ein Game-Changer. In der Vergangenheit habe ich Input- und Output-Variablen zusammen mit Modulen stark genutzt. Ich war auch daran gewöhnt, Terraform-Module zu schreiben, die Dienste durch das Auslösen von Chef oder Ansible konfigurieren. Mit dem Fokus auf Bereitstellungen auf GKE habe ich mich gefragt, ob ich überhaupt ein Konfigurationsmanagement benötige. Durch die Verwendung von Kubernetes als verwalteten Dienst gab es keine Notwendigkeit, ein Konfigurationsmanagement in den Stack aufzunehmen. Das Schreiben von Manifesten und das Vorhandensein einer Bereitstellungspipeline ist ein anderes Ziel.
In der Vergangenheit war ich es gewohnt, meine Terraform-Pläne nach Anwendung und Umgebungen zu strukturieren. Innerhalb eines Anwendungsplans hatte ich Datenbank, Anwendungsserver, Redis usw. Sicher, es konfiguriert auch alle Dinge, weil Ansible ebenfalls ausgelöst wird. Und es hatte seine Vor- und Nachteile.
Zurück zu Terraform. Mit diesen Voraussetzungen habe ich Pläne geschrieben und Datenquellen mit terraform_remote_state definiert, um die Datenquelle in Ressourcen zu verwenden. Auf diese Weise kann ich den Status eines anderen Plans verwenden. Irgendwie ergibt das für mich Sinn.
Ich habe gelernt, Terraform-Pläne auf eine andere Weise zu strukturieren. Ein Plan für die Projekterklärung, ein anderer für Datenbanken, der nächste für Kubernetes. Durch die Verwendung von terraform_remote_state ist es möglich, Variablen eines anderen Zustands abzurufen und sie in verschiedenen Plänen als Datenquelle zu verwenden. Auf diese Weise können die Datenbankpläne auf Werte des Projekt-Remote-Zustands zugreifen. Alle Datenbankinstanzen befinden sich in einer CloudSql-Terraform-Konfiguration, die gesamte GKE-Basisinfrastruktur im GKE-Plan, und beide greifen über terraform_remote_state als Datenquelle auf den Projektplan-Zustand zu.
Es gibt verschiedene Möglichkeiten, Terraform-Projekte zu strukturieren, jede hat ihre Vor- und Nachteile.
- ahead wie man HashiCorp Terraform Remote State nutzt
- DigitalOcean wie man ein Terraform-Projekt strukturiert
- Jack Roper wie man Terraform-Projekte strukturiert
Wenn Sie einige Erfahrungen oder andere interessante Tutorials haben, wäre es wirklich schön, wenn Sie diese als Kommentar teilen könnten.