Wir empfehlen die Verwendung einer deklarativen Infrastruktur, um die Grundlage konsistent und kontrollierbar bereitzustellen. Dieser Ansatz unterstützt eine konsistente Governance, indem Richtliniensteuerungen zu akzeptablen 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.
Im folgenden Diagramm wird unser empfohlenes Modell vorgestellt, mit dem eine Grundlagenpipeline, eine Infrastrukturpipeline und eine Anwendungspipeline getrennt werden können.
Im Diagramm werden die Pipeline-Ebenen in diesem Modell vorgestellt:
- Die Grundlagenpipeline stellt die Grundlagenressourcen bereit, die auf der gesamten Plattform verwendet werden. Wir empfehlen, dass ein zentrales Team für die Verwaltung der Grundlagenressourcen verantwortlich ist, die von mehreren Geschäftseinheiten und Arbeitslasten genutzt werden.
- In der Infrastrukturpipeline werden Projekte und Infrastrukturen bereitgestellt, die von Arbeitslasten wie VM-Instanzen oder Datenbanken verwendet werden. Mit dem Blueprint wird eine separate Infrastrukturpipeline für jede Geschäftseinheit eingerichtet. Sie können aber auch eine einzelne Infrastrukturpipeline bevorzugen, die von mehreren Teams verwendet wird.
- Die Anwendungspipeline stellt die Artefakte für jede Arbeitslast bereit, z. B. Container oder Images. Möglicherweise haben Sie viele verschiedene Anwendungsteams mit einzelnen Anwendungspipelines.
In den folgenden Abschnitten wird die Nutzung der einzelnen Pipelineebenen vorgestellt.
Grundlagenpipeline
Die Grundlagenpipeline stellt die Grundlagenressourcen bereit. Außerdem wird die Infrastrukturpipeline eingerichtet, die zum Bereitstellen von Infrastruktur verwendet wird, die von Arbeitslasten verwendet wird.
Um die Grundlagenpipeline zu erstellen, klonen Sie zuerst die terraform-example-foundation in Ihr eigenes Git-Repository oder verzweigen Sie. Führen Sie die Schritte in der README-Datei 0-bootstrap aus, um den Bootstrap-Ordner und die Ressourcen zu konfigurieren.
| Phase | Beschreibung |
|---|---|
Bootstrapping einer Google Cloud-Organisation. Mit diesem Schritt wird auch eine CI/CD-Pipeline für den Blueprint-Code in nachfolgenden Phasen konfiguriert.
|
Nachdem Sie die Grundlagenpipeline in der Phase 0-bootstrap erstellt haben, stellen die folgenden Phasen Ressourcen in der Grundlagenpipeline bereit. Lesen Sie die README-Anleitung für jede Phase und implementieren Sie jede Phase sequenziell.
| Phase | Beschreibung |
|---|---|
Richtet übergeordnete freigegebene Ordner, Projekte für freigegebene Dienste, Logging auf Organisationsebene und grundlegende Sicherheitseinstellungen über Organisationsrichtlinien ein. |
|
Richtet Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen in der von Ihnen erstellten Google Cloud-Organisation ein. |
|
oder |
Richtet freigegebene VPCs in der ausgewählten Topologie und den zugehörigen Netzwerkressourcen ein. |
Infrastrukturpipeline
In der Infrastrukturpipeline werden die Projekte und Infrastruktur bereitgestellt, z. B. die VM-Instanzen und Datenbanken, die von Arbeitslasten verwendet werden. Die Grundlagenpipeline stellt mehrere Infrastrukturpipelines bereit. Diese Trennung zwischen der Grundlagenpipeline und der Infrastrukturpipeline ermöglicht eine Trennung zwischen plattformweiten Ressourcen und arbeitslastspezifischen Ressourcen.
Das folgende Diagramm zeigt, wie der Blueprint mehrere Infrastrukturpipelines konfiguriert, die für separate Teams vorgesehen sind.
Das Diagramm beschreibt die folgenden Schlüsselkonzepte:
- Jede Infrastrukturpipeline wird verwendet, um Infrastrukturressourcen unabhängig von den Grundlagenressourcen zu verwalten.
- Jede Geschäftseinheit hat eine eigene Infrastrukturpipeline, die in einem dedizierten Projekt im Ordner
commonverwaltet wird. - Jede Infrastrukturpipeline hat ein Dienstkonto mit der Berechtigung, 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 verwenden, die von einem einzigen Team mit konsistenten 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 unter Verwendung der Infrastrukturpipeline als Beispiel bereit. |
Anwendungspipeline
Die Anwendungspipeline ist für die Bereitstellung von Anwendungsartefakten für jede einzelne Arbeitslast verantwortlich, z. B. Images oder Kubernetes-Container, die die Geschäftslogik Ihrer Anwendung ausführen. 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. Ein Beispiel für eine Anwendungspipeline finden Sie im Blueprint für Unternehmensanwendungen.
Pipeline mit Cloud Build automatisieren
Der Blueprint verwendet Cloud Build, 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 |
|---|---|
Build-Konfigurationen trennen, um Code vor der Bereitstellung zu validieren |
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 Einschränkungen für Open Policy-Agents, die durch die Richtlinienvalidierung in Google Cloud CLI erzwungen werden. Diese Einschränkungen definieren die zulässigen Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn ein Build die Richtlinie in der ersten Build-Konfiguration nicht erfüllt, stellt die zweite Build-Konfiguration keine Ressourcen bereit. Die im Blueprint erzwungenen Richtlinien werden von |
Prinzip der geringsten Berechtigung | Die Grundlagenpipeline hat für jede Phase ein anderes Dienstkonto mit einer Zulassungsrichtlinie, die nur die minimalen IAM-Rollen für diese Phase zuweist. Jeder Cloud Build-Trigger wird als das spezifische Dienstkonto für diese Phase ausgeführt. Die Verwendung unterschiedlicher Konten verringert das Risiko, dass sich Änderungen an einem Repository auf die Ressourcen auswirken können, die von einem anderen Repository verwaltet werden. Informationen zu den einzelnen IAM-Rollen, die auf jedes Dienstkonto angewendet werden, finden Sie im Terraform-Code |
Private Cloud Build-Pools | Der Blueprint verwendet private Cloud Build-Pools. Mit privaten Pools können Sie optional zusätzliche Kontrollen erzwingen und beispielsweise den Zugriff auf öffentliche Repositories einschränken oder Cloud Build in einem VPC Service Controls-Perimeter ausführen. |
Benutzerdefinierte Builder von Cloud Build | Der Blueprint erstellt einen eigenen benutzerdefinierten Builder, um Terraform auszuführen. Weitere Informationen finden Sie unter |
Bereitstellungsgenehmigung | Optional können Sie eine manuelle Genehmigungsphase zu Cloud Build 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 Fehlerkorrektur arbeiten, erstellen Sie einen neuen Zweig basierend auf dem Entwicklungszweig. 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 Grundlagenpipeline aus, um
terraform applyauszuführen, um 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 Vorgänge (nächstes Dokument in dieser Reihe)