Il pattern specchiato si basa sulla replica della progettazione di uno o più ambienti esistenti in uno o più nuovi ambienti. Pertanto, questo pattern si applica principalmente alle architetture che seguono il pattern ibrido per ambiente. In questo pattern, esegui i carichi di lavoro di sviluppo e test in un ambiente, mentre esegui i carichi di lavoro di gestione temporanea e produzione in un altro.
Il pattern mirroring presuppone che i workload di test e di produzione non debbano comunicare direttamente tra loro. Tuttavia, dovrebbe essere possibile gestire ed eseguire il deployment di entrambi i gruppi di carichi di lavoro in modo coerente.
Se utilizzi questo pattern, collega i due ambienti di computing in modo da rispettare i seguenti requisiti:
- L'integrazione continua/deployment continuo (CI/CD) può eseguire il deployment e gestire i carichi di lavoro in tutti gli ambienti di computing o in ambienti specifici.
- I sistemi di monitoraggio, gestione della configurazione e altri sistemi amministrativi devono funzionare in tutti gli ambienti di computing.
- I carichi di lavoro non possono comunicare direttamente tra ambienti di computing. Se necessario, la comunicazione deve avvenire in modo controllato e granulare.
Architettura
Il seguente diagramma dell'architettura mostra un'architettura di riferimento di alto livello di questo pattern che supporta CI/CD, monitoraggio, gestione della configurazione, altri sistemi amministrativi e comunicazione dei carichi di lavoro:
La descrizione dell'architettura nel diagramma precedente è la seguente:
- I carichi di lavoro vengono distribuiti in base agli ambienti funzionali (sviluppo, test, CI/CD e strumenti amministrativi) in VPC separati sul lato Google Cloud .
- VPC condiviso
viene utilizzato per i carichi di lavoro di sviluppo e test. Un VPC aggiuntivo viene utilizzato per
gli strumenti CI/CD e amministrativi. Con i VPC condivisi:
- Le applicazioni sono gestite da team diversi per ambiente e per progetto di servizio.
- Il progetto host amministra e controlla la comunicazione di rete e i controlli di sicurezza tra gli ambienti di sviluppo e test, nonché all'esterno del VPC.
- Il VPC CI/CD è connesso alla rete che esegue i carichi di lavoro di produzione nel tuo ambiente di computing privato.
- Le regole firewall consentono solo il traffico consentito.
- Puoi anche utilizzare Cloud Next Generation Firewall Enterprise con il servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti per la prevenzione delle minacce senza modificare la progettazione o il routing. Cloud Next Generation Firewall Enterprise funziona creando endpoint firewall zonali gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i workload per le firme delle minacce configurate. Protegge inoltre i carichi di lavoro dalle minacce.
- Consente la comunicazione tra i VPC sottoposti a peering utilizzando indirizzi IP interni.
- Il peering in questo pattern consente ai sistemi CI/CD e amministrativi di eseguire il deployment e gestire i carichi di lavoro di sviluppo e test.
- Prendi in considerazione queste best practice generali.
Stabilisci questa connessione CI/CD utilizzando una delle opzioni di connettività di rete ibrida e multi-cloud che soddisfano i requisiti della tua attività e delle tue applicazioni. Per consentirti di eseguire il deployment e gestire i carichi di lavoro di produzione, questa connessione fornisce la raggiungibilità della rete privata tra i diversi ambienti di computing. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
Se le istanze negli ambienti di sviluppo e test richiedono l'accesso a internet, valuta le seguenti opzioni:
- Puoi eseguire il deployment di Cloud NAT nella stessa rete del progetto host VPC condiviso. Il deployment nella stessa rete del progetto host VPC condiviso consente di evitare di rendere queste istanze direttamente accessibili da internet.
- Per il traffico web in uscita, puoi utilizzare Secure Web Proxy. Il proxy offre diversi vantaggi.
Per saperne di più sugli Google Cloud strumenti e sulle funzionalità che ti aiutano a creare, testare ed eseguire il deployment in Google Cloud e in ambienti ibridi e multicloud, consulta il blog DevOps e CI/CD su Google Cloud spiegati.
Varianti
Per soddisfare diversi requisiti di progettazione, tenendo comunque conto di tutti i requisiti di comunicazione, il pattern di architettura mirroring offre queste opzioni, descritte nelle sezioni seguenti:
- VPC condiviso per ambiente
- Firewall centralizzato a livello di applicazione
- Topologia hub e spoke
- Architettura distribuita Zero Trust basata su microservizi
VPC condiviso per ambiente
L'opzione di progettazione VPC condiviso per ambiente consente la separazione a livello di applicazione o servizio tra gli ambienti, inclusi CI/CD e strumenti amministrativi che potrebbero essere necessari per soddisfare determinati requisiti di sicurezza dell'organizzazione. Questi requisiti limitano la comunicazione, il dominio amministrativo e controllo dell'accesso per diversi servizi che devono essere gestiti anche da team diversi.
Questo design consente la separazione fornendo l'isolamento a livello di rete e progetto tra i diversi ambienti, il che consente una comunicazione più granulare e controllo dell'accesso dell'accesso Identity and Access Management (IAM).
Dal punto di vista della gestione e delle operazioni, questo design offre la flessibilità di gestire le applicazioni e i workload creati da team diversi per ambiente e per progetto di servizio. Il networking VPC e le relative funzionalità di sicurezza possono essere sottoposti a provisioning e gestiti dai team di operazioni di networking in base alle seguenti possibili strutture:
- Un team gestisce tutti i progetti host in tutti gli ambienti.
- Team diversi gestiscono i progetti host nei rispettivi ambienti.
Le decisioni relative alla gestione dei progetti host devono basarsi sulla struttura del team, sulle operazioni di sicurezza e sui requisiti di accesso di ciascun team. Puoi applicare questa variante di progettazione alla rete VPC condivisa per ogni opzione di progettazione della landing zone dell'ambiente. Tuttavia, devi considerare i requisiti di comunicazione del pattern mirror per definire quale comunicazione è consentita tra i diversi ambienti, inclusa la comunicazione sulla rete ibrida.
Puoi anche eseguire il provisioning di una rete VPC condiviso per ogni ambiente principale, come illustrato nel seguente diagramma:
Firewall centralizzato a livello di applicazione
In alcuni scenari, i requisiti di sicurezza potrebbero richiedere la considerazione del livello applicazione (livello 7) e dell'ispezione approfondita dei pacchetti con meccanismi di firewalling avanzati che superano le funzionalità di Cloud Next Generation Firewall. Per soddisfare i requisiti e gli standard di sicurezza della tua organizzazione, puoi utilizzare un'appliance NGFW ospitata in un'appliance virtuale di rete (NVA). Diversi Google Cloud partner per la sicurezza offrono opzioni adatte a questa attività.
Come illustrato nel seguente diagramma, puoi inserire la NVA nel percorso di rete tra Virtual Private Cloud e l'ambiente di computing privato utilizzando più interfacce di rete.
Questo design può essere utilizzato anche con più VPC condivisi, come illustrato nel diagramma seguente.
La NVA in questa progettazione funge da livello di sicurezza perimetrale. Servono anche come base per l'attivazione dell'ispezione del traffico inline e l'applicazione di criteri di controllo dell'accesso dell'accesso rigorosi.
Per una strategia di sicurezza multilivello solida che includa regole firewall VPC e funzionalità di servizio di prevenzione delle intrusioni, includi un'ulteriore ispezione del traffico e un controllo di sicurezza per i flussi di traffico sia est-ovest che nord-sud.
Topologia hub-and-spoke
Un'altra possibile variante di progettazione è l'utilizzo di VPC separati (inclusi i VPC condivisi) per lo sviluppo e le diverse fasi di test. In questa variante, come mostrato nel seguente diagramma, tutti gli ambienti di staging si connettono al VPC CI/CD e amministrativo in un'architettura hub-and-spoke. Utilizza questa opzione se devi separare i domini amministrativi e le funzioni in ogni ambiente. Il modello di comunicazione hub-and-spoke può aiutarti con i seguenti requisiti:
- Le applicazioni devono accedere a un insieme comune di servizi, come monitoraggio, strumenti di gestione della configurazione, CI/CD o autenticazione.
- Un insieme comune di criteri di sicurezza deve essere applicato al traffico in entrata e in uscita in modo centralizzato tramite l'hub.
Per ulteriori informazioni sulle opzioni di progettazione hub-and-spoke, vedi Topologia hub-and-spoke con appliance centralizzate e Topologia hub-and-spoke senza appliance centralizzate.
Come mostrato nel diagramma precedente, la comunicazione tra VPC e la connettività ibrida passano tutte attraverso il VPC hub. Nell'ambito di questo pattern, puoi controllare e limitare la comunicazione nel VPC hub in modo che sia in linea con i tuoi requisiti di connettività.
Nell'ambito dell'architettura di rete hub e spoke, le seguenti sono le opzioni di connettività principali (tra i VPC spoke e hub) su Google Cloud:
- Peering di rete VPC
- VPN
- Utilizzo dell'appliance virtuale di rete (NVA)
- Con più interfacce di rete
- Con Network Connectivity Center (NCC)
Per ulteriori informazioni su quale opzione devi prendere in considerazione nella progettazione, consulta Architettura di rete hub-and-spoke. Un fattore chiave che influenza la scelta della VPN rispetto al peering VPC tra gli spoke e il VPC hub è quando è richiesta la transitività del traffico. La transitività del traffico significa che il traffico di uno spoke può raggiungere altri spoke tramite l'hub.
Architettura distribuita Zero Trust dei microservizi
Le architetture ibride e multi-cloud possono richiedere più cluster per raggiungere i propri obiettivi tecnici e commerciali, inclusa la separazione dell'ambiente di produzione dagli ambienti di sviluppo e test. Pertanto, i controlli di sicurezza del perimetro di rete sono importanti, soprattutto quando sono necessari per rispettare determinati requisiti di sicurezza.
Non è sufficiente supportare i requisiti di sicurezza delle attuali architetture di microservizi distribuite cloud-first, ma devi anche prendere in considerazione le architetture distribuite Zero Trust. L'architettura distribuita Zero Trust dei microservizi supporta l'architettura dei microservizi con l'applicazione di criteri di sicurezza a livello di microservizio, l'autenticazione e l'identità del carico di lavoro. L'attendibilità è basata sull'identità e applicata a ogni servizio.
Utilizzando un'architettura proxy distribuita, come un mesh di servizi, i servizi possono convalidare in modo efficace i chiamanti e implementare criteri di controllo dell'accesso granulari per ogni richiesta, consentendo un ambiente di microservizi più sicuro e scalabile. Cloud Service Mesh ti offre la flessibilità di disporre di un mesh comune che può estendersi ai tuoi deploymentGoogle Cloud e on-premise. Il mesh utilizza criteri di autorizzazione per proteggere le comunicazioni da servizio a servizio.
Potresti anche incorporare Apigee Adapter for Envoy, che è un deployment leggero del gateway API Apigee all'interno di un cluster Kubernetes, con questa architettura. Apigee Adapter for Envoy è un proxy di servizio e edge open source progettato per applicazioni cloud-first.
Per ulteriori informazioni su questo argomento, leggi i seguenti articoli:
- Architettura distribuita Zero Trust
- Ambiente ibrido Google Kubernetes Engine (GKE)
- Connetti a Google
- Connetti un cluster on-premise a una reteGoogle Cloud .
- Configura un mesh multi-cloud o ibrido
- Esegui il deployment di Cloud Service Mesh in ambienti e cluster.
Best practice per il pattern a specchio
- I sistemi CI/CD necessari per il deployment o la riconfigurazione dei deployment di produzione devono essere ad alta disponibilità, il che significa che tutti i componenti dell'architettura devono essere progettati per fornire il livello di disponibilità del sistema previsto. Per saperne di più, consulta la sezione relativa all'affidabilità dell'infrastruttura.Google Cloud
- Per eliminare gli errori di configurazione per i processi ripetuti come gli aggiornamenti del codice, l'automazione è essenziale per standardizzare le build, i test e i deployment.
- L'integrazione di NVA centralizzate in questa progettazione potrebbe richiedere l'incorporazione di più segmenti con diversi livelli di controlli di accesso alla sicurezza.
- Quando progetti una soluzione che include NVA, è importante considerare l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni per la progettazione e l'implementazione dell'alta disponibilità e della ridondanza fornite dal fornitore della NVA.
- Se non esporti le route IP on-premise tramite il peering VPC o la VPN nel VPC di sviluppo e test, puoi limitare la raggiungibilità della rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta Scambio di route personalizzate del peering di rete VPC.
- Per i carichi di lavoro con indirizzamento IP privato che possono richiedere l'accesso alle API di Google, puoi esporre le API di Google utilizzando un endpoint Private Service Connect all'interno di una rete VPC. Per saperne di più, consulta Ingresso controllato, in questa serie.
- Consulta le best practice generali per i modelli di architettura di rete ibrida e multicloud.