Best Practices für die Versionsverwaltung

In diesem Dokument finden Sie Best Practices für die Versionskontrolle bei der Verwendung von Terraform für Google Cloud.

Speichern Sie wie bei anderen Codetypen Infrastrukturcode in der Versionsverwaltung, um den Verlauf beizubehalten und einfache Rollbacks zu ermöglichen.

Dieser Leitfaden ist keine Einführung in Terraform. Eine Einführung in die Verwendung von Terraform mit Google Cloud finden Sie unter Erste Schritte mit Terraform.

Standardverzweigungsstrategie verwenden

Verwenden Sie für alle Repositories, die Terraform-Code enthalten, standardmäßig die folgende Strategie:

• Der Zweig main ist der primäre Entwicklungszweig und stellt den neuesten genehmigten Code dar. Der main-Zweig ist geschützt.
• Die Entwicklung erfolgt in Feature- und Fehlerkorrekturzweigen, die vom Zweig main ausgehen.
  • Nennen Sie Featurezweige feature/$feature_name.
  • Nennen Sie Fehlerkorrekturzweige fix/$bugfix_name.
• Wenn ein Feature oder eine Fehlerkorrektur abgeschlossen ist, führen Sie sie über eine Pull-Anfrage wieder mit dem Zweig main zusammen.
• Führen Sie zur Vermeidung von Zusammenführungskonflikten ein Rebasing von Zweigen durch, bevor Sie sie zusammenführen.

Umgebungszweige für Stammkonfigurationen verwenden

Für Repositories mit Stammkonfigurationen, die direkt in Google Cloud bereitgestellt werden, ist eine sichere Roll-out-Strategie erforderlich. Wir empfehlen, für jede Umgebung einen separaten Zweig zu erstellen. Dadurch können Änderungen an der Terraform-Konfiguration durch Zusammenführen von Änderungen zwischen den verschiedenen Zweige hochgestuft werden.

Umfassende Sichtbarkeit zulassen

Sorgen Sie dafür, dass Terraform-Quellcode und -Repositories in Entwicklungsorganisationen sowie für Infrastrukturinhaber (z. B. SREs) und Infrastruktur-Stakeholder (z. B. Entwickler) umfassend sichtbar und zugänglich sind. Dadurch erhalten die Stakeholder in der Infrastruktur ein besseres Verständnis der Infrastruktur, von der sie abhängen.

Ermutigen Sie die Infrastruktur-Stakeholder, im Rahmen des Änderungsanfrageprozesses Zusammenführungsanfragen zu senden.

Niemals Commit von Secrets durchführen

Führen Sie niemals einen Commit von Secrets an die Versionsverwaltung durch, auch nicht an die Terraform-Konfiguration. Laden Sie sie stattdessen in ein System wie Secret Manager hoch und verweisen Sie mithilfe von Datenquellen darauf.

Beachten Sie, dass solche vertraulichen Werte möglicherweise in der Zustandsdatei landen und auch als Ausgaben bereitgestellt werden können.

Repositories anhand von Teamgrenzen organisieren

Obwohl Sie separate Verzeichnisse verwenden können, um logische Grenzen zwischen Ressourcen zu verwalten, bestimmen Organisationsgrenzen und Logistik die Repository-Struktur. Verwenden Sie im Allgemeinen das Designprinzip, dass Konfigurationen mit unterschiedlichen Genehmigungs- und Verwaltungsanforderungen in verschiedene Versionsverwaltungs-Repositories unterteilt werden. Zur Veranschaulichung dieses Prinzips hier einige mögliche Repository-Konfigurationen:

• Ein zentrales Repository: In diesem Modell wird der gesamte Terraform-Code zentral von einem einzelnen Plattformteam verwaltet. Dieses Modell funktioniert am besten, wenn ein dediziertes Infrastrukturteam für die gesamte Cloud-Verwaltung verantwortlich ist und alle von anderen Teams angeforderten Änderungen genehmigt.

• Team-Repositories: In diesem Modell ist jedes Team für sein eigenes Terraform-Repository verantwortlich, in dem es alles im Zusammenhang mit der Infrastruktur verwaltet, die ihm gehört. Das Sicherheitsteam kann beispielsweise ein Repository haben, in dem alle Sicherheitseinstellungen verwaltet werden, und die Anwendungsteams haben jeweils ein eigenes Terraform-Repository zur Bereitstellung und Verwaltung ihrer Anwendung.

  Die Organisation von Repositories gemäß Teamgrenzen ist für die meisten Unternehmensszenarien die beste Struktur.

• Entkoppelte Repositories: In diesem Modell wird jede logische Terraform-Komponente in ein eigenes Repository eingeteilt. Netzwerke können beispielsweise ein dediziertes Repository haben und es kann ein separates Projekt-Factory-Repository für die Erstellung und Verwaltung von Projekten geben. Dies funktioniert am besten in stark dezentralisierten Umgebungen, in denen Verantwortlichkeiten häufig zwischen Teams wechseln.

Beispiel für Repository-Struktur

Sie können diese Prinzipien kombinieren, um die Terraform-Konfiguration auf verschiedene Repository-Typen aufzuteilen:

• Grundlegend
• Anwendungs- und teamspezifisch

Grundlegendes Repository

Ein grundlegendes Repository, das wichtige zentrale Komponenten wie Ordner oder Organisations-IAM enthält. Dieses Repository kann vom zentralen Cloud-Team verwaltet werden.

• Fügen Sie in diesem Repository für jede Hauptkomponente ein Verzeichnis ein (z. B. Ordner, Netzwerke usw.).
• Fügen Sie in die Komponentenverzeichnisse einen separaten Ordner für jede Umgebung ein, was den zuvor genannten Verzeichnisstrukturrichtlinien entspricht.

Anwendungs- und teamspezifische Repositories

Stellen Sie anwendungs- und teamspezifische Repositories für jedes Team separat bereit, um seine spezielle anwendungsspezifische Terraform-Konfiguration zu verwalten.

Nächste Schritte

• Best Practices für Terraform-Vorgänge
• Best Practices für die sichere Verwendung von Terraform