Wir empfehlen die Verwendung einer deklarativen Infrastruktur, um Ihre Grundlage auf konsistente und steuerbare Weise bereitzustellen. Dieser Ansatz trägt zu einer einheitlichen Verwaltung bei, indem Richtlinienkontrollen für zulässige Ressourcenkonfigurationen in Ihren Pipelines erzwungen werden. Der Blueprint wird mit einem GitOps-Ablauf bereitgestellt, wobei Terraform verwendet wird, um die Infrastruktur als Code (IaC), ein Git-Repository für die Versionsverwaltung und Genehmigung von Code und Cloud Build für die CI/CD-Automatisierung in der Bereitstellungspipeline zu definieren. Eine Einführung in dieses Konzept finden Sie unter Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten.
In den folgenden Abschnitten wird beschrieben, wie die Bereitstellungspipeline zum Verwalten von Ressourcen in Ihrer Organisation verwendet wird.
Pipelineebenen
Zur Trennung der Teams und des Technologie-Stacks, die für die Verwaltung verschiedener Ebenen Ihrer Umgebung verantwortlich sind, empfehlen wir ein Modell, das unterschiedliche Pipelines und verschiedene Identitäten verwendet, die für jede Schicht des Stacks verantwortlich sind.
Das folgende Diagramm zeigt unser empfohlenes Modell zur Trennung von Basispipeline, Infrastrukturpipeline und Anwendungspipeline.
Das Diagramm zeigt die Pipelineebenen in diesem Modell:
- Mit der Grundlagenpipeline werden die Grundlagenressourcen bereitgestellt, die auf der gesamten Plattform verwendet werden. Wir empfehlen, dass ein einzelnes zentrales Team für die Verwaltung der Basisressourcen zuständig ist, die von mehreren Geschäftsbereichen und Arbeitslasten genutzt werden.
- Mit der Infrastruktur-Pipeline werden Projekte und Infrastruktur bereitgestellt, die von Arbeitslasten wie VM-Instanzen oder Datenbanken verwendet werden. Im Blueprint wird für jede Geschäftseinheit eine separate Infrastrukturpipeline eingerichtet. Sie können auch eine einzelne Infrastrukturpipeline verwenden, die von mehreren Teams genutzt wird.
- Die Anwendungspipeline stellt die Artefakte für jede Arbeitslast bereit, z. B. Container oder Images. Möglicherweise haben Sie viele verschiedene Anwendungsteams mit individuellen Anwendungspipelines.
In den folgenden Abschnitten wird die Verwendung der einzelnen Pipelineebenen vorgestellt.
Die Grundlagenpipeline
Die Grundlagenpipeline stellt die Grundlagenressourcen bereit. Außerdem wird die Infrastrukturpipeline eingerichtet, mit der die von Arbeitslasten verwendete Infrastruktur bereitgestellt wird.
Um die Grundlagenpipeline zu erstellen, klonen Sie zuerst die terraform-example-foundation in Ihr eigenes Git-Repository oder verzweigen sie. Folgen Sie der Anleitung in der 0-bootstrap README-Datei, um den Bootstrap-Ordner und die Ressourcen zu konfigurieren.
| Phase | Beschreibung |
|---|---|
Führt das Bootstrapping einer Google Cloud-Organisation durch. In diesem Schritt wird auch eine CI/CD-Pipeline für den Blueprint-Code in den nachfolgenden Phasen konfiguriert.
|
Nachdem Sie die Basispipeline in der Phase 0-bootstrap erstellt haben, werden in den folgenden Phasen Ressourcen in der Basispipeline bereitgestellt. Lesen Sie die Anleitungen in der README-Datei für jede Phase und implementieren Sie die einzelnen Phasen nacheinander.
| Phase | Beschreibung |
|---|---|
Richtet übergeordnete freigegebene Ordner, Projekte für freigegebene Dienste, Logging auf Organisationsebene und grundlegende Sicherheitseinstellungen über Organisationsrichtlinien ein. |
|
Hiermit werden Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen in der von Ihnen erstellten Google Cloud-Organisation eingerichtet. |
|
oder |
Hiermit werden freigegebene VPCs in der ausgewählten Topologie und die zugehörigen Netzwerkressourcen eingerichtet. |
Infrastrukturpipeline
Über die Infrastruktur-Pipeline werden die Projekte und die Infrastruktur (z. B. die VM-Instanzen und Datenbanken) bereitgestellt, die von Arbeitslasten verwendet werden. Mit der Basispipeline werden mehrere Infrastrukturpipelines bereitgestellt. Diese Trennung zwischen der Grundlagenpipeline und der Infrastrukturpipeline ermöglicht eine Trennung zwischen platformweiten und arbeitslastspezifischen Ressourcen.
Das folgende Diagramm zeigt, wie im Blueprint mehrere Infrastrukturpipelines konfiguriert werden, die von verschiedenen Teams verwendet werden sollen.
Das Diagramm beschreibt die folgenden wichtigen Konzepte:
- Mit jeder Infrastruktur-Pipeline werden Infrastrukturressourcen unabhängig von den Basisressourcen verwaltet.
- Jede Geschäftseinheit hat eine eigene Infrastrukturpipeline, die in einem speziellen Projekt im Ordner
commonverwaltet wird. - Jede der Infrastrukturpipelines hat ein Dienstkonto, das die Berechtigung hat, Ressourcen nur für die Projekte bereitzustellen, die dieser Geschäftseinheit zugeordnet sind. Diese Strategie erstellt eine Aufgabentrennung zwischen den privilegierten Dienstkonten, die für die Grundlagenpipeline verwendet werden, und denen, die von jeder Infrastrukturpipeline verwendet werden.
Dieser Ansatz mit mehreren Infrastrukturpipelines wird empfohlen, wenn Sie mehrere Entitäten in Ihrer Organisation haben, die die Fähigkeiten und Notwendigkeiten zur separaten Verwaltung ihrer Infrastruktur haben, insbesondere wenn sie unterschiedliche Anforderungen wie die Arten der Pipelinevalidierungsrichtlinie haben, die erzwungen werden soll. Alternativ können Sie auch eine einzelne Infrastrukturpipeline bevorzugen, die von einem einzigen Team mit einheitlichen Validierungsrichtlinien verwaltet wird.
In der terraform-example-foundation konfiguriert Phase 4 eine Infrastrukturpipeline und Phase 5 ein Beispiel für die Verwendung dieser Pipeline zum Bereitstellen von Infrastrukturressourcen.
| Phase | Beschreibung |
|---|---|
Richtet eine Ordnerstruktur, Projekte und eine Infrastrukturpipeline ein. |
|
|
Stellt Arbeitslastprojekte mit einer Compute Engine-Instanz bereit und verwendet dabei die Infrastrukturpipeline als Beispiel. |
Anwendungspipeline
Die Anwendungspipeline ist für das Bereitstellen von Anwendungsartefakten für jede einzelne Arbeitslast verantwortlich, z. B. für Images oder Kubernetes-Container, in denen die Geschäftslogik Ihrer Anwendung ausgeführt wird. Diese Artefakte werden in Infrastrukturressourcen bereitgestellt, die von der Infrastrukturpipeline bereitgestellt worden sind.
Der Blueprint zu Unternehmensgrundlagen richtet Ihre Grundlagenpipeline und die Infrastrukturpipeline ein, stellt jedoch keine Anwendungspipeline bereit. Eine Beispielanwendungspipeline finden Sie im Enterprise Application Blueprint.
Pipeline mit Cloud Build automatisieren
Im Blueprint wird Cloud Build verwendet, um CI/CD-Prozesse zu automatisieren. In der folgenden Tabelle werden die Steuerelemente beschrieben, die in die Grundlagenpipeline und die Infrastrukturpipeline eingebunden sind, die vom Repository terraform-example-foundation bereitgestellt werden. Wenn Sie eigene Pipelines mit anderen CI/CD-Automatisierungstools entwickeln, empfehlen wir die Anwendung ähnlicher Steuerelemente.
| Steuerelement | Beschreibung |
|---|---|
Separate Buildkonfigurationen zum Validieren des Codes vor der Bereitstellung |
Der Blueprint verwendet zwei Build-Konfigurationsdateien für die gesamte Pipeline und jedes mit einer Phase verknüpfte Repository enthält zwei Cloud Build-Trigger, die mit diesen Build-Konfigurationsdateien verknüpft sind. Wenn Code an einen Repository-Zweig übertragen wird, werden die Build-Konfigurationsdateien ausgelöst, um zuerst |
Terraform-Richtlinienprüfungen | Der Blueprint enthält eine Reihe von Open Policy Agent-Einschränkungen, die durch die Richtlinienüberprüfung in der Google Cloud CLI erzwungen werden. Diese Einschränkungen definieren die zulässigen Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn ein Build nicht den Richtlinien in der ersten Build-Konfiguration entspricht, werden mit der zweiten Build-Konfiguration keine Ressourcen bereitgestellt. Die im Blueprint erzwungenen Richtlinien sind Forks von |
Prinzip der geringsten Berechtigung | Die Foundation-Pipeline hat für jede Phase ein anderes Dienstkonto mit einer Zulassungsrichtlinie, die nur die Mindestanzahl an IAM-Rollen für diese Phase gewährt. Jeder Cloud Build-Trigger wird als das jeweilige Dienstkonto für diese Phase ausgeführt. Durch die Verwendung verschiedener Konten lässt sich das Risiko verringern, dass die Änderung eines Repositories sich auf die Ressourcen auswirkt, die von einem anderen Repository verwaltet werden. Informationen zu den einzelnen IAM-Rollen, die auf jedes Dienstkonto angewendet werden, finden Sie im |
Private Cloud Build-Pools | Der Blueprint verwendet private Cloud Build-Pools. Mit privaten Pools können Sie optional zusätzliche Steuerelemente erzwingen, z. B. den Zugriff auf öffentliche Repositories einschränken oder Cloud Build innerhalb eines VPC Service Controls-Perimeters ausführen. |
Benutzerdefinierte Cloud Build-Builder | Der Blueprint erstellt einen eigenen benutzerdefinierten Builder, um Terraform auszuführen. Weitere Informationen finden Sie unter |
Bereitstellungsgenehmigung | Optional können Sie Cloud Build eine Phase für die manuelle Genehmigung hinzufügen. Diese Genehmigung fügt einen zusätzlichen Prüfpunkt nach dem Auslösen, jedoch vor der Ausführung des Builds hinzu, damit ein berechtigter Nutzer den Build manuell genehmigen kann. |
Verzweigungsstrategie
Wir empfehlen eine persistente Verzweigungsstrategie, um Code an Ihr Git-System zu senden und Ressourcen über die Grundlagenpipeline bereitzustellen. Im folgenden Diagramm wird die persistente Verzweigungsstrategie beschrieben.
Im Diagramm werden drei persistente Zweige in Git (Entwicklung, Nicht-Produktion und Produktion) beschrieben, die die entsprechenden Google Cloud-Umgebungen widerspiegeln. Es gibt auch mehrere sitzungsspezifische Feature-Zweige, die keinen Ressourcen entsprechen, die in Ihren Google Cloud-Umgebungen bereitgestellt sind.
Wir empfehlen, einen Pull-Anfrageprozess (PR) in Ihr Git-System zu erzwingen, damit jeder Code, der in einen persistenten Zweig zusammengeführt wird, eine genehmigte Pull-Anfrage hat.
Führen Sie die folgenden allgemeinen Schritte aus, um Code mit dieser persistenten Verzweigungsstrategie zu entwickeln:
- Wenn Sie neue Funktionen entwickeln oder an einer Fehlerbehebung arbeiten, erstellen Sie einen neuen Zweig, der auf dem Entwicklungszweig basiert. Verwenden Sie eine Namenskonvention für den Zweig, die die Art der Änderung, eine Ticketnummer oder eine andere Kennzeichnung sowie eine visuell lesbare Beschreibung wie
feature/123456-org-policiesenthält. - Wenn Sie die Arbeit im Feature-Zweig abschließen, öffnen Sie eine PR, die auf den Entwicklungszweig abzielt.
- Wenn Sie die PR senden, löst die PR die Grundlagenpipeline aus, um
terraform planundterraform validatezum Staging und Prüfen der Änderungen auszuführen. - Nachdem Sie die Änderungen am Code validiert haben, führen Sie das Feature oder die Fehlerkorrektur im Entwicklungszweig zusammen.
- Der Zusammenführungsprozess löst die Ausführung der Grundlagenpipeline aus, um
terraform applyauszuführen und die neuesten Änderungen im Entwicklungszweig in der Entwicklungsumgebung bereitzustellen. - Prüfen Sie die Änderungen in der Entwicklungsumgebung mit beliebigen manuellen Prüfungen, Funktionstests oder End-to-End-Tests, die für Ihren Anwendungsfall relevant sind. Stufen Sie dann Änderungen an der Nicht-Produktionsumgebung hoch, indem Sie eine PR öffnen, die auf den Nicht-Produktionszweig abzielt, und führen Sie Ihre Änderungen zusammen.
- Zum Bereitstellen von Ressourcen in der Produktionsumgebung wiederholen Sie den gleichen Vorgang wie in Schritt 6: Überprüfen und validieren Sie die bereitgestellten Ressourcen, öffnen Sie eine PR für den Produktionszweig und führen Sie die Zusammenführung durch.
Nächste Schritte
- Best Practices für die Betriebsabläufe (nächstes Dokument in dieser Reihe)