Questa sezione descrive la procedura che puoi utilizzare per eseguire il deployment del progetto base, le relative convenzioni di denominazione e le alternative ai suggerimenti relativi ai progetti.
Riepilogo
Per implementare l'architettura descritta in questo documento, completa i passaggi in questa sezione.
Esegui il deployment del progetto in una nuova organizzazione
Per eseguire il deployment del progetto in una nuova organizzazione Google Cloud, completa quanto segue:
Crea la tua infrastruttura di base utilizzando il progetto di base aziendale. Completa le seguenti informazioni:
- Crea una struttura organizzativa che includa cartelle per la separazione degli ambienti.
- Configura le autorizzazioni IAM di base per concedere l'accesso agli amministratori della piattaforma sviluppatore.
- Crea la rete VPC.
- Eseguire 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.
L'amministratore della piattaforma per sviluppatori utilizza la pipeline dell'infrastruttura di base per creare la pipeline dell'infrastruttura multi-tenant, la fabbrica dell'applicazione e la pipeline con l'ambito del parco risorse.
L'amministratore della piattaforma per sviluppatori usa la pipeline dell'infrastruttura multi-tenant per eseguire il deployment dei cluster GKE e dell'infrastruttura condivisa.
Gli operatori delle applicazioni utilizzano la fabbrica di applicazioni per l'onboarding delle nuove applicazioni. Gli operatori aggiungono una o più voci nel repository dei dati di fabbrica delle applicazioni, il che attiva la creazione di risorse specifiche dell'applicazione.
Gli sviluppatori di applicazioni utilizzano la pipeline CI/CD dell'applicazione all'interno della loro infrastruttura specifica per l'applicazione per eseguire il deployment di applicazioni nell'infrastruttura multi-tenant.
Esegui il deployment del progetto senza quello delle basi aziendali
Se non esegui il deployment del progetto base dell'applicazione aziendale, completa questi passaggi:
- Crea le seguenti risorse:
- Una gerarchia dell'organizzazione con
development
,nonproduction
eproduction
cartelle - Una rete VPC condiviso in ogni cartella
- Uno schema di indirizzi IP che tiene conto degli intervalli IP richiesti per i tuoi cluster GKE
- Un meccanismo DNS per i tuoi cluster GKE
- Criteri firewall allineati alla tua security posture
- 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 utilizzabile per eseguire il deployment della fabbrica di applicazioni, della pipeline dell'infrastruttura multi-tenant
- 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 progetto richiede che tu esegua prima il deployment della piattaforma per sviluppatori e, successivamente, il deployment delle applicazioni sulla piattaforma. La seguente tabella descrive come utilizzare il progetto base se disponi già di applicazioni containerizzate in esecuzione su Google Cloud.
Utilizzo esistente | Strategia di migrazione |
---|---|
Hai già una pipeline CI/CD. | Puoi utilizzare l'architettura del parco risorse e del cluster del progetto anche quando vengono utilizzati prodotti diversi per la creazione e il deployment delle applicazioni. Ti consigliamo come minimo di eseguire il mirroring delle immagini in due regioni. |
Avere una struttura organizzativa esistente che non corrisponde al progetto delle basi aziendali. | Avere almeno due ambienti è consigliato per deployment sequenziali più sicuri. Non devi eseguire il deployment di ambienti in VPC o cartelle condivisi separati. Non eseguire però il deployment nello stesso cluster di carichi di lavoro appartenenti ad ambienti diversi. |
Non utilizzare IaC. |
Se l'attuale processo di deployment delle applicazioni non utilizza IaC, puoi valutare l'idoneità con il modello di maturità Terraform su Google Cloud. Importa le risorse esistenti in un progetto Terraform diverso organizzato in modo simile a questo progetto, con la separazione delle pipeline multi-tenant e per tenant. Per creare nuovi cluster, puoi utilizzare i moduli Terraform per Google Cloud. |
I cluster sono distribuiti in più progetti all'interno dello stesso ambiente. |
Puoi raggruppare i cluster di più progetti in un parco risorse. Verifica che
gli spazi dei nomi abbiano significati univoci all'interno dello stesso parco risorse. Prima di aggiungere cluster a un parco risorse, chiedi ai team di spostare le loro applicazioni in uno spazio dei nomi con un nome univoco (ad esempio, non Puoi quindi raggruppare gli spazi dei nomi in ambiti. |
I cluster si trovano in un'unica regione. |
Per adottare il progetto base, non devi utilizzare più regioni in produzione e non in produzione. |
Esistono diversi insiemi di ambienti. |
Puoi modificare il progetto in modo che supporti più o meno di tre ambienti. |
La creazione di cluster è delegata ai team di sviluppatori o operatori delle applicazioni. |
Per una piattaforma di sviluppo più sicura e coerente, puoi provare a trasferire la proprietà dei cluster dai team delle applicazioni al team della piattaforma di sviluppo. Se non ci riesci, puoi comunque adottare molte delle pratiche del progetto base. Ad esempio, puoi aggiungere a un parco risorse di proprietà di diversi team delle applicazioni. Tuttavia, quando combini i cluster con proprietà indipendente, non utilizzare Workload Identity o Cloud Service Mesh, perché non offrono un controllo sufficiente su chi può rivendicare quali identità dei carichi di lavoro. Utilizza invece un criterio dell'organizzazione personalizzato per impedire ai team di abilitare queste funzionalità sui cluster GKE. Quando i cluster sono raggruppati in un parco risorse, puoi comunque controllare e applicare i criteri. Puoi utilizzare un criterio dell'organizzazione personalizzato per richiedere la creazione di cluster all'interno di un parco risorse corrispondente alla cartella di ambiente in cui si trova il progetto del cluster. Puoi utilizzare la configurazione predefinita del parco risorse per richiedere che i nuovi cluster utilizzino il controllo dei criteri. |
Alternative ai consigli predefiniti
Questa sezione descrive le alternative ai suggerimenti predefiniti inclusi in questa guida.
Area decisionale | Possibili alternative |
---|---|
Tutte le applicazioni vengono eseguite nello stesso insieme di cinque cluster. |
Il progetto utilizza un insieme di cinque cluster (due in produzione, due in produzione e uno in fase di sviluppo). Puoi modificare il progetto per creare ulteriori insiemi di cinque cluster. 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 negli altri set. Ti consigliamo di separare le applicazioni in set di cluster diversi per completare attività come le seguenti:
Evita di creare nuovi set di cluster per ogni applicazione o tenant, perché questa pratica potrebbe comportare una delle seguenti circostanze:
|
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 per la fase di produzione, tre per quella non di produzione e una per lo sviluppo). Questa strategia di deployment aumenta i costi e l'overhead per la manutenzione delle risorse in altre regioni. |
Se tutte le applicazioni hanno requisiti di disponibilità inferiori, puoi eseguire il deployment di 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 disponibilità di un'architettura doppia o multiregionale. |
|
Se le applicazioni hanno requisiti di disponibilità diversi, puoi creare set di cluster diversi per applicazioni diverse (ad esempio, |
|
La topologia hub e spoke soddisfa meglio i tuoi requisiti rispetto al VPC condiviso. |
Puoi eseguire il deployment del progetto in una configurazione hub e spoke, dove ogni ambiente (di sviluppo, produzione e non di produzione) è ospitato sul proprio spoke. La topologia hub-and-spoke può aumentare la segregazione degli ambienti. Per ulteriori informazioni, consulta Topologia di rete Hub-and-spoke. |
Ogni applicazione ha un repository Git separato. |
Alcune organizzazioni utilizzano un singolo repository Git (un monorepo) per tutto il codice sorgente anziché più repository. Se usi un monorepo, puoi modificare il componente applicationfabbrica del progetto in modo che supporti il tuo repository. Completa le seguenti informazioni:
|
Passaggi successivi
- Scopri di più sul progetto delle basi aziendali.
- Scopri di più sulla distribuzione del software su Google Cloud da quanto segue:
- Scopri di più sull'esecuzione di applicazioni su GKE da:
- Best practice per la creazione di container
- Best practice per il networking di GKE
- Best practice per GKE Enterprise multi-tenancy
- Best practice per l'utilizzo dei container
- Best practice per l'esecuzione di applicazioni Kubernetes con ottimizzazione dei costi su GKE
- Repository di cluster GKE più sicuri
- Rafforza la sicurezza del tuo cluster