Il pattern con mirroring si basa sulla replica del design di un modello o ambienti in uno o più ambienti nuovi. Pertanto, questo modello si applica principalmente alle architetture che seguono pattern ambiente ibrido. In questo pattern, i carichi di lavoro di sviluppo e test vengono eseguiti mentre esegui i carichi di lavoro di gestione temporanea e produzione in un altro ambiente.
Il pattern con mirroring presuppone che i carichi di lavoro di test e produzione non siano dovrebbero comunicare direttamente tra loro. Tuttavia, dovrebbe essere di 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 che è in linea con i seguenti requisiti:
- È possibile eseguire il deployment dell'integrazione continua e del deployment continuo (CI/CD) gestire i carichi di lavoro in tutti gli ambienti di elaborazione o 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 necessaria, la comunicazione deve essere articolata 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 usato un altro VPC
CI/CD e strumenti di amministrazione. 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 la rete le comunicazioni e i controlli di sicurezza tra sviluppo e test degli ambienti di lavoro e all'esterno del VPC.
- Il VPC CI/CD è connesso alla rete che esegue i carichi di lavoro di produzione in nel tuo ambiente di computing 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 un ambiente a livello di zona gestito da Google gli endpoint firewall che usano la tecnologia di intercettazione dei pacchetti ispezionare in modo trasparente i carichi di lavoro per individuare la minaccia configurata firme. 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 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. che consente di eseguire il deployment per gestire i carichi di lavoro di produzione, questa connessione fornisce la connettività tra i diversi ambienti di computing. 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 Cloud NAT nella stessa rete del progetto host del 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, pur prendendo in considerazione tutti e requisiti di comunicazione, il modello di architettura con mirroring 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 o separazione del livello di servizio tra gli ambienti, tra cui CI/CD e strumenti amministrativi necessari per soddisfare determinate esigenze organizzative i tuoi requisiti di sicurezza. Questi requisiti limitano le comunicazioni, le attività dominio e controllo dell'accesso per vari servizi che devono essere gestiti da team diversi.
Questo tipo di progettazione è indipendente, poiché fornisce una connessione 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 controllo dell'accesso.
Da un punto di vista gestionale e operativo, questa progettazione fornisce flessibilità per gestire le applicazioni e i carichi di lavoro creati da team diversi per ambiente e per progetto di servizio. Networking VPC e la relativa sicurezza le funzionalità possono essere sottoposte a provisioning e gestite dai team delle operazioni di networking in base le 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 sulla gestione dei progetti host dovrebbero essere basate sulla struttura del team, le operazioni di sicurezza e i requisiti di accesso di ogni 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 rispettare standard e requisiti di sicurezza della tua organizzazione, puoi usare appliance ospitato in un'appliance virtuale di rete (NVA). Diversi prodotti Google Cloud partner per la sicurezza offrire opzioni adatte a questo compito.
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 questa progettazione funge da livello di sicurezza perimetrale. Funge anche da la base per abilitare l'ispezione del traffico in linea e applicare regole e i criteri di controllo dell'accesso.
Per una solida strategia di sicurezza multilivello che includa le regole del firewall VPC e le funzionalità del servizio di prevenzione delle intrusioni, includono un'ulteriore ispezione del traffico e la sicurezza dei flussi di traffico da est a ovest e da nord a sud.
Topologia hub e 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 come mostrato nel diagramma seguente, tutti gli ambienti di fase si connettono e il VPC amministrativo in un'architettura hub e spoke. Utilizza questa opzione se devono 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 il monitoraggio, strumenti di gestione delle configurazioni, CI/CD o autenticazione.
- È necessario applicare un insieme comune di criteri di sicurezza alle il traffico in uscita in modo centralizzato attraverso l'hub.
Per ulteriori informazioni sulle opzioni di progettazione basate su hub e raggi, vedi Topologia hub e spoke con appliance centralizzate e Topologia hub e spoke senza appliance centralizzate.
Come mostrato nel diagramma precedente, le risorse di comunicazione la connettività passa tutte attraverso il VPC dell'hub. Nell'ambito di questo schema, controllare e limitare la comunicazione sul VPC dell'hub per allinearsi 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 su quale opzione dovresti prendere in considerazione nella tua progettazione, vedi Architettura di rete Hub e spoke Una chiave che influisce sulla selezione di VPN su peering VPC tra gli spoke e il VPC hub è quando transitività del traffico è obbligatorio. La transitività del traffico indica che il traffico proveniente da uno spoke può raggiungere ad altri spoke attraverso l'hub.
Architettura distribuita dei microservizi Zero Trust
Le architetture ibride e multi-cloud possono richiedere più cluster per raggiungere gli scopi tecnici e commerciali, separando anche di produzione dagli 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 per supportare i requisiti di sicurezza dell'attuale modello cloud-first di microservizi distribuiti, dovresti anche prendere in considerazione il modello Zero Trust architetture distribuite. L'architettura distribuita di microservizi Zero Trust supporta la tua architettura di microservizi con il criterio di sicurezza a livello di microservizi applicazione forzata, autenticazione e identità dei carichi di lavoro. La fiducia è basato sull'identità e applicate per ogni servizio.
Utilizzando un'architettura proxy distribuita, ad esempio un mesh di servizi, i servizi possono convalidare efficacemente i chiamanti e implementare criteri granulari di controllo dell'accesso per ogni richiesta, in modo da avere un ambiente di microservizi più sicuro e scalabile. Cloud Service Mesh offre la flessibilità di disporre di un mesh comune in grado di coprire Google Cloud e i deployment on-premise. Il 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
- Connettiti a Google
- .
- Connetti un cluster GKE Enterprise on-premise a un rete Google Cloud.
- Configurare 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 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 avere ulteriori informazioni su come utilizzare vari controlli e protezioni come che automatizzi, Automatizza 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. Per ulteriori informazioni, vedi appliance di rete centralizzate su Google Cloud
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 la progettazione di alta disponibilità e ridondanza e le indicazioni fornite dal fornitore di NVA. Per ulteriori informazioni, vedi il sezione delle opzioni dell'architettura delle appliance di rete centralizzate su Google Cloud per ottenere una disponibilità elevata tra le appliance virtuali.
Non esportando le route IP on-premise tramite il peering VPC o VPN nella di sviluppo e test di un VPC, puoi limitare la connettività di rete di sviluppo e test nell'ambiente on-premise. Per ulteriori informazioni, vedi Scambio di route personalizzate di 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, vedi Ingress con accesso limitato, di questa serie.
Esamina il best practice generali per modelli di architettura di networking ibrida e multi-cloud.