Beim gespiegelten Muster wird das Design einer bestimmten vorhandenen Umgebung oder mehrerer vorhandener Umgebungen in einer neuen Umgebung oder mehreren neuen Umgebungen repliziert. Daher gilt dieses Muster hauptsächlich für Architekturen, die dem Umgebungshybrid-Muster folgen. Dabei werden Entwicklungs- und Testarbeitslasten in einer Umgebung und Staging- sowie Produktionsarbeitslasten in einer anderen Umgebung ausgeführt.
Beim gespiegelten Muster wird davon ausgegangen, dass Test- und Produktionsarbeitslasten nicht direkt miteinander kommunizieren sollen. Von Vorteil ist jedoch, wenn sich beide Arbeitslastgruppen konsistent verwalten lassen.
Wenn Sie dieses Muster verwenden, verbinden Sie die beiden Rechenumgebungen so, dass die folgenden Anforderungen erfüllt werden:
- Mithilfe von Continuous Integration/Continuous Deployment (CI/CD) können Arbeitslasten in allen oder bestimmten Rechenumgebungen bereitgestellt und verwaltet werden.
- Monitoring, Konfigurationsverwaltung und andere Verwaltungssysteme sollten in allen Rechenumgebungen funktionieren.
- Arbeitslasten können nicht direkt zwischen Rechenumgebungen kommunizieren. Falls erforderlich, muss die Kommunikation detailliert und kontrolliert erfolgen.
Architektur
Das folgende Architekturdiagramm zeigt eine allgemeine Referenzarchitektur dieses Musters, die CI/CD, Monitoring, Konfigurationsverwaltung, andere Verwaltungssysteme und die Arbeitslastkommunikation unterstützt:
Die Beschreibung der Architektur im vorherigen Diagramm sieht so aus:
- Arbeitslasten werden basierend auf den funktionalen Umgebungen (Entwicklung, Tests, CI/CD und Verwaltungstools) auf separate VPCs in Google Cloud verteilt.
- Die freigegebene VPC wird für Entwicklungs- und Testarbeitslasten verwendet. Für CI/CD und Verwaltungstools wird eine zusätzliche VPC verwendet. Bei freigegebenen VPCs:
- Die Anwendungen werden von verschiedenen Teams pro Umgebung und pro Dienstprojekt verwaltet.
- Das Hostprojekt verwaltet und steuert die Netzwerkkommunikation und die Sicherheitskontrollen zwischen der Entwicklungs- und der Testumgebung sowie außerhalb der VPC.
- Die CI/CD-VPC ist mit dem Netzwerk verbunden, in dem die Produktionsarbeitslasten in Ihrer privaten Rechenumgebung ausgeführt werden.
- Firewallregeln erlauben nur zulässigen Traffic.
- Sie können auch Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) verwenden, um Deep Packet Inspection zur Bedrohungsprävention zu implementieren, ohne das Design oder Routing zu ändern. Cloud Next Generation Firewall Enterprise erstellt von Google verwaltete zonale Firewall-Endpunkte, die Technologie zum Abfangen von Paketen verwenden, um die Arbeitslasten transparent auf die konfigurierten Bedrohungssignaturen zu prüfen. Außerdem schützt es Arbeitslasten vor Bedrohungen.
- Ermöglicht die Kommunikation zwischen den VPCs mit Peering über interne IP-Adressen.
- Das Peering in diesem Muster ermöglicht es, Entwicklungs- und Testarbeitslasten auf CI/CD- und Verwaltungssystemen bereitzustellen und zu verwalten.
- Beachten Sie die folgenden allgemeinen Best Practices.
Sie stellen diese CI/CD-Verbindung mit einer der oben beschriebenen Verbindungsoptionen für Hybrid- und Multi-Cloud-Netzwerke her, die Ihren Geschäfts- und Anwendungsanforderungen entspricht. Damit Sie Produktionsarbeitslasten bereitstellen und verwalten können, bietet diese Verbindung eine private Netzwerkerreichbarkeit zwischen den verschiedenen Rechenumgebungen. Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 haben.
Wenn die Instanzen in den Entwicklungs- und Testumgebungen Internetzugriff benötigen, können Sie die folgenden Optionen in Betracht ziehen:
- Sie können Cloud NAT im selben Netzwerk des freigegebene VPC-Hostprojekts bereitstellen. Durch die Bereitstellung im selben Netzwerk des freigegebene VPC-Hostprojekts wird verhindert, dass diese Instanzen direkt über das Internet zugänglich sind.
- Für ausgehenden Webtraffic können Sie den Sicheren Web-Proxy verwenden. Der Proxy bietet mehrere Vorteile.
Weitere Informationen zu den Google Cloud-Tools und ‑Funktionen, mit denen Sie in Google Cloud und in Hybrid- und Multi-Cloud-Umgebungen entwickeln, testen und bereitstellen können, finden Sie im Blogpost DevOps und CI/CD in Google Cloud.
Varianten
Das Architekturmuster gespiegelt bietet die folgenden Optionen, um verschiedene Designanforderungen zu erfüllen und gleichzeitig alle Kommunikationsanforderungen zu berücksichtigen:
- Freigegebene VPC pro Umgebung
- Zentrale Firewall der Anwendungsschicht
- Hub-and-Spoke-Topologie
- Verteilte Zero-Trust-Architektur für Mikrodienste
Freigegebene VPC pro Umgebung
Die Designoption „Freigegebene VPC pro Umgebung“ ermöglicht eine Trennung auf Anwendungs- oder Dienstebene über Umgebungen hinweg, einschließlich CI/CD- und Verwaltungstools, die zur Erfüllung bestimmter organisatorischer Sicherheitsanforderungen erforderlich sein können. Diese Anforderungen beschränken die Kommunikation, die Verwaltungsdomain und die Zugriffssteuerung für verschiedene Dienste, die auch von verschiedenen Teams verwaltet werden müssen.
Bei diesem Design wird die Trennung durch eine Isolation auf Netzwerk- und Projektebene zwischen den verschiedenen Umgebungen erreicht. Dies ermöglicht eine detailliertere Kommunikation und Zugriffssteuerung durch die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM).
Aus Sicht der Verwaltung und des Betriebs bietet dieses Design die Flexibilität, die von verschiedenen Teams erstellten Anwendungen und Arbeitslasten pro Umgebung und pro Dienstprojekt zu verwalten. VPC-Netzwerke und ihre Sicherheitsfunktionen können von Netzwerkteams basierend auf den folgenden möglichen Strukturen bereitgestellt und verwaltet werden:
- Ein Team verwaltet alle Hostprojekte in allen Umgebungen.
- Die Hostprojekte in den jeweiligen Umgebungen werden von verschiedenen Teams verwaltet.
Entscheidungen zur Verwaltung von Hostprojekten sollten auf der Teamstruktur, den Sicherheitsabläufen und den Zugriffsanforderungen der einzelnen Teams basieren. Sie können diese Designvariante auf die Designoption „Freigegebenes VPC-Netzwerk für jede Umgebung“ anwenden. Sie müssen jedoch die Kommunikationsanforderungen des gespiegelten Musters berücksichtigen, um zu definieren, welche Kommunikation zwischen den verschiedenen Umgebungen zulässig ist, einschließlich der Kommunikation über das Hybridnetzwerk.
Sie können auch ein freigegebene VPC-Netzwerk für jede Hauptumgebung bereitstellen, wie im folgenden Diagramm dargestellt:
Zentrale Firewall der Anwendungsebene
In einigen Fällen erfordern die Sicherheitsanforderungen die Berücksichtigung der Anwendungsschicht (Layer 7) und der detaillierten Paketprüfung mit erweiterten Firewallmechanismen, die über die Möglichkeiten der Cloud Next Generation Firewall hinausgehen. Um die Sicherheitsanforderungen und -standards Ihrer Organisation zu erfüllen, können Sie eine NGFW-Appliance verwenden, die in einer virtuellen Netzwerk-Appliance (NVA) gehostet wird. Mehrere Sicherheitspartner von Google Cloud bieten Optionen, die sich gut für diese Aufgabe eignen.
Wie im folgenden Diagramm dargestellt, können Sie die NVA mithilfe von mehreren Netzwerkschnittstellen in den Netzwerkpfad zwischen der Virtual Private Cloud und der privaten Rechenumgebung einfügen.
Dieses Design kann auch mit mehreren freigegebenen VPCs verwendet werden, wie im folgenden Diagramm dargestellt.
Die NVA in diesem Design dient als Perimeter-Sicherheitsschicht. Außerdem dient sie als Grundlage für die Aktivierung der Inline-Traffic-Prüfung und die Durchsetzung strenger Zugriffssteuerungsrichtlinien.
Für eine robuste mehrschichtige Sicherheitsstrategie, die VPC-Firewallregeln und Funktionen für den Dienst zur Einbruchsprävention umfasst, sollten Sie sowohl für Ost-West- als auch für Nord-Süd-Trafficflüsse weitere Traffic-Inspektionen und Sicherheitskontrollen einrichten.
Hub-and-Spoke-Topologie
Eine weitere mögliche Designvariante besteht darin, separate VPCs (einschließlich freigegebener VPCs) für die Entwicklung und verschiedene Testphasen zu verwenden. In dieser Variante, wie im folgenden Diagramm dargestellt, sind alle Staging-Umgebungen in einer Hub-and-Spoke-Architektur mit der CI/CD- und der Verwaltungs-VPC verbunden. Verwenden Sie diese Option, wenn Sie die Verwaltungsdomains und die Funktionen in jeder Umgebung trennen müssen. Das Hub-and-Spoke-Kommunikationsmodell kann bei den folgenden Anforderungen helfen:
- Anwendungen müssen auf eine Reihe gängiger Dienste zugreifen können, z. B. auf Monitoring, Konfigurationsverwaltungstools, CI/CD oder Authentifizierung.
- Gemeinsame Sicherheitsrichtlinien müssen zentral über den Hub auf eingehenden und ausgehenden Traffic angewendet werden.
Weitere Informationen zu Hub-and-Spoke-Designoptionen finden Sie unter Hub-and-Spoke-Topologie mit zentralisierten Appliances und Hub-and-Spoke-Topologie ohne zentralisierte Appliances.
Wie im vorherigen Diagramm dargestellt, laufen die VPC-interne Kommunikation und die hybride Konnektivität alle über das Hub-VPC. Im Rahmen dieses Musters können Sie die Kommunikation im Hub-VPC steuern und einschränken, um sie an Ihre Konnektivitätsanforderungen anzupassen.
Im Rahmen der Hub-and-Spoke-Netzwerkarchitektur sind dies die wichtigsten Konnektivitätsoptionen (zwischen den Spoke- und Hub-VPCs) in Google Cloud:
- VPC-Netzwerk-Peering
- VPN
- Virtuelle Netzwerk-Appliance (NVA) verwenden
- Mit mehreren Netzwerkschnittstellen
- Mit dem Network Connectivity Center (NCC)
Weitere Informationen dazu, welche Option Sie in Ihrem Design berücksichtigen sollten, finden Sie unter Hub-and-Spoke-Netzwerkarchitektur. Ein wichtiger Einflussfaktor für die Auswahl von VPN über VPC-Peering zwischen den Spokes und dem Hub-VPC ist, ob Traffic-Transitivit erforderlich ist. Die Traffic-Transitivität bedeutet, dass Traffic von einem Spoke andere Spokes über den Hub erreichen kann.
Verteilte Zero-Trust-Architektur für Mikrodienste
Für Hybrid- und Multi-Cloud-Architekturen können mehrere Cluster erforderlich sein, um die technischen und geschäftlichen Ziele zu erreichen. Dazu gehört auch die Trennung der Produktionsumgebung von der Entwicklungs- und Testumgebung. Daher sind Sicherheitskontrollen für den Netzwerkperimeter wichtig, insbesondere wenn sie zur Einhaltung bestimmter Sicherheitsanforderungen erforderlich sind.
Es reicht nicht aus, die Sicherheitsanforderungen der aktuellen cloudbasierten verteilten Mikrodienstarchitekturen zu erfüllen. Sie sollten auch verteilte Zero-Trust-Architekturen in Betracht ziehen. Die verteilte Zero-Trust-Architektur für Mikrodienste unterstützt Ihre Mikrodienstarchitektur mit Erzwingung von Sicherheitsrichtlinien, Authentifizierung und Arbeitslastidentität auf Mikrodienstebene. Das Vertrauen ist identitätsbasiert und wird für jeden Dienst erzwungen.
Mit einer verteilten Proxyarchitektur wie einem Service Mesh können Dienste Anrufer effektiv validieren und für jede Anfrage detaillierte Zugriffssteuerungsrichtlinien implementieren. So wird eine sicherere und skalierbarere Mikrodienstumgebung ermöglicht. Mit Cloud Service Mesh können Sie ein gemeinsames Mesh-Netzwerk verwenden, das sowohl Ihre Google Cloud-Bereitstellungen als auch lokale Bereitstellungen umfasst. Das Mesh verwendet Autorisierungsrichtlinien, um die Dienst-zu-Dienst-Kommunikation zu sichern.
Sie können auch den Apigee Adapter for Envoy, eine schlanke Apigee API-Gateway-Bereitstellung in einem Kubernetes-Cluster, in diese Architektur einbinden. Apigee Adapter for Envoy ist ein Open-Source-Edge- und -Dienstproxy, der für cloudbasierte Anwendungen entwickelt wurde.
Weitere Informationen zu diesem Thema finden Sie in den folgenden Artikeln:
- Verteilte Zero-Trust-Architektur
- Hybride GKE Enterprise-Umgebung
- Mit Google verbinden
- Sie können einen lokalen GKE Enterprise-Cluster mit einem Google Cloud-Netzwerk verbinden.
- Multi-Cloud- oder Hybrid-Mesh einrichten
- Cloud Service Mesh in verschiedenen Umgebungen und Clustern bereitstellen
Best Practices für gespiegelte Muster
- Die für die Bereitstellung oder Neukonfiguration von Produktionsbereitstellungen erforderlichen CI/CD-Systeme müssen hochverfügbar sein. Das bedeutet, dass alle Architekturkomponenten so konzipiert sein müssen, dass die erwartete Systemverfügbarkeit erreicht wird. Weitere Informationen finden Sie unter Zuverlässigkeit der Google Cloud-Infrastruktur.
- Um Konfigurationsfehler bei wiederkehrenden Prozessen wie Codeaktualisierungen zu vermeiden, ist die Automatisierung zur Standardisierung Ihrer Builds, Tests und Bereitstellungen unerlässlich.
- Die Integration zentralisierter NVAs in dieses Design erfordert möglicherweise die Einbindung mehrerer Segmente mit unterschiedlichen Sicherheitszugriffssteuerungen.
- Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen einzelnen Fehlerpunkt zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie der Anleitung Ihres NVA-Anbieters für die HA- und Redundanz-Design- und -Implementierung.
- Wenn Sie lokale IP-Routen nicht über VPC-Peering oder VPN in die VPC für Entwicklung und Tests exportieren, können Sie die Netzwerkerreichbarkeit von Entwicklungs- und Testumgebungen auf die lokale Umgebung beschränken. Weitere Informationen finden Sie unter Austausch benutzerdefinierter Routen beim VPC-Netzwerk-Peering.
- Für Arbeitslasten mit privater IP-Adressierung, für die der Zugriff auf Google APIs erforderlich sein kann, können Sie Google APIs mithilfe eines Private Service Connect-Endpunkts in einem VPC-Netzwerk verfügbar machen. Weitere Informationen finden Sie in dieser Reihe unter Gated Ingress.
- Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkarchitekturmuster.