Blueprint bereitstellen

Last reviewed 2024-04-19 UTC

In diesem Abschnitt werden der Prozess, den Sie zum Bereitstellen des Blueprints verwenden können, sowie seine Namenskonventionen und Alternativen zu Blueprint-Empfehlungen beschrieben.

Zusammenfassung

Führen Sie die Schritte in diesem Abschnitt aus, um die in diesem Dokument beschriebene Architektur zu implementieren.

Blueprint in einer neuen Organisation bereitstellen

Führen Sie die folgenden Schritte aus, um den Blueprint in einer neuen Google Cloud-Organisation bereitzustellen:

  1. Erstellen Sie Ihre grundlegende Infrastruktur mit dem Blueprint für Unternehmensgrundlagen. Führen Sie Folgendes aus:

    1. Erstellen Sie eine Organisationsstruktur, einschließlich Ordnern für die Trennung von Umgebungen.
    2. Grundlegende IAM-Berechtigungen konfigurieren, um Zugriff auf Entwicklerplattformadministratoren zu gewähren
    3. VPC-Netzwerk erstellen.
    4. Grundlageninfrastruktur-Pipeline bereitstellen.

    Wenn Sie den Blueprint zu Unternehmensgrundlagen nicht verwenden, finden Sie weitere Informationen unter Blueprint ohne Unternehmens-Blueprint bereitstellen.

  2. Der Entwicklerplattform-Administrator verwendet die Grundlage der Infrastruktur-Pipeline, um die mehrmandantenfähige Infrastrukturpipeline, die Pipeline für die Anwendung der Factory und den Flottenbereich zu erstellen.

  3. Der Entwicklerplattformadministrator verwendet die mehrmandantenfähige Infrastrukturpipeline, um GKE-Cluster und eine gemeinsam genutzte Infrastruktur bereitzustellen.

  4. Anwendungsoperatoren verwenden die Application Factory, um neue Anwendungen einzurichten. Operatoren fügen dem Anwendungs-Factory-Repository einen oder mehrere Einträge hinzu, die das Erstellen von anwendungsspezifischen Ressourcen auslösen.

  5. Anwendungsentwickler verwenden die Anwendungs-CI/CD-Pipeline in ihrer anwendungsspezifischen Infrastruktur, um Anwendungen in der mehrmandantenfähigen Infrastruktur bereitzustellen.

Blueprint ohne Blueprint für Unternehmensgrundlagen bereitstellen

Wenn Sie den Blueprint der Unternehmensanwendung nicht im Blueprint der Unternehmensgrundlagen bereitstellen, führen Sie die folgenden Schritte aus:

  1. Erstellen Sie die folgenden Ressourcen:
    • Eine Organisationshierarchie mit den Ordnern development, nonproduction und production
    • Ein freigegebenes VPC-Netzwerk in jedem Ordner
    • Ein IP-Adressschema, das die erforderlichen IP-Bereiche für Ihre GKE-Cluster berücksichtigt
    • Einen DNS-Mechanismus für Ihre GKE-Cluster
    • Firewallrichtlinien, die auf Ihren Sicherheitsstatus ausgerichtet sind
    • Einen Mechanismus für den Zugriff auf Google Cloud APIs über private IP-Adressen
    • Einen Verbindungsmechanismus mit Ihrer lokalen Umgebung
    • Zentrales Logging für Sicherheit und Audit
    • Security Command Center für Bedrohungsmonitoring
    • Organisationsrichtlinien, die Ihrem Sicherheitsstatus entsprechen
    • Eine Pipeline, mit der die Anwendungs-Factory, die mehrmandantenfähige Infrastrukturpipeline und die Pipeline des Flottenbereichs bereitgestellt werden können
  2. Nachdem Sie die Ressourcen bereitgestellt haben, fahren Sie mit Schritt 2 unter Blueprint in einer neuen Organisation bereitstellen fort.

Blueprint in Ihre vorhandene GKE-Bereitstellung einbinden

Bei diesem Blueprint müssen Sie zuerst die Entwicklerplattform und dann Anwendungen auf der Entwicklerplattform bereitstellen. In der folgenden Tabelle wird beschrieben, wie Sie den Blueprint verwenden, wenn Sie bereits containerisierte Anwendungen in Google Cloud ausführen.

Vorhandene Nutzung Migrationsstrategie

Sie haben bereits eine CI/CD-Pipeline.

Sie können die Flotten- und Clusterarchitektur des Blueprints verwenden, auch wenn verschiedene Produkte für die Erstellung und Bereitstellung der Anwendung verwendet werden. Wir empfehlen, Bilder mindestens in zwei Regionen zu spiegeln.

Sie haben eine vorhandene Organisationsstruktur, die nicht mit dem Blueprint für Unternehmensgrundlagen übereinstimmt.

Für sicherere sequenzielle Bereitstellungen wird empfohlen, mindestens zwei Umgebungen zu verwenden. Sie müssen Umgebungen nicht in separaten freigegebenen VPCs oder Ordnern bereitstellen. Stellen Sie jedoch keine Arbeitslasten bereit, die zu verschiedenen Umgebungen im selben Cluster gehören.

Verwenden Sie IaC nicht.

Wenn Ihr aktueller Bereitstellungsprozess für Anwendungen keinen IaC verwendet, können Sie Ihre Bereitschaft mit dem Reifegrad von Terraform in Google Cloud prüfen. Importieren Sie vorhandene Ressourcen in ein anderes Terraform-Projekt, das diesem Blueprint ähnelt, mit der Trennung von mehrmandantenfähigen und pro-mandantenfähigen Pipelines. Zum Erstellen neuer Cluster können Sie Terraform-Module für Google Cloud verwenden.

Cluster sind auf mehrere Projekte innerhalb derselben Umgebung verteilt.

Sie können Cluster aus mehreren Projekten in einer Flotte gruppieren. Prüfen Sie, ob Ihre Namespaces innerhalb der Flotte eindeutige Bedeutungen haben. Bevor Sie Cluster zu einer Flotte hinzufügen, bitten Sie die Teams, ihre Anwendungen in einen Namespace mit einem eindeutigen Namen zu verschieben (z. B. nicht default).

Anschließend können Sie Namespaces in Bereichen gruppieren.

Cluster befinden sich in einer einzigen Region.

Sie müssen nicht mehrere Regionen in der Produktion und in der Nicht-Produktionsumgebung verwenden, um den Blueprint zu übernehmen.

Es gibt verschiedene Umgebungen.

Sie können den Blueprint so ändern, dass er mehr oder weniger als drei Umgebungen unterstützt.

Das Erstellen von Clustern wird an Anwendungsentwickler oder Anwendungsoperatorteams delegiert.

Als sicherste und konsistente Entwicklerplattform können Sie versuchen, die Inhaberschaft von Clustern aus den Anwendungsteams in das Entwicklerplattformteam zu verschieben. Wenn dies nicht möglich ist, können Sie trotzdem viele der Blueprint-Praktiken anwenden. Sie können beispielsweise Flotten von verschiedenen Anwendungsteams zu einer Flotte hinzufügen. Wenn Sie jedoch Cluster mit unabhängiger Inhaberschaft kombinieren, sollten Sie nicht Workload Identity Federation for GKE oder Cloud Service Mesh verwenden, da sie nicht genügend Kontrolle darüber bieten, wer welche Workload Identitys bestätigen kann. Verwenden Sie stattdessen eine benutzerdefinierte Organisationsrichtlinie, um zu verhindern, dass Teams diese Features auf GKE-Clustern aktivieren.

Wenn Cluster in einer Flotte gruppiert sind, können Sie dennoch Richtlinien prüfen und erzwingen. Sie können eine benutzerdefinierte Organisationsrichtlinie verwenden, um zu verlangen, dass Cluster innerhalb einer Flotte erstellt werden, die dem Umgebungsordner entspricht, in dem sich das Projekt des Clusters befindet. Sie können die Standardkonfiguration der Flotte verwenden, um zu verlangen, dass neue Cluster die Richtliniensteuerung verwenden.

Alternativen zu Standardempfehlungen

In diesem Abschnitt werden Alternativen zu den Standardempfehlungen beschrieben, die in diesem Leitfaden enthalten sind.

Entscheidungsbereich Mögliche Alternativen

Alle Anwendungen werden in demselben Cluster ausgeführt.

Der Blueprint verwendet eine Reihe von fünf Clustern (zwei in der Produktion, zwei in der Nicht-Produktion und einer in der Entwicklung). Sie können den Blueprint so ändern, dass zusätzliche Sätze von fünf Clustern erstellt werden.

Anwendungen Gruppen von fünf Clustern zuweisen Binden Sie die Bereiche oder Flotten-Namespaces einer Anwendung nicht an Cluster in den anderen Datasets. Sie können Anwendungen in verschiedene Clustersätze unterteilen, um Aktivitäten wie die folgenden zu beenden:

  • Gruppieren Sie einige Anwendungen mit speziellen regulatorischen Bedenken (z. B. PCI-DSS).
  • Isolieren Sie Anwendungen, die während Clusterupgrades besonders behandelt werden müssen (z. B. zustandsorientierte Anwendungen, die nichtflüchtige Volumes verwenden).
  • Isolieren Sie Anwendungen mit riskanten Sicherheitsprofilen (z. B. die Verarbeitung von Inhalten, die von Nutzern bereitgestellt werden, in einer speicherunsicheren Sprache).
  • Isolieren Sie Anwendungen, die GPUs, Kostenempfindlichkeit und Leistungsempfindlichkeit erfordern.
  • Wenn Sie das GKE-Clusterlimit für die Anzahl der Knoten (15.000 Knoten) fast erreicht haben, können Sie einen neuen Satz von Clustern erstellen.
  • Verwenden Sie eine andere freigegebene VPC für Anwendungen, die innerhalb eines VPC Service Controls-Perimeters ausgeführt werden müssen. Erstellen Sie einen Clustersatz im Perimeter und einen Cluster außerhalb des Perimeters.

Vermeiden Sie es, für jede Anwendung oder jeden Mandanten neue Cluster-Gruppen zu erstellen, da diese Vorgehensweise zu einem der folgenden Umstände führen kann:

  • Anwendungen, die die Mindestclustergröße (3 VMs x 2 Regionen) auch bei den kleinsten verfügbaren Instanztypen nicht gut nutzen.
  • Es wurde ein Potenzial für Kostensenkungen durch Bin-Packing verschiedener Anwendungen erkannt.
  • Mühsame und unsichere Kapazitätsplanung, da die Planung auf jede Anwendung einzeln angewendet wird. Vorhersagen zu Kapazitäten sind genauer, wenn sie für eine Vielzahl von Anwendungen zusammengefasst werden.
  • Verzögerungen beim Erstellen neuer Cluster für neue Mandanten oder Anwendungen, um die Zufriedenheit der Mandanten mit der Plattform zu verringern. In einigen Organisationen können die erforderlichen IP-Adresszuweisungen beispielsweise Zeit in Anspruch nehmen und zusätzliche Genehmigungen erfordern.
  • Das Limit für private Cluster in einem VPC-Netzwerk erreichen.

Produktions- und Nicht-Produktionsumgebungen haben Cluster in zwei Regionen.

Um eine niedrigere Latenz für Endnutzer in mehreren Regionen zu erreichen, können Sie die Produktions- und Nicht-Produktionsarbeitslasten in mehr als zwei Regionen bereitstellen (z. B. drei Regionen für die Produktion, drei Regionen für die Nicht-Produktion und eine Region für die Entwicklung). Diese Bereitstellungsstrategie erhöht die Kosten und den Aufwand für das Verwalten von Ressourcen in zusätzlichen Regionen.

Wenn alle Anwendungen niedrigere Verfügbarkeitsanforderungen haben, können Sie Produktions- und Nicht-Produktionsarbeitslasten nur in einer Region (eine Produktionsumgebung, eine Nicht-Produktionsumgebung und eine Entwicklungsumgebung) bereitstellen. Diese Strategie hilft, die Kosten zu senken, bietet jedoch nicht das gleiche Maß an Verfügbarkeit wie eine dual- oder multiregionale Architektur.

Wenn Anwendungen unterschiedliche Verfügbarkeitsanforderungen haben, können Sie verschiedene Cluster für verschiedene Anwendungen erstellen (z. B.cluster-set-1 mit zwei Produktionsumgebungen, zwei Nicht-Produktionsumgebungen und einer Entwicklungsumgebung cluster-set-2 mit einer Produktionsumgebung, einer Nicht-Produktionsumgebung und einer Entwicklungsumgebung.

Die Hub-and-Spoke-Topologie entspricht Ihren Anforderungen besser als die freigegebene VPC.

Sie können den Blueprint in einer Hub-and-Spoke-Konfiguration bereitstellen, wobei jede Umgebung (Entwicklung, Produktion und Nicht-Produktion) in einem eigenen Spoke gehostet wird. Die Hub-and-Spoke-Topologie kann die Trennung der Umgebungen erhöhen. Weitere Informationen finden Sie unter Hub-and-Spoke-Netzwerktopologie.

Jede Anwendung hat ein separates Git-Repository.

Einige Organisationen verwenden ein einziges Git-Repository (ein Monorepo) für den gesamten Quellcode anstelle mehrerer Repositories. Wenn Sie ein Monorepo verwenden, können Sie die Application Factory-Komponente des Blueprints so ändern, dass sie Ihr Repository unterstützt. Führen Sie Folgendes aus:

  • Anstatt für jede neue Anwendung ein neues Repository anzulegen, erstellen Sie ein Unterverzeichnis im vorhandenen Repository.
  • Anstatt der Anwendungsentwicklergruppe Inhaberberechtigungen für das neue Repository zu erteilen, erteilen Sie eine Schreibberechtigung für das vorhandene Repository und machen Sie die Anwendungsentwicklergruppe zu einem erforderlichen Prüfer für Änderungen am neuen Unterverzeichnis. Verwenden Sie das Feature CODEOWNERS und den Zweigschutz.

Nächste Schritte