Questa sezione descrive il processo che puoi utilizzare per eseguire il deployment del progetto base, convenzioni di denominazione e alternative ai suggerimenti relativi ai progetti.
Riepilogo
Per implementare l'architettura descritta in questo documento, completa i passaggi di questa sezione.
Esegui il deployment del progetto in una nuova organizzazione
Per eseguire il deployment del blueprint in una nuova organizzazione Google Cloud, completa quanto segue:
Crea l'infrastruttura di base utilizzando il blueprint per le basi dell'enterprise. Completa quanto segue:
- Crea una struttura organizzativa che includa cartelle per la separazione dei ambienti cloud-native.
- Configura le autorizzazioni IAM di base per concedere l'accesso allo sviluppatore Google Workspace for Education.
- Crea la rete VPC.
- Esegui il deployment della pipeline dell'infrastruttura di base.
Se non utilizzi il progetto delle basi aziendali, vedi Eseguire il deployment del progetto base senza quello delle basi aziendali.
Esegui il deployment del blueprint dell'applicazione aziendale nel seguente modo:
- L'amministratore della piattaforma per gli sviluppatori utilizza la pipeline dell'infrastruttura di base per creare la pipeline dell'infrastruttura multi-tenant, la factory di applicazioni e la pipeline a livello di parco.
- L'amministratore della piattaforma per gli sviluppatori utilizza la pipeline di infrastruttura multi-tenant per eseguire il deployment di cluster GKE e infrastruttura condivisa.
- Gli operatori delle applicazioni utilizzano la factory delle applicazioni per eseguire l'onboarding di nuove applicazioni. Gli operatori aggiungono una o più voci nel repository della factory di applicazioni, che attiva la creazione di risorse specifiche per l'applicazione.
- Gli sviluppatori di applicazioni utilizzano la pipeline CI/CD dell'applicazione all'interno del loro un'infrastruttura specifica per l'applicazione per eseguire il deployment delle applicazioni nel multi-tenant dell'infrastruttura.
Esegui il deployment del progetto senza quello delle basi aziendali
Se non esegui il deployment del progetto base dell'applicazione aziendale nell'azienda progetto di base, completa i seguenti passaggi:
- Crea le seguenti risorse:
- Una gerarchia dell'organizzazione con
development
,nonproduction
eproduction
cartelle - Una rete VPC condivisa in ogni cartella
- Uno schema di indirizzi IP che tenga conto degli intervalli IP richiesti per i cluster GKE
- Un meccanismo DNS per i tuoi cluster GKE
- Criteri firewall in linea con la tua postura di sicurezza
- Un meccanismo per accedere alle API Google Cloud tramite indirizzi IP privati
- Un meccanismo di connettività con il tuo ambiente on-premise
- Logging centralizzato per sicurezza e audit
- Security Command Center per il monitoraggio delle minacce
- Criteri dell'organizzazione in linea con la tua strategia di sicurezza
- Una pipeline che può essere utilizzata per eseguire il deployment della fabbrica di applicazioni, pipeline di infrastruttura multi-tenant e pipeline con ambito del parco risorse
- Una gerarchia dell'organizzazione con
- Dopo aver eseguito il deployment delle risorse, continua con il passaggio 2 della sezione Eseguire il deployment del progetto base in una nuova organizzazione.
Incorpora il progetto nel tuo deployment GKE esistente
Questo blueprint richiede di eseguire prima il deployment della piattaforma per sviluppatori e poi il deployment delle applicazioni sulla piattaforma per sviluppatori. La tabella seguente descrive come utilizzare il blueprint se hai già applicazioni containerizzate in esecuzione su Google Cloud.
Utilizzo esistente | Strategia di migrazione |
---|---|
Hai già una pipeline CI/CD. | Tu può utilizzare l'architettura del parco risorse e del cluster del progetto anche quando per la creazione e il deployment delle applicazioni. Come minimo, consigliamo di eseguire il mirroring delle immagini in due regioni. |
Avere una struttura organizzativa esistente che non corrisponde al blueprint delle basi dell'azienda. | Avere sono consigliati almeno due ambienti per deployment sequenziali più sicuri. Non è necessario eseguire il deployment degli ambienti in VPC o cartelle condivisi separati. Tuttavia, non eseguire il deployment di carichi di lavoro appartenenti a ambienti diversi nello stesso cluster. |
Non utilizzare l'IaC. |
Se la tua attuale procedura di deployment delle applicazioni non utilizza l'IaC, puoi valutare la tua idoneità con il modello di maturità di Terraform su Google Cloud. Importa le risorse esistenti in un altro progetto Terraform organizzato in modo simile a questo blueprint, con la separazione delle pipeline per tenant e multi-tenant. Per creare nuovi cluster, puoi utilizzare i moduli Terraform per Google Cloud. |
I cluster sono distribuiti su più progetti all'interno dello stesso ambiente. |
Puoi raggruppare i cluster di più progetti in un parco risorse. Verifica che
gli spazi dei nomi hanno significati univoci all'interno dello stesso parco risorse. Prima di aggiungere
a un parco risorse, chiedi ai team di spostare le loro applicazioni in uno spazio dei nomi con
nome univoco (ad esempio, non Puoi quindi raggruppare spazi dei nomi in ambiti. |
I cluster si trovano in un'unica regione. |
Non è necessario utilizzare più regioni in produzione e non di produzione per adottare il progetto. |
Esistono diversi insiemi di ambienti. |
Puoi modificare il blueprint in modo da supportare più o meno di tre ambienti. |
La creazione dei cluster è delegata ai team di sviluppatori o operatori di applicazioni. |
Per ottenere la piattaforma per sviluppatori più sicura e coerente, puoi provare trasferire la proprietà dei cluster dai team delle applicazioni alla piattaforma di sviluppo dell'IA. In caso contrario, puoi comunque adottare molte delle pratiche del blueprint. Per Ad esempio, puoi aggiungere i cluster di proprietà di diversi team delle applicazioni a un parco risorse. Tuttavia, quando combini i cluster con proprietà indipendente, non usare Federazione delle identità per i carichi di lavoro per GKE o il mesh di servizi Cloud, in quanto non forniscono un controllo sufficiente che possono specificare le identità dei carichi di lavoro. Utilizza invece un modello personalizzato dell'organizzazione per impedire ai team di abilitare queste funzionalità cluster GKE. Quando i cluster sono raggruppati in un parco risorse, puoi comunque per controllare e applicare criteri. Puoi utilizzare un modello criterio dell'organizzazione per richiedere la creazione di cluster all'interno di un parco risorse che corrisponde alla cartella di ambiente in cui si trova il progetto del cluster. Puoi utilizzare la configurazione predefinita di Fleet per richiedere che i nuovi cluster utilizzino il controllo delle norme. |
Alternative ai consigli predefiniti
Questa sezione descrive le alternative ai consigli predefiniti inclusi in questa guida.
Area decisionale | Possibili alternative |
---|---|
Tutte le applicazioni vengono eseguite nello stesso insieme di cinque cluster. |
Il progetto base utilizza un insieme di cinque cluster (due in produzione, due in produzione e uno in fase di sviluppo). Puoi modificare il progetto per di cinque cluster aggiuntivi. Assegna le applicazioni a insiemi di cinque cluster. Non associare gli ambiti di un'applicazione o gli spazi dei nomi del parco risorse ai cluster in gli altri insiemi. Ti consigliamo di isolare le applicazioni in cluster diversi per completare attività come le seguenti:
Evita di creare nuovi set di cluster per ogni applicazione o tenant, perché potrebbe verificarsi una delle seguenti situazioni:
|
Gli ambienti di produzione e non di produzione hanno cluster in due regioni. |
Per una latenza inferiore per gli utenti finali in più regioni, puoi eseguire il deployment dei carichi di lavoro di produzione e non di produzione in più di due regioni (ad esempio tre regioni per la produzione, tre regioni per la non produzione e una regione per lo sviluppo). Questa strategia di implementazione aumenta il costo e il carico di gestione delle risorse in regioni aggiuntive. |
Se tutte le applicazioni hanno requisiti di disponibilità inferiori, puoi eseguire il deployment dei carichi di lavoro di produzione e non di produzione in una sola regione (un ambiente di produzione, un ambiente non di produzione e un ambiente di sviluppo). Questa strategia consente di ridurre i costi, ma non protegge lo stesso livello di la disponibilità come architettura a due o più regioni. |
|
Se le applicazioni hanno requisiti di disponibilità diversi, puoi creare
set di cluster diversi per applicazioni diverse (ad esempio,
|
|
La topologia hub-and-spoke soddisfa meglio i tuoi requisiti rispetto al VPC condiviso. |
Puoi eseguire il deployment del blueprint in una configurazione hub-and-spoke, in cui ogni ambiente (sviluppo, produzione e non produzione) è ospitato nel proprio spoke. La topologia hub-and-spoke può aumentare la segregazione degli ambienti. Per maggiori informazioni, consulta la topologia di rete hub-and-spoke. |
Ogni applicazione ha un repository Git separato. |
Alcune organizzazioni utilizzano un singolo repository Git (un monorepo) per il codice sorgente, invece che in più repository. Se usi un monorepo, puoi modifica lo application fabbrica del progetto per supportare il tuo repository. Completa le seguenti informazioni:
|
Passaggi successivi
- Scopri di più sul progetto della piattaforma di base per le aziende.
- Scopri di più sulla distribuzione del software su Google Cloud da quanto segue:
- Scopri di più sull'esecuzione di applicazioni su GKE dal seguenti: