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:
Erstellen Sie Ihre grundlegende Infrastruktur mit dem Blueprint für Unternehmensgrundlagen. Führen Sie Folgendes aus:
- Erstellen Sie eine Organisationsstruktur, einschließlich Ordnern für die Trennung von Umgebungen.
- Grundlegende IAM-Berechtigungen konfigurieren, um Zugriff auf Entwicklerplattformadministratoren zu gewähren
- VPC-Netzwerk erstellen.
- Grundlageninfrastruktur-Pipeline bereitstellen.
Wenn Sie den Blueprint zu Unternehmensgrundlagen nicht verwenden, finden Sie weitere Informationen unter Blueprint ohne Unternehmens-Blueprint bereitstellen.
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.
Der Entwicklerplattformadministrator verwendet die mehrmandantenfähige Infrastrukturpipeline, um GKE-Cluster und eine gemeinsam genutzte Infrastruktur bereitzustellen.
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.
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:
- Erstellen Sie die folgenden Ressourcen:
- Eine Organisationshierarchie mit den Ordnern
development
,nonproduction
undproduction
- 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
- Eine Organisationshierarchie mit den Ordnern
- 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 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 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:
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:
|
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. |
|
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:
|
Nächste Schritte
- Weitere Informationen zum Blueprint für Unternehmensgrundlagen
- Weitere Informationen zur Softwarebereitstellung in Google Cloud finden Sie hier:
- Weitere Informationen zum Ausführen von Anwendungen in GKE finden Sie unter:
- Best Practices für die Containererstellung
- Best Practices für GKE-Netzwerke
- Best Practices für die GKE-Mehrmandantenfähigkeit in Unternehmen
- Best Practices für den Betrieb von Containern
- Best Practices zum Ausführen kostenoptimierter Kubernetes-Anwendungen in GKE
- GKE sicherer Cluster-Repository
- Die Sicherheit Ihres Clusters erhöhen