esegui il deployment del progetto base

Last reviewed 2024-04-19 UTC

Questa sezione descrive il processo che puoi utilizzare per eseguire il deployment del progetto, le sue convenzioni di denominazione e le alternative ai suggerimenti del progetto.

Riepilogo

Per implementare l'architettura descritta in questo documento, completa i passaggi descritti in questa sezione.

Esegui il deployment del progetto base in una nuova organizzazione

Per eseguire il deployment del progetto base in una nuova organizzazione Google Cloud, completa quanto segue:

  1. Crea la tua infrastruttura di base utilizzando il progetto di base aziendale. Completa i seguenti passaggi:

    1. Creando una struttura organizzativa, incluse le cartelle per la separazione degli ambienti.
    2. Configurare le autorizzazioni IAM di base per concedere l'accesso agli amministratori della piattaforma per sviluppatori.
    3. Crea la rete VPC.
    4. Eseguire il deployment della pipeline dell'infrastruttura di base.

    Se non utilizzi il progetto di base per le aziende, vedi Eseguire il deployment del progetto senza il progetto di base aziendale.

  2. L'amministratore della piattaforma per sviluppatori usa la pipeline dell'infrastruttura di base per creare la pipeline dell'infrastruttura multi-tenant, la fabbrica delle applicazioni e la pipeline con l'ambito del parco risorse.

  3. L'amministratore della piattaforma per sviluppatori usa la pipeline dell'infrastruttura multi-tenant per il deployment dei cluster GKE e dell'infrastruttura condivisa.

  4. Gli operatori di applicazioni utilizzano la fabbrica di applicazioni per integrare nuove applicazioni. Gli operatori aggiungono una o più voci nel repository di fabbrica delle applicazioni, attivando la creazione di risorse specifiche per le applicazioni.

  5. Gli sviluppatori di applicazioni utilizzano la pipeline CI/CD dell'applicazione all'interno della propria infrastruttura specifica per le applicazioni per eseguire il deployment delle applicazioni nell'infrastruttura multi-tenant.

Esegui il deployment del progetto senza il progetto di base delle fondamenta aziendali

Se non esegui il deployment del progetto base dell'applicazione aziendale nel progetto di base dell'azienda, completa questi passaggi:

  1. Crea le seguenti risorse:
    • Una gerarchia dell'organizzazione con cartelle development, nonproduction e production
    • Una rete VPC condiviso in ogni cartella
    • Uno schema di indirizzi IP che tiene conto degli intervalli IP richiesti per i cluster GKE
    • Un meccanismo DNS per i tuoi cluster GKE.
    • Criteri firewall allineati con la tua strategia 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 allineati con la tua strategia di sicurezza
    • Una pipeline che può essere utilizzata per eseguire il deployment del fabbrica delle applicazioni, della pipeline dell'infrastruttura multi-tenant e dell'ambito del parco risorse
  2. Dopo aver eseguito il deployment delle risorse, continua con il passaggio 2 in Esegui il deployment del progetto base in una nuova organizzazione.

Incorpora il progetto base nel tuo deployment GKE esistente

Questo progetto richiede prima il deployment della piattaforma per sviluppatori e poi il deployment delle applicazioni sulla piattaforma per sviluppatori. La seguente tabella descrive come utilizzare il progetto base se hai già applicazioni containerizzate in esecuzione su Google Cloud.

Utilizzo esistente Strategia di migrazione

Hai già una pipeline CI/CD.

Puoi utilizzare il parco risorse e l'architettura del cluster del progetto base anche quando vengono utilizzati prodotti diversi per la creazione e il deployment dell'applicazione. Come minimo, ti consigliamo di eseguire il mirroring delle immagini su due regioni.

Avere una struttura organizzativa esistente che non corrisponde al progetto di base dell'azienda.

Per distribuzioni sequenziali più sicure, è consigliabile avere almeno due ambienti. Non è necessario eseguire il deployment di ambienti in cartelle o VPC condivisi separati. Tuttavia, non eseguire il deployment nello stesso cluster di carichi di lavoro appartenenti ad ambienti diversi.

Non usare IaC.

Se l'attuale processo di deployment delle applicazioni non utilizza IaC, puoi valutare la tua idoneità con il modello di maturità Terraform su Google Cloud. Importa le risorse esistenti in un altro progetto Terraform organizzato in modo simile a questo progetto base, con la separazione delle pipeline per più 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 default).

Puoi quindi raggruppare gli spazi dei nomi in ambiti.

I cluster si trovano in un'unica regione.

Non è necessario utilizzare più regioni in produzione e non in produzione per adottare il progetto base.

Esistono diversi insiemi di ambienti.

Puoi modificare il progetto per supportare più o meno di tre ambienti.

La creazione di cluster è delegata ai team degli sviluppatori di applicazioni o degli operatori delle applicazioni.

Per una piattaforma per sviluppatori più sicura e coerente, puoi provare a trasferire la proprietà dei cluster dai team che si occupano delle applicazioni al team della piattaforma di sviluppo. Se non puoi, puoi comunque adottare molte delle best practice per i progetti. Ad esempio, puoi aggiungere a un parco risorse i cluster di proprietà di diversi team delle applicazioni. Tuttavia, quando combini i cluster con proprietà indipendente, non utilizzare Workload Identity o Anthos Service Mesh, perché non offrono un controllo sufficiente su chi può affermare 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 dell'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 base utilizza un insieme di cinque cluster (due in produzione, due in produzione e uno in fase di sviluppo). Puoi modificare il progetto per creare set aggiuntivi 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. Puoi voler separare le applicazioni in set di cluster diversi per completare attività come quelle seguenti:

  • Raggruppa alcune applicazioni con problemi normativi speciali (ad esempio PCI-DSS).
  • Isola le applicazioni che richiedono una gestione speciale durante gli upgrade dei cluster (ad esempio le applicazioni stateful che utilizzano volumi permanenti).
  • Isolare le applicazioni con profili di sicurezza rischiosi (ad esempio, elaborare contenuti forniti dall'utente in un linguaggio non sicuro per la memoria).
  • Isola le applicazioni che richiedono GPU, sensibilità ai costi e sensibilità alle prestazioni.
  • Se ti stai avvicinando al limite di cluster GKE relativo al numero di nodi (15.000 nodi), puoi creare un nuovo insieme di cluster.
  • Utilizza un VPC condiviso diverso per le applicazioni che devono essere eseguite all'interno di un perimetro dei Controlli di servizio VPC. Creando un cluster all'interno del perimetro e un set all'esterno del perimetro.

Evita di creare nuovi set di cluster per ogni applicazione o tenant, perché questa pratica potrebbe comportare una delle seguenti circostanze:

  • Applicazioni che non sfruttano bene le dimensioni minime dei cluster (3 VM x 2 regioni) anche con i tipi di istanza più piccoli disponibili.
  • Potenziale perdita di riduzione dei costi derivante dal bin packing di diverse applicazioni.
  • Pianificazione di crescita della capacità noiosa e incerta, perché viene applicata a ogni singola applicazione. Le previsioni della capacità sono più accurate se vengono svolte in forma aggregata per un ampio set di applicazioni.
  • Ritardi nella creazione di nuovi cluster per i nuovi tenant o le nuove applicazioni, che riducono la soddisfazione dei tenant con la piattaforma. Ad esempio, in alcune organizzazioni, le allocazioni richieste degli indirizzi IP possono richiedere tempo e richiedere approvazioni aggiuntive.
  • Raggiungi il limite di cluster privati in una rete VPC.

Gli ambienti di produzione e non di produzione hanno cluster in due regioni.

Per ridurre la latenza agli 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 per la non produzione e una per lo sviluppo). Questa strategia di deployment aumenta i costi e i costi generali per il mantenimento delle risorse in altre regioni.

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 aiuta a ridurre i costi, ma non protegge lo stesso livello di disponibilità di un'architettura con due o più regioni.

Se le applicazioni hanno requisiti di disponibilità diversi, puoi creare set di cluster diversi per applicazioni diverse (ad esempio, cluster-set-1 con due ambienti di produzione, due ambienti non di produzione e un ambiente di sviluppo e cluster-set-2 con un ambiente di produzione, un ambiente non di produzione e un ambiente di sviluppo).

La topologia hub e spoke corrisponde ai tuoi requisiti meglio del VPC condiviso.

Puoi eseguire il deployment del progetto in una configurazione hub and spoke, in cui ogni ambiente (sviluppo, produzione e non produzione) è ospitato nel proprio spoke. La topologia hub e spoke può aumentare la segregazione degli ambienti. Per saperne di più, consulta Topologia di rete hub e 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 utilizzi un monorepo, puoi modificare il componente application_fabbrica del progetto in modo che supporti il repository. Completa i seguenti passaggi:

  • Anziché creare un nuovo repository per ogni nuova applicazione, crea una sottodirectory nel repository esistente.
  • Anziché concedere al gruppo di sviluppatori delle applicazioni le autorizzazioni di proprietario per il nuovo repository, concedi l'autorizzazione di scrittura sul repository esistente e rendi il gruppo di sviluppatori dell'applicazione un revisore obbligatorio per le modifiche alla nuova sottodirectory. Utilizza la funzionalità CODEOWNERS e la protezione dei rami.

Passaggi successivi