Il pattern con mirroring si basa sulla replica del design di un determinato ambiente o ambienti esistenti in uno o più ambienti nuovi. Pertanto, questo pattern si applica principalmente alle architetture che seguono il modello ambiente ibrido. Con questo pattern, i carichi di lavoro di sviluppo e test vengono eseguiti in un ambiente, mentre i carichi di lavoro di gestione temporanea e produzione in un altro.
Il pattern con mirroring presuppone che i carichi di lavoro di test e produzione non comunichino 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 in linea con i seguenti requisiti:
- L'integrazione continua e il deployment continuo (CI/CD) consentono di eseguire il deployment e gestire i carichi di lavoro in tutti gli ambienti di elaborazione o ambienti specifici.
- Sistemi di monitoraggio, gestione della configurazione e altri sistemi amministrativi devono funzionare in più ambienti di elaborazione.
- I carichi di lavoro non possono comunicare direttamente tra gli ambienti di computing. Se necessario, la comunicazione deve avvenire in modo granulare e controllato.
Architettura
Il seguente diagramma dell'architettura mostra un'architettura di riferimento di alto livello di questo pattern che supporta CI/CD, Monitoring, 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 sono distribuiti in base agli ambienti funzionali (sviluppo, test, CI/CD e strumenti amministrativi) su VPC separati sul lato Google Cloud.
- Il VPC condiviso
viene utilizzato per i carichi di lavoro di sviluppo e test. Viene usato un altro VPC per
CI/CD e gli strumenti amministrativi. Con i VPC condivisi:
- Le applicazioni sono gestite da team diversi per ambiente e progetto di servizio.
- Il progetto host amministra e controlla i controlli di sicurezza e della comunicazione di rete 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 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 firewall a livello di zona gestiti da Google che utilizzano la tecnologia di intercettazione dei pacchetti per ispezionare in modo trasparente i carichi di lavoro alla ricerca delle firme di minaccia configurate. Inoltre, protegge i carichi di lavoro dalle minacce.
- Abilita la comunicazione tra i VPC in 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.
- Considera queste best practice generali.
Puoi stabilire questa connessione CI/CD utilizzando una delle opzioni di connettività di rete ibrida e multi-cloud discusse in base ai requisiti aziendali e delle applicazioni. Per consentire il deployment e la gestione dei carichi di lavoro di produzione, questa connessione fornisce la connettività di rete privata tra i diversi ambienti di elaborazione. Tutti gli ambienti devono avere uno spazio di indirizzi IP RFC 1918 senza sovrapposizione.
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 di progetto host del VPC condiviso. Il deployment nella stessa rete del progetto host del VPC condiviso aiuta a 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 sugli strumenti e sulle funzionalità di Google Cloud che aiutano a creare, testare ed eseguire il deployment in Google Cloud e in ambienti ibridi e multi-cloud, consulta il blog DevOps e CI/CD su Google Cloud.
Varianti
Per soddisfare diversi requisiti di progettazione, pur prendendo in considerazione tutti i requisiti di comunicazione, il pattern di architettura con mirroring offre queste opzioni, descritte nelle sezioni seguenti:
- VPC condiviso per ambiente
- Firewall a livello di applicazione centralizzato
- Topologia hub e spoke
- Architettura distribuita di microservizi Zero Trust
VPC condiviso per ambiente
L'opzione di progettazione del VPC condiviso per ambiente consente la separazione del livello di applicazione o di servizio tra ambienti, tra cui 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 garantisce la separazione fornendo isolamento a livello di rete e di progetto tra i diversi ambienti, che consente una comunicazione più granulare e controllo dell'accesso Identity and Access Management (IAM).
Da un punto di vista di gestione e operazioni, questo design offre la flessibilità necessaria 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 sottoposti a provisioning e gestiti dai team delle operazioni di networking in base alle seguenti strutture possibili:
- Un unico team gestisce tutti i progetti host in tutti gli ambienti.
- I progetti host vengono gestiti da team diversi nei rispettivi ambienti.
Le decisioni relative alla gestione dei progetti host dovrebbero essere basate sulla struttura dei team, sulle operazioni di sicurezza e sui requisiti di accesso di ogni team. Puoi applicare questa variante 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 con mirroring 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 diagramma seguente:
Firewall a livello di applicazione centralizzato
In alcuni scenari, i requisiti di sicurezza potrebbero richiedere la considerazione del livello di applicazione (livello 7) e dell'ispezione approfondita dei pacchetti con meccanismi di firewall avanzati che superano le capacità del firewall di Cloud Next Generation. Per soddisfare gli standard e i requisiti di sicurezza della tua organizzazione, puoi utilizzare un'appliance NGFW ospitata in un'appliance virtuale di rete (NVA). Diversi partner per la sicurezza di Google Cloud offrono opzioni adatte a questa attività.
Come illustrato nel seguente diagramma, è possibile posizionare l'NVA nel percorso di rete tra Virtual Private Cloud e l'ambiente di computing privato utilizzando più interfacce di rete.
Questa progettazione può essere utilizzata anche con più VPC condivisi, come illustrato nel diagramma seguente.
L'NVA in questa progettazione funge da livello di sicurezza perimetrale. Inoltre, funge da base per abilitare l'ispezione del traffico in linea e applicare criteri di controllo dell'accesso rigorosi.
Per una solida strategia di sicurezza multilivello che includa regole firewall VPC e funzionalità del servizio di prevenzione delle intrusioni, includi un'ulteriore ispezione del traffico e controllo di sicurezza verso i flussi di traffico sia da est a ovest che da nord-sud.
Topologia hub e spoke
Un'altra possibile variante della 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 diagramma seguente, tutti gli ambienti di fase si connettono con il CI/CD e il VPC amministrativo in un'architettura hub e spoke. Utilizza questa opzione se devi separare i domini amministrativi e le funzioni in ciascun ambiente. Il modello di comunicazione hub e spoke può essere utile per i seguenti requisiti:
- Le applicazioni devono accedere a un set comune di servizi, come monitoraggio, strumenti di gestione della configurazione, CI/CD o autenticazione.
- È necessario applicare un insieme comune di criteri di sicurezza al traffico in entrata e in uscita in modo centralizzato attraverso l'hub.
Per ulteriori informazioni sulle opzioni di progettazione hub e spoke, consulta Topologia hub e spoke con appliance centralizzate e topologia hub e spoke senza appliance centralizzate.
Come mostrato nel diagramma precedente, la comunicazione tra VPC e la connettività ibrida passano attraverso il VPC dell'hub. Nell'ambito di questo pattern, puoi controllare e limitare la comunicazione nel VPC dell'hub per allinearti ai tuoi requisiti di connettività.
Nell'ambito dell'architettura di rete hub e spoke, di seguito sono riportate le opzioni di connettività principali (tra gli spoke e i VPC 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 sull'opzione da prendere in considerazione nella progettazione, consulta Architettura di rete Hub-and-spoke. Un fattore di influenza chiave per la selezione di VPN su peering VPC tra gli spoke e il VPC dell'hub è il caso in cui è richiesta la transitività del traffico. La transitività del traffico indica che il traffico proveniente da uno spoke può raggiungere altri spoke attraverso l'hub.
Architettura distribuita dei microservizi Zero Trust
Le architetture ibride e multi-cloud possono richiedere più cluster per raggiungere i propri obiettivi tecnici e commerciali, compresa la separazione dell'ambiente di produzione dagli ambienti di sviluppo e test. Pertanto, i controlli di sicurezza perimetrali di rete sono importanti, soprattutto quando devono rispettare determinati requisiti di sicurezza.
Non è sufficiente per supportare i requisiti di sicurezza delle attuali architetture di microservizi distribuiti cloud-first, perciò dovresti prendere in considerazione anche le architetture distribuite Zero Trust. L'architettura distribuita di microservizi Zero Trust supporta la tua architettura di microservizi con applicazione, autenticazione e identità dei carichi di lavoro dei criteri di sicurezza a livello di microservizi. L'attendibilità è basata sull'identità e viene applicata per ogni servizio.
Utilizzando un'architettura di proxy distribuito, 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 in grado di coprire i deployment di Google Cloud e on-premise. Il mesh usa i criteri di autorizzazione per proteggere le comunicazioni tra i servizi.
Potresti anche incorporare Apigee Adapter per Envoy, che è un deployment di gateway API Apigee leggero all'interno di un cluster Kubernetes, con questa architettura. Apigee Adapter per Envoy è un proxy perimetrale e di servizio open source progettato per applicazioni cloud-first.
Per ulteriori informazioni su questo argomento, consulta i seguenti articoli:
- Architettura distribuita senza attendibilità
- Ambiente ibrido di GKE Enterprise
- Collegati a Google
- Connetti un cluster GKE Enterprise on-premise a una rete Google Cloud.
- Configura un mesh multi-cloud o ibrido
- Esegui il deployment di Cloud Service Mesh in ambienti e cluster diversi.
Best practice per pattern speculari
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 previsto di disponibilità del sistema. Per ulteriori informazioni, consulta 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. Per scoprire di più su come utilizzare i vari controlli e protezioni durante l'automazione, consulta Automatizzare i deployment.
L'integrazione di NVA centralizzate in questa progettazione potrebbe richiedere l'integrazione di più segmenti con diversi livelli di controlli di accesso alla sicurezza. Per ulteriori informazioni, consulta Appliance di rete centralizzate su Google Cloud.
Quando si progetta una soluzione che include le VM a elevata disponibilità, è importante considerare l'alta disponibilità per evitare un single point of failure che potrebbe bloccare tutte le comunicazioni. Segui le indicazioni di progettazione e implementazione per l'alta disponibilità e la ridondanza fornite dal fornitore di NVA. Per ulteriori informazioni, consulta la sezione relativa alle opzioni di architettura delle appliance di rete centralizzate su Google Cloud per ottenere disponibilità elevata tra le appliance virtuali.
Se non esporti le route IP on-premise tramite peering VPC o VPN nel VPC di sviluppo e test, puoi limitare la connettività della rete dagli ambienti di sviluppo e test all'ambiente on-premise. Per maggiori informazioni, consulta Scambio di route personalizzate di 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 maggiori informazioni, consulta Traffico in entrata con accesso limitato in questa serie.
Esamina le best practice generali per i pattern di architettura di networking ibride e multi-cloud.