Il pattern in mirror si basa sulla replica del design di uno o più ambienti esistenti in uno o più nuovi ambienti. Pertanto, questo modello si applica principalmente alle architetture che seguono 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 con mirroring presuppone che i carichi di lavoro di test e produzione non siano dovrebbero 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 si allineino ai 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.
- Monitoraggio, gestione della configurazione e altri sistemi amministrativi dovrebbe funzionare in più ambienti di computing.
- I carichi di lavoro non possono comunicare direttamente tra gli ambienti di computing. Se necessario, la comunicazione deve essere granulare e controllata.
Architettura
Il seguente diagramma dell'architettura mostra un'architettura di riferimento di alto livello questo pattern che supporta CI/CD, il monitoraggio, la gestione della configurazione, altri sistemi amministrativi e la 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 sul lato Google Cloud.
- VPC condiviso
per i carichi di lavoro di sviluppo e test. Viene utilizzata un'altra VPC per gli strumenti di CI/CD e amministrativi. Con i VPC condivisi:
- Le applicazioni sono gestite da team diversi in base all'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 firewall consentono solo il traffico consentito.
- Potresti anche usare Firewall aziendale di nuova generazione Cloud con il servizio di prevenzione delle intrusioni (Intrusion Prevention Service, IPS) per implementare di ispezione per la prevenzione delle minacce senza modificarne la progettazione i percorsi dei carichi di lavoro. 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 carichi di lavoro alla ricerca delle firme di minacce configurate. Inoltre, protegge i carichi di lavoro dalle minacce.
- Consente la comunicazione tra i VPC accoppiati utilizzando indirizzi IP interni.
- Il peering in questo pattern consente CI/CD e servizi per il deployment e la gestione dei carichi di lavoro di sviluppo e test.
- Prendi in considerazione questi best practice generali.
Puoi stabilire questa connessione CI/CD utilizzando una delle opzioni di connettività di networking ibrida e multi-cloud che soddisfano i requisiti aziendali e delle 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 sovrapposizione.
Se le istanze negli ambienti di sviluppo e test richiedono la connessione a internet per l'accesso, prendi in considerazione le seguenti opzioni:
- Puoi eseguire il deployment di Cloud NAT nella stessa rete del progetto host VPC condiviso. Il deployment nel la stessa rete di progetto host del VPC condiviso consente di evitare che questi accessibili direttamente da internet.
- Per il traffico web in uscita, puoi utilizzare Secure Web Proxy. Il proxy offre diversi vantaggi.
Per saperne di più sugli strumenti e sulle funzionalità di Google Cloud che ti aiutano a creare, testare ed eseguire il deployment in Google Cloud e in ambienti ibridi e multi-cloud, consulta le Spiegazione di DevOps e CI/CD su Google Cloud blog.
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 e spoke
- Architettura distribuita di microservizi Zero Trust
VPC condiviso per ambiente
L'opzione di progettazione del 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 il controllo dell'accesso per diversi servizi che devono essere gestiti anche da team diversi.
Questa progettazione garantisce una maggiore separazione, in quanto a livello di rete e di progetto di isolamento tra i diversi ambienti, al fine di garantire la comunicazione e Identity and Access Management (IAM) e il controllo dell'accesso.
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.
- I progetti host vengono gestiti da team diversi 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 di progettazione delle applicazioni Rete VPC condivisa per ogni opzione di progettazione della zona di destinazione dell'ambiente. Tuttavia, devi tenere in considerazione i requisiti di comunicazione della piattaforma con mirroring per definire quale comunicazione è consentita tra i diversi degli ambienti cloud, 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 livello di applicazione (livello 7) e ispezione approfondita dei pacchetti con firewall i meccanismi che superano le capacità 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 diagramma seguente, è possibile posizionare l'NVA nella rete tra il Virtual Private Cloud e l'ambiente di computing privato utilizzando interfacce di rete multiple.
Questo design può essere utilizzato anche con più VPC condivisi, come illustrato in 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 della progettazione è l'utilizzo di VPC separati (inclusi quelli VPC) per le diverse fasi di sviluppo e 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 devono separare i domini amministrativi e le funzioni in ciascun 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à.
Come parte dell'architettura di rete hub-and-spoke, le seguenti sono le principali opzioni di connettività (tra gli spoke e i VPC hub) su Google Cloud:
- Peering di rete VPC
- VPN
- Utilizzo di appliance virtuale di rete (NVA)
- Con più interfacce di rete
- Con Centro connettività di rete (NCC)
Per ulteriori informazioni sull'opzione da considerare nella progettazione, 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 gli scopi tecnici e commerciali, separando anche dell'ambiente di produzione degli ambienti di sviluppo e test. Pertanto, i controlli di sicurezza perimetrali di rete sono importanti, soprattutto necessari per soddisfare 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. La rete mesh utilizza l'autorizzazione per garantire la sicurezza delle comunicazioni tra i servizi.
Puoi anche incorporare Adattatore Apigee per Envoy, che è un deployment di gateway API Apigee leggero all'interno Kubernetes con questa architettura. Adattatore Apigee per Envoy è un proxy perimetrale e di servizio open source progettato per il cloud-first diverse applicazioni.
Per ulteriori informazioni su questo argomento, consulta i seguenti articoli:
- Architettura distribuita senza attendibilità
- Ambiente ibrido di 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 pattern speculari
- I sistemi CI/CD necessari per il deployment o la riconfigurazione della produzione i deployment devono essere ad alta disponibilità, il che significa che tutta l'architettura i componenti devono essere progettati per fornire il livello la disponibilità del servizio. Per ulteriori informazioni, vedi Affidabilità dell'infrastruttura Google Cloud.
- Per eliminare gli errori di configurazione per processi ripetuti come il codice aggiornamenti, l'automazione è essenziale per standardizzare build, test deployment di machine learning. Per scoprire di più su come utilizzare vari controlli e guard durante l'automazione, consulta Automatizzare i deployment.
- L'integrazione di NVA centralizzate in questa progettazione potrebbe richiedere incorporazione di più segmenti con diversi livelli di accesso alla sicurezza i controlli di sicurezza.
- Quando si progetta una soluzione che include le VVA, è importante considerare l'alta disponibilità (HA) delle VM per evitare single point of failure che potrebbero 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 la sezione Scambio di route personalizzate del peering di rete VPC.
- Per carichi di lavoro con indirizzi IP privati che possono richiedere le API di Google all'accesso, puoi esporre API di Google utilizzando un Endpoint Private Service Connect all'interno di una rete VPC. Per ulteriori informazioni, consulta la sezione Ingresso con cancello di questa serie.
- Esamina il best practice generali per modelli di architettura di networking ibrida e multi-cloud.