Il pattern in mirror si basa sulla replica del design di uno o più ambienti esistenti in uno o più nuovi ambienti. Pertanto, questo pattern si applica principalmente alle architetture che seguono il pattern ambiente ibrido. In questo modello, esegui i carichi di lavoro di sviluppo e test in un ambiente e quelli di gestione temporanea e produzione in un altro.
Il pattern speculare 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 calcolo in modo che siano in linea con i seguenti requisiti:
- L'integrazione e il deployment continui (CI/CD) possono eseguire il deployment e gestire i carichi di lavoro in tutti gli ambienti di calcolo o in ambienti specifici.
- Il monitoraggio, la gestione della configurazione e altri sistemi amministrativi devono funzionare in tutti gli ambienti di calcolo.
- I carichi di lavoro non possono comunicare direttamente tra ambienti di calcolo. Se necessario, la comunicazione deve essere granulare e controllata.
Architettura
Il seguente diagramma di 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 distinte lato Google Cloud.
- La VPC condivisa viene utilizzata per i carichi di lavoro di sviluppo e test. Viene utilizzata un'altra VPC per gli strumenti di CI/CD e di amministrazione. Con i VPC condivisi:
- Le applicazioni sono gestite da team diversi per ambiente e per progetto di servizio.
- Il progetto host amministra e controlla i controlli di sicurezza e di comunicazione di rete tra gli ambienti di sviluppo e di test, nonché all'esterno del VPC.
- La VPC CI/CD è connessa alla rete su cui vengono eseguiti i carichi di lavoro di produzione nel tuo ambiente di calcolo privato.
- Le regole del firewall consentono solo il traffico consentito.
- Puoi anche utilizzare Cloud Next Generation Firewall Enterprise con servizio di prevenzione delle intrusioni (IPS) per implementare l'ispezione approfondita dei pacchetti al fine di prevenire le minacce senza modificare la progettazione o il routing. Cloud Next Generation Firewall Enterprise funziona creando endpoint di firewall zonali gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i workload alla ricerca delle firme di minacce configurate. Protegge inoltre i carichi di lavoro dalle minacce.
- Consente la comunicazione tra i VPC accoppiati utilizzando indirizzi IP interni.
- Il peering in questo pattern consente ai sistemi di 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 multicloud discusse 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 calcolo. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizioni.
Se le istanze negli ambienti di sviluppo e test richiedono 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 ulteriori informazioni sulle funzionalità e sugli strumenti di Google Cloud che ti aiutano a creare, testare e implementare 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 conto di tutti i requisiti di comunicazione, il pattern di architettura speculare offre le seguenti opzioni, descritte nelle sezioni seguenti:
- VPC condiviso per ambiente
- Firewall a livello di applicazione centralizzato
- Topologia hub and 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 gli strumenti di CI/CD e 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 grazie all'isolamento a livello di rete e di progetto tra i diversi ambienti, il che consente un controllo dell'accesso più granulare della comunicazione e dell'accesso con Identity and Access Management (IAM).
Dal punto di vista della gestione e delle operazioni, questo design offre la flessibilità per gestire le applicazioni e i carichi di lavoro creati da team diversi per ambiente e per progetto di servizio. Il networking VPC e le relative funzionalità di sicurezza possono essere di cui è possibile eseguire il provisioning e la gestione da parte dei team di operazioni di rete in base alle seguenti strutture possibili:
- 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 essere basate sulla struttura del team, sulle operazioni di sicurezza e sui requisiti di accesso di ciascun team. Puoi applicare questa variazione di progettazione alla rete VPC condivisa per ogni opzione di progettazione della zona di destinazione dell'ambiente. Tuttavia, devi considerare i requisiti di comunicazione del pattern mirrored per definire quali comunicazioni sono consentite 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 a livello di applicazione centralizzato
In alcuni scenari, i requisiti di sicurezza potrebbero richiedere l'utilizzo del livello di 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 in hosting in un'appliance virtuale di rete (NVA). Diversi partner di sicurezza di Google Cloud offrono opzioni adatte a questa attività.
Come illustrato nel seguente diagramma, puoi posizionare l'NVA nel percorso di rete tra Virtual Private Cloud e l'ambiente di calcolo privato utilizzando più interfacce di rete.
Questo design può essere utilizzato anche con più VPC condivisi, come illustrato nel seguente diagramma.
L'NVA in questo design funge da livello di sicurezza del perimetro. Inoltre, funge da base per attivare l'ispezione del traffico in linea e applicare criteri di controllo dell'accesso rigorosi.
Per una strategia di sicurezza solida a più livelli che includa regole firewall VPC e funzionalità di servizi di prevenzione delle intrusioni, includi ulteriori ispezioni del traffico e controlli di sicurezza per i flussi di traffico est-ovest e nord-sud.
Topologia hub and spoke
Un'altra possibile variante di progettazione è utilizzare VPC distinti (inclusi VPC condivisi) per lo sviluppo e le diverse fasi di test. In questa variante, come mostrato nel diagramma seguente, tutti gli ambienti di fase si connettono al CI/CD e alla VPC amministrativa 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ò essere utile per 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, consulta Topologia hub-and-spoke con appliance centralizzati e Topologia hub-and-spoke senza appliance centralizzati.
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 nella VPC hub in modo che sia in linea con i tuoi requisiti di connettività.
Nell'ambito dell'architettura di rete hub-and-spoke, le opzioni di connettività principali (tra i VPC spoke e hub) su Google Cloud sono le seguenti:
- Peering di rete VPC
- VPN
- Utilizzo di un'appliance virtuale di rete (NVA)
- Con più interfacce di rete
- Con Network Connectivity Center (NCC)
Per ulteriori informazioni sull'opzione da considerare nel tuo design, consulta Architettura di rete hub-and-spoke. Un fattore chiave che influisce sulla scelta della VPN rispetto al peering VPC tra gli spoke e il VPC hub è quando è richiesta la transitività del traffico. La transitività del traffico indica che il traffico da 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 loro 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 se 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 dei criteri di sicurezza a livello di microservizio, l'autenticazione e l'identità del carico di lavoro. La attendibilità è basata sull'identità e applicata per ogni servizio.
Utilizzando un'architettura proxy distribuita, come un mesh di servizi, i servizi possono verificare in modo efficace gli utenti 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 avere un mesh comune che può includere i deployment di Google Cloud e on-premise. Il mesh utilizza i criteri di autorizzazione per contribuire a proteggere le comunicazioni da servizio a servizio.
Con questa architettura puoi anche incorporare Apigee Adapter for Envoy, che è un deployment di Apigee API Gateway in un cluster Kubernetes. Apigee Adapter for Envoy è un proxy di servizi ed edge open source progettato per le applicazioni cloud-first.
Per ulteriori informazioni su questo argomento, leggi i seguenti articoli:
- Architettura distribuita Zero Trust
- Ambiente ibrido GKE Enterprise
- Connetti a Google
- Connetti un cluster GKE Enterprise on-premise a una rete Google Cloud.
- Configurare un mesh multi-cloud o ibrido
- Esegui il deployment di Cloud Service Mesh in ambienti e cluster.
Best practice per i pattern speculari
- I sistemi CI/CD necessari per eseguire il deployment o la riconfigurazione dei deployment di produzione devono essere altamente disponibili, il che significa che tutti i componenti dell'architettura devono essere progettati per fornire il livello previsto di disponibilità del sistema. Per ulteriori informazioni, consulta la pagina sulla l'affidabilità dell'infrastruttura Google Cloud.
- Per eliminare gli errori di configurazione per 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 questo design potrebbe richiedere l'incorporazione di più segmenti con diversi livelli di controlli di accesso di sicurezza.
- Quando progetti una soluzione che include NVA, è importante prendere in considerazione l'alta disponibilità (HA) delle NVA per evitare un singolo punto di errore che potrebbe bloccare tutte le comunicazioni. Segui le linee guida per la progettazione e l'implementazione della disponibilità elevata e della ridondanza fornite dal fornitore dell'NVA.
- Se non esporti le route IP on-premise tramite il peering VPC o la VPN nella VPC di sviluppo e test, puoi limitare la connettività di rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta Scambio di route personalizzate con il peering di rete VPC.
- Per i carichi di lavoro con indirizzi IP privati 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 ulteriori informazioni, consulta Ingresso con cancello, in questa serie.
- Consulta le best practice generali per i modelli di architettura di rete ibrida e multicloud.