Esegui il deployment del progetto base

Last reviewed 2024-12-13 UTC

Questa sezione descrive la procedura che puoi utilizzare per eseguire il deployment del blueprint, le relative convenzioni di denominazione e le alternative ai consigli per i blueprint.

Riepilogo

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

Esegui il deployment del blueprint in una nuova organizzazione

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

  1. Crea l'infrastruttura di base utilizzando il blueprint per le basi dell'azienda. Completa quanto segue:

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

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

  2. Esegui il deployment del blueprint dell'applicazione aziendale nel seguente modo:

    1. 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 di ambito parco risorse.
    2. L'amministratore della piattaforma per gli sviluppatori utilizza la pipeline di infrastruttura multi-tenant per eseguire il deployment di cluster GKE e infrastruttura condivisa.
    3. Gli operatori delle applicazioni utilizzano la factory di 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.
    4. Gli sviluppatori di applicazioni utilizzano la pipeline CI/CD dell'applicazione all'interno della loro infrastruttura specifica per l'applicazione per eseguire il deployment delle applicazioni nell'infrastruttura multi-tenant.

Esegui il deployment del progetto senza il progetto di base per le aziende

Se non esegui il deployment del progetto base per le applicazioni aziendali sul progetto base per le imprese, completa i seguenti 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 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 controllo
    • Security Command Center per il monitoraggio delle minacce
    • Norme dell'organizzazione in linea con la tua strategia di sicurezza
    • Una pipeline che può essere utilizzata per eseguire il deployment della factory di applicazioni, della pipeline di infrastruttura multi-tenant e della pipeline di ambito parco risorse
  2. Dopo aver eseguito il deployment delle risorse, vai al passaggio 2 di 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 di eseguire 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.

Puoi utilizzare l'architettura del cluster e del parco risorse del blueprint anche quando vengono utilizzati prodotti diversi 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.

Per implementazioni sequenziali più sicure, è consigliabile avere almeno due ambienti. 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 suGoogle 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 i tuoi 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.

Per adottare il blueprint non è necessario utilizzare più regioni di produzione e non di produzione.

Esistono diversi insiemi di ambienti.

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

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

Per la piattaforma per sviluppatori più sicura e coerente, puoi provare a trasferire la proprietà dei cluster dai team di applicazioni al team della piattaforma per sviluppatori. In caso contrario, puoi comunque adottare molte delle pratiche del blueprint. Ad esempio, puoi aggiungere i cluster di proprietà di diversi team di applicazioni a un parco. Tuttavia, quando combini cluster con proprietà indipendenti, non utilizzare la federazione delle identità di lavoro per GKE o Cloud Service Mesh, in quanto non forniscono un controllo sufficiente su chi può affermare quali identità di lavoro. Utilizza invece un criterio dell'organizzazione personalizzato per impedire ai team di attivare queste funzionalità sui cluster GKE.

Quando i cluster sono raggruppati in un parco risorse, puoi comunque eseguire controlli e applicare i criteri. Puoi utilizzare un criterio di 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 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 blueprint per creare altri insiemi di cinque cluster.

Assegna le applicazioni a insiemi di cinque cluster. Non associare gli ambiti o gli spazi dei nomi del parco risorse di un'applicazione ai cluster negli altri insiemi. Potresti voler separare le applicazioni in diversi set di cluster per completare attività come le seguenti:

  • Raggruppa alcune applicazioni con requisiti normativi speciali (ad esempio PCI-DSS).
  • Isola le applicazioni che richiedono una gestione speciale durante gli upgrade del cluster (ad esempio, le applicazioni con stato che utilizzano volumi permanenti).
  • Isolare le applicazioni con profili di sicurezza rischiosi (ad esempio, l'elaborazione di 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 stai per raggiungere il limite del cluster GKE per il numero di nodi (65.000), puoi creare un nuovo insieme di cluster.
  • Utilizza un VPC condiviso diverso per le applicazioni che devono essere eseguite all'interno di un perimetro Controlli di servizio VPC. Crea un insieme di cluster nel perimetro e un altro al di fuori 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 del cluster (3 VM x 2 regioni) anche con i tipi di istanze più piccoli disponibili.
  • Potenziale sprecato per la riduzione dei costi dal raggruppamento di diverse applicazioni.
  • Pianificazione della crescita della capacità laboriosa e incerta perché viene applicata a ogni applicazione singolarmente. Le previsioni della capacità sono più precise se eseguite in modo aggregato per un ampio insieme di applicazioni.
  • Ritardi nella creazione di nuovi cluster per nuovi tenant o applicazioni, con conseguente riduzione della soddisfazione dei tenant nei confronti della piattaforma. Ad esempio, in alcune organizzazioni, le allocazioni degli indirizzi IP richiesti possono richiedere tempo e approvazioni aggiuntive.
  • Raggiungimento del limite del cluster privato in una rete VPC.

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 offre lo stesso livello di disponibilità di un'architettura a due regioni o multiregione.

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-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 con architettura a hub e spoke.

Ogni applicazione ha un repository Git separato.

Alcune organizzazioni utilizzano un unico repository Git (un monorepo) per tutto il codice sorgente anziché più repository. Se utilizzi un monorepo, puoi modificare il componente factory di applicazioni del blueprint per supportare il tuo repository. Completa quanto segue:

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

Passaggi successivi