Das Gespiegelt-Muster basiert auf der Replikation des Designs einer oder mehrerer vorhandener Umgebungen in eine oder mehrere neue Umgebungen. Daher gilt dieses Muster hauptsächlich für Architekturen, die dem Umgebungshybridmuster entsprechen. Bei diesem Muster 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, müssen Sie die beiden Rechenumgebungen so verbinden, dass die folgenden Anforderungen erfüllt werden:
- Systeme für die kontinuierliche Integration und Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD) können Arbeitslasten in allen oder bestimmten Rechenumgebungen bereitstellen und verwalten.
- Monitoring-, Konfigurationsverwaltungs- 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 administrative Systeme und die Kommunikation von Arbeitslasten unterstützt:
Die Architektur im vorherigen Diagramm wird so beschrieben:
- Arbeitslasten werden basierend auf den funktionalen Umgebungen (Entwicklung, Tests, CI/CD und Verwaltungstools) auf separate VPCs auf der Google Cloud Seite verteilt.
- Die freigegebene VPC wird für Entwicklungs- und Testarbeitslasten verwendet. Für die CI/CD- und Verwaltungstools wird eine zusätzliche VPC verwendet. Bei gemeinsam genutzten VPCs:
- Die Anwendungen werden von verschiedenen Teams pro Umgebung und pro Dienstprojekt verwaltet.
- Das Hostprojekt verwaltet und steuert die Netzwerkkommunikation und Sicherheitskontrollen zwischen den Entwicklungs- und Testumgebungen 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 lassen nur zulässigen Traffic zu.
- Sie können auch Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) verwenden, um eine Deep Packet Inspection zur Bedrohungsprävention ohne Design- oder Routingänderungen durchzuführen. 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 werden Arbeitslasten vor Bedrohungen geschützt.
- Ermöglicht die Kommunikation zwischen den verbundenen VPCs ü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 allgemeinen Best Practices.
Sie stellen diese CI/CD-Verbindung mit einer der besprochenen Hybrid- und Multi-Cloud-Netzwerkverbindungsoptionen her, die Ihren Geschäfts- und Anwendungsanforderungen entspricht. Damit Sie Produktionsarbeitslasten bereitstellen und verwalten können, bietet diese Verbindung eine private Netzwerkverfügbarkeit 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, sollten Sie die folgenden Optionen in Betracht ziehen:
- Sie können Cloud NAT im selben Netzwerk des Hostprojekts für die freigegebene VPC 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 Webproxy 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 Blogbeitrag DevOps und CI/CD auf Google Cloud .
Varianten
Um unterschiedliche Designanforderungen zu erfüllen und gleichzeitig alle Kommunikationsanforderungen zu berücksichtigen, bietet das gespiegelte-Architekturmuster die folgenden Optionen, die in den folgenden Abschnitten beschrieben werden:
- Freigegebene VPC pro Umgebung
- Zentrale Firewall auf Anwendungsebene
- Hub-and-Spoke-Topologie
- Verteilte Zero-Trust-Architektur für Mikrodienste
Freigegebene VPC pro Umgebung
Die Designoption „Freigegebene VPC pro Umgebung“ ermöglicht die Trennung auf Anwendungs- oder Dienstebene über Umgebungen hinweg, einschließlich CI/CD- und Verwaltungstools, die möglicherweise erforderlich sind, um bestimmte Sicherheitsanforderungen der Organisation zu erfüllen. Diese Anforderungen schränken die Kommunikation, die administrative Domain und die Zugriffssteuerung für verschiedene Dienste ein, die auch von verschiedenen Teams verwaltet werden müssen.
Dieses Design bietet eine Trennung durch Isolation auf Netzwerk- und Projektebene zwischen den verschiedenen Umgebungen, was eine detailliertere Kommunikation und IAM-Zugriffssteuerung ermöglicht.
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 Netzwerkbetriebsteams auf Grundlage der folgenden möglichen Strukturen bereitgestellt und verwaltet werden:
- Ein Team verwaltet alle Hostprojekte in allen Umgebungen.
- Die Hostprojekte werden von verschiedenen Teams in den jeweiligen Umgebungen verwaltet.
Entscheidungen zur Verwaltung von Hostprojekten sollten auf der Teamstruktur, den Sicherheitsvorgängen und den Zugriffsanforderungen der einzelnen Teams basieren. Sie können diese Designvariante auf die Landing-Zone-Designoption „Freigegebenes VPC-Netzwerk für jede Umgebung“ anwenden. Sie müssen jedoch die Kommunikationsanforderungen des gespiegelten-Musters berücksichtigen, um festzulegen, welche Kommunikation zwischen den verschiedenen Umgebungen zulässig ist, einschließlich der Kommunikation über das Hybridnetzwerk.
Sie können auch für jede Hauptumgebung ein freigegebene VPC-Netzwerk bereitstellen, wie im folgenden Diagramm dargestellt:
Zentrale Firewall auf Anwendungsebene
In einigen Szenarien erfordern die Sicherheitsanforderungen möglicherweise die Berücksichtigung der Anwendungsschicht (Layer 7) und eine Deep Packet Inspection mit erweiterten Firewallmechanismen, die über die Funktionen 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 Google Cloud Sicherheitspartner bieten Optionen an, 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. Sie dient auch als Grundlage für die Inline-Traffic-Prüfung und die Durchsetzung strenger Zugriffssteuerungsrichtlinien.
Für eine robuste mehrschichtige Sicherheitsstrategie, die VPC-Firewallregeln und Funktionen zur Einbruchsprävention umfasst, sollten Sie sowohl Ost-West- als auch Nord-Süd-Traffic-Flows einer weiteren Traffic-Prüfung und Sicherheitskontrolle unterziehen.
Hub-and-Spoke-Topologie
Eine weitere mögliche Designvariante ist die Verwendung separater VPCs (einschließlich freigegebener VPCs) für die Entwicklung und verschiedene Testphasen. In dieser Variante, wie im folgenden Diagramm dargestellt, sind alle Staging-Umgebungen in einer Hub-and-Spoke-Architektur mit der CI/CD- und der administrativen 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 gemeinsamer Dienste zugreifen, z. B. Monitoring, Konfigurationsverwaltungstools, CI/CD oder Authentifizierung.
- Ein gemeinsamer Satz von Sicherheitsrichtlinien muss 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 obigen Diagramm dargestellt, erfolgt die VPC-übergreifende Kommunikation und die Hybridkonnektivität über die Hub-VPC. Im Rahmen dieses Musters können Sie die Kommunikation in der Hub-VPC steuern und einschränken, um sie an Ihre Konnektivitätsanforderungen anzupassen.
Im Rahmen der Hub-and-Spoke-Netzwerkarchitektur sind die folgenden die primären Verbindungsoptionen (zwischen den Spoke- und Hub-VPCs) auf 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 in Betracht ziehen sollten, finden Sie unter Hub-and-Spoke-Netzwerkarchitektur. Ein wichtiger Faktor bei der Auswahl von VPN gegenüber VPC-Peering zwischen den Spoke- und Hub-VPCs ist, wenn Traffic-Transitivität erforderlich ist. 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 sind möglicherweise mehrere Cluster erforderlich, um die technischen und geschäftlichen Ziele zu erreichen, einschließlich der Trennung der Produktionsumgebung von den Entwicklungs- und Testumgebungen. Daher sind Sicherheitskontrollen für den Netzwerkperimeter wichtig, insbesondere wenn sie zur Einhaltung bestimmter Sicherheitsanforderungen erforderlich sind.
Es reicht nicht aus, die Sicherheitsanforderungen aktueller Cloud-First-Architekturen mit verteilten Mikrodiensten zu unterstützen. Sie sollten auch verteilte Zero-Trust-Architekturen in Betracht ziehen. Die verteilte Zero-Trust-Architektur für Mikrodienste unterstützt Ihre Mikrodienstarchitektur mit der Erzwingung von Sicherheitsrichtlinien auf Mikrodienstebene, Authentifizierung und Workload Identity. Vertrauen ist identitätsbasiert und wird für jeden Dienst erzwungen.
Durch die Verwendung einer verteilten Proxyarchitektur wie einem Service Mesh können Dienste Anrufer effektiv validieren und detaillierte Zugriffssteuerungsrichtlinien für jede Anfrage implementieren. Dies ermöglicht eine sicherere und skalierbare Mikrodienstumgebung. Cloud Service Mesh bietet Ihnen die Flexibilität, ein gemeinsames Mesh-Netzwerk zu verwenden, das sowohl IhreGoogle Cloud - als auch Ihre lokalen Bereitstellungen umfassen kann. Im Mesh werden Autorisierungsrichtlinien verwendet, um die Dienst-zu-Dienst-Kommunikation zu sichern.
Sie können auch den Apigee-Adapter für Envoy in diese Architektur einbinden. Dabei handelt es sich um eine schlanke Apigee API-Gateway-Bereitstellung in einem Kubernetes-Cluster. Apigee Adapter for Envoy ist ein Open-Source-Edge- und ‑Dienstproxy, der für Cloud-First-Anwendungen entwickelt wurde.
Weitere Informationen zu diesem Thema finden Sie in den folgenden Artikeln:
- Verteilte Zero-Trust-Architektur
- Hybride Google Kubernetes Engine-Umgebung (GKE)
- Mit Google verbinden
- Verbinden Sie einen lokalen Cluster mit einemGoogle Cloud -Netzwerk.
- Multi-Cloud- oder Hybrid-Mesh einrichten
- Cloud Service Mesh in 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 sie die erwartete Systemverfügbarkeit bieten. Weitere Informationen finden Sie unter Google Cloud Infrastrukturzuverlässigkeit.
- Um Konfigurationsfehler bei wiederkehrenden Prozessen wie Codeaktualisierungen zu vermeiden, ist die Automatisierung unerlässlich, um Ihre Builds, Tests und Bereitstellungen zu standardisieren.
- Die Integration zentralisierter NVAs in dieses Design erfordert möglicherweise die Einbeziehung mehrerer Segmente mit unterschiedlichen Ebenen für die Sicherheitszugriffssteuerung.
- Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen Single Point of Failure zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie den Design- und Implementierungsrichtlinien für HA und Redundanz Ihres NVA-Anbieters.
- Wenn Sie keine lokalen IP-Routen über VPC-Peering oder VPN in die VPC für Entwicklung und Tests exportieren, können Sie die Netzwerkerreichbarkeit von Entwicklungs- und Testumgebungen zur lokalen Umgebung einschränken. Weitere Informationen finden Sie unter Benutzerdefinierte Routen für VPC-Netzwerk-Peering austauschen.
- Für Arbeitslasten mit privater IP-Adressierung, die Zugriff auf Google APIs erfordern, können Sie Google APIs über einen Private Service Connect-Endpunkt 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.