Esegui la migrazione a Google Cloud: esegui la migrazione dai deployment manuali a quelli containerizzati e automatici

Last reviewed 2024-12-08 UTC

Questo documento ti aiuta a pianificare e progettare un percorso di migrazione dai deployment manuali ai deployment automatizzati e containerizzati in Google Cloudutilizzando strumenti cloud-native e servizi gestiti Google Cloud .

Questo documento fa parte della seguente serie in più parti sulla migrazione a Google Cloud:

Questo documento è utile se prevedi di modernizzare i processi di deployment, se esegui la migrazione da processi di deployment manuali e legacy a deployment automatizzati e basati su container o se stai valutando l'opportunità di eseguire la migrazione e vuoi capire come potrebbe essere.

Prima di iniziare questa migrazione, devi valutare l'ambito della migrazione e lo stato dei tuoi processi di deployment attuali e definire le tue aspettative e i tuoi obiettivi. Scegli il punto di partenza in base a come esegui attualmente il deployment dei tuoi carichi di lavoro:

  • Stai eseguendo il deployment dei carichi di lavoro manualmente.
  • Stai eseguendo il deployment dei carichi di lavoro con strumenti di gestione della configurazione (CM).

È difficile passare dai deployment manuali direttamente a quelli completamente automatizzati e basati su container. Ti consigliamo invece di seguire i seguenti passaggi per la migrazione:

  1. Esegui il deployment utilizzando gli strumenti di orchestrazione dei container.
  2. Esegui il deployment automaticamente.

Questo percorso di migrazione è ideale, ma puoi interrompere la migrazione prima se i vantaggi del passaggio al passaggio successivo superano i costi per il tuo caso specifico. Ad esempio, se non prevedi di eseguire il deployment automatico dei tuoi carichi di lavoro, puoi interrompere l'operazione dopo il deployment utilizzando gli strumenti di orchestrazione dei container. Potrai rivisitare questo documento in futuro, quando sarai pronto a continuare il tuo percorso.

Quando passi da un passaggio della migrazione a un altro, c'è una fase di transizione in cui potresti utilizzare contemporaneamente processi di deployment diversi. Infatti, non devi scegliere una sola opzione di deployment per tutti i tuoi carichi di lavoro. Ad esempio, potresti avere un ambiente ibrido in cui esegui il deployment di determinati carichi di lavoro utilizzando strumenti di gestione della configurazione, mentre esegui il deployment di altri carichi di lavoro con strumenti di orchestrazione dei container.

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto in Migrazione a Google Cloud: Guida introduttiva.

Il seguente diagramma illustra il percorso del tuo viaggio di migrazione.

Percorso di migrazione con quattro fasi.

Potresti eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni. Ad esempio, potresti eseguire la migrazione di alcuni workload prima e di altri in un secondo momento. Per ogni iterazione di migrazione separata, segui le fasi del framework di migrazione generale:

  1. Valuta e scopri i tuoi workload e i tuoi dati.
  2. Pianifica e crea una base su Google Cloud.
  3. Esegui la migrazione dei carichi di lavoro e dei dati a Google Cloud.
  4. Ottimizza il tuo ambiente Google Cloud .

Per maggiori informazioni sulle fasi di questo framework, consulta la pagina Eseguire la migrazione a Google Cloud: guida introduttiva.

Per progettare un piano di migrazione efficace, ti consigliamo di convalidare ogni passaggio del piano e di assicurarti di avere una strategia di rollback. Per convalidare il piano di migrazione, consulta la pagina Eseguire la migrazione a Google Cloud: best practice per la convalida di un piano di migrazione.

Eseguire la migrazione agli strumenti di orchestrazione dei container

Uno dei primi passaggi per abbandonare i deployment manuali consiste nell'eseguire il deployment dei carichi di lavoro con strumenti di orchestrazione dei container. In questo passaggio, progetti e implementi un processo di deployment per gestire i carichi di lavoro containerizzati utilizzando strumenti di orchestrazione dei container, come Kubernetes.

Se i tuoi workload non sono già in container, dovrai impegnarti molto per containerizzarli. Non tutti i carichi di lavoro sono adatti alla containerizzazione. Se stai eseguendo il deployment di un carico di lavoro che non è pronto per il cloud o per la containerizzazione, potrebbe non valere la pena containerizzare i carichi di lavoro. Alcuni carichi di lavoro non possono nemmeno supportare la containerizzazione per motivi tecnici o di licenza.

Valutare e individuare i carichi di lavoro

Per definire l'ambito della migrazione, devi prima disporre di un inventario degli artefatti che produci e implementi, nonché delle loro dipendenze da altri sistemi e artefatti. Per creare questo inventario, devi utilizzare le competenze dei team che hanno progettato e implementato i processi di produzione e deployment degli artefatti attuali. Il documento Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro spiega come valutare l'ambiente durante una migrazione e come creare un inventario delle app.

Per ogni artefatto, devi valutare la copertura dei test. Prima di passare al passaggio successivo, devi disporre di una copertura di test adeguata per tutti gli artefatti. Se devi testare e convalidare manualmente ogni artefatto, non benefici dell'automazione. Adotta una metodologia che metta in evidenza l'importanza dei test, come lo sviluppo basato sui test.

Quando valuti i tuoi processi, considera quante versioni diverse dei tuoi artefatti potresti avere in produzione. Ad esempio, se l'ultima versione di un artefatto è diverse versioni più recente delle istanze che devi supportare, devi progettare un modello che supporti entrambe le versioni.

Considera anche la strategia di ramificazione che utilizzi per gestire la tua base di codice. Una strategia di ramificazione è solo una parte di un modello di collaborazione che devi valutare e devi esaminare i processi di collaborazione più ampi all'interno e all'esterno dei tuoi team. Ad esempio, se adotti una strategia di ramificazione flessibile, ma non la adatti al processo di comunicazione, l'efficienza di questi team potrebbe ridursi.

In questa fase di valutazione, determini anche come rendere gli artefatti che stai producendo più efficienti e adatti alla containerizzazione rispetto ai tuoi attuali processi di deployment. Un modo per migliorare l'efficienza è valutare quanto segue:

  • Parti comuni: valuta cosa hanno in comune i tuoi artefatti. Ad esempio, se hai librerie comuni e altre dipendenze di runtime, valuta la possibilità di consolidarle in un unico ambiente di runtime.
  • Requisiti dell'ambiente runtime: valuta se puoi semplificare gli ambienti runtime per ridurre la loro varianza. Ad esempio, se utilizzi ambienti di runtime diversi per eseguire tutti i tuoi workload, valuta la possibilità di partire da una base comune per ridurre il carico di manutenzione.
  • Componenti non necessari: valuta se i tuoi artefatti contengono parti non necessarie. Ad esempio, potresti avere strumenti di utilità, come strumenti di debug e risoluzione dei problemi, che non sono strettamente necessari.
  • Configurazione e inserimento dei secret: valuta il modo in cui configuri gli artefatti in base ai requisiti dell'ambiente di runtime. Ad esempio, il tuo attuale sistema di inserimento della configurazione potrebbe non supportare un ambiente containerizzato.
  • Requisiti di sicurezza: valuta se il modello di sicurezza dei container soddisfa i tuoi requisiti. Ad esempio, il modello di sicurezza di un ambiente containerizzato potrebbe entrare in conflitto con il requisito di un workload di disporre di privilegi di superutente, accesso diretto alle risorse di sistema o tenancy esclusiva.
  • Requisiti della logica di deployment: valuta se devi implementare processi di deployment avanzati. Ad esempio, se devi implementare una procedura di deployment canary, puoi determinare se lo strumento di orchestrazione dei container la supporta.

Pianificare e costruire una base

Nella fase di pianificazione e creazione, esegui il provisioning e la configurazione dell'infrastruttura per svolgere le seguenti operazioni:

  • Supporta i tuoi carichi di lavoro nel tuo ambiente Google Cloud .
  • Collega l'ambiente di origine e l'ambiente Google Cloud per completare la migrazione.

La fase di pianificazione e creazione è composta dalle seguenti attività:

  1. Crea una gerarchia delle risorse.
  2. Configura Identity and Access Management (IAM) di Google Cloud.
  3. Configura la fatturazione.
  4. Configura la connettività di rete.
  5. Rafforza la tua sicurezza.
  6. Configura logging, monitoraggio e avvisi.

Per maggiori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianificare e creare le basi.

Per ottenere la flessibilità necessaria per gestire le risorse Google Cloud , ti consigliamo di progettare una Google Cloud gerarchia delle risorse che supporti più ambienti, ad esempio per i carichi di lavoro di sviluppo, test e produzione.

Quando stabilisci le identità di utenti e servizi, per un isolamento ottimale hai bisogno di almeno unaccount di serviziot per ogni passaggio della procedura di deployment. Ad esempio, se il processo esegue passaggi per produrre l'artefatto e per gestire l'archiviazione di questo artefatto in un repository, sono necessari almeno due service account. Se vuoi eseguire il provisioning e configurare ambienti di sviluppo e test per i tuoi processi di deployment, potresti dover creare più service account. Se hai un insieme distinto di service account per ambiente, rendi gli ambienti indipendenti l'uno dall'altro. Sebbene questa configurazione aumenti la complessità dell'infrastruttura e imponga un carico maggiore al team operativo, ti offre la flessibilità di testare e convalidare in modo indipendente ogni modifica ai processi di deployment.

Devi anche eseguire il provisioning e configurare i servizi e l'infrastruttura per supportare i carichi di lavoro containerizzati:

Utilizzando gli strumenti di orchestrazione dei container, non devi preoccuparti del provisioning dell'infrastruttura quando esegui il deployment di nuovi carichi di lavoro. Ad esempio, puoi utilizzare Autopilot per gestire automaticamente la configurazione del cluster GKE.

Esegui il deployment degli artefatti con gli strumenti di orchestrazione dei container

In base ai requisiti raccolti nella fase di valutazione e nella fase di base di questo passaggio, esegui le seguenti operazioni:

  • Containerizza i tuoi carichi di lavoro.
  • Implementa processi di deployment per gestire i carichi di lavoro containerizzati.

La containerizzazione dei carichi di lavoro è un'attività non banale. Di seguito è riportato un elenco generalizzato di attività che devi adattare ed estendere per containerizzare i tuoi carichi di lavoro. Il tuo obiettivo è soddisfare le tue esigenze, come networking e gestione del traffico, archiviazione permanente, inserimento di secret e configurazioni e requisiti di tolleranza di errore. Questo documento tratta due attività: la creazione di un insieme di immagini container da utilizzare come base e la creazione di un insieme di immagini container per i tuoi carichi di lavoro.

Innanzitutto, automatizzi la produzione di artefatti, in modo da non dover produrre manualmente una nuova immagine per ogni nuovo deployment. Il processo di creazione dell'artefatto deve essere attivato automaticamente ogni volta che il codice sorgente viene modificato, in modo da ricevere un feedback immediato su ogni modifica.

Per produrre ogni immagine, esegui i seguenti passaggi:

  1. Crea l'immagine.
  2. Esegui la suite di test.
  3. Archivia l'immagine in un registro.

Ad esempio, puoi utilizzare Cloud Build per creare gli artefatti, eseguire le suite di test e, se i test hanno esito positivo, archiviare i risultati in Artifact Registry.

Devi anche stabilire regole e convenzioni per identificare gli artefatti. Quando produci le immagini, etichettale in modo che ogni esecuzione dei processi sia ripetibile. Ad esempio, una convenzione comune è quella di identificare le release utilizzando il versioning semantico, in cui vengono taggate le immagini container durante la produzione di una release. Quando produci immagini che richiedono ancora lavoro prima del rilascio, puoi utilizzare un identificatore che le colleghi al punto del codebase da cui il tuo processo le ha prodotte. Ad esempio, se utilizzi repository Git, puoi utilizzare l'hash del commit come identificatore dell'immagine container corrispondente che hai prodotto quando hai eseguito il push di un commit nel ramo principale del repository.

Durante la fase di valutazione di questo passaggio, hai raccolto informazioni sugli artefatti, sulle loro parti comuni e sui requisiti di runtime. Con queste informazioni, puoi progettare e creare un insieme di immagini container di base e un altro insieme di immagini per i tuoi carichi di lavoro. Utilizzi le immagini di base come punto di partenza per creare le immagini per i tuoi carichi di lavoro. Il set di immagini di base deve essere controllato e supportato rigorosamente per evitare la proliferazione di ambienti di runtime non supportati.

Quando produci immagini container da immagini di base, ricorda di estendere le suite di test per coprire le immagini, non solo i carichi di lavoro all'interno di ogni immagine. Puoi utilizzare strumenti come InSpec per eseguire suite di test di conformità nei tuoi ambienti di runtime.

Quando hai terminato di inserire i tuoi carichi di lavoro nei container e di implementare processi per produrre automaticamente queste immagini container, implementa i processi di deployment per utilizzare gli strumenti di orchestrazione dei container. Nella fase di valutazione, utilizzi le informazioni sui requisiti della logica di deployment che hai raccolto per progettare processi di deployment avanzati. Utilizzando gli strumenti di orchestrazione dei container, puoi concentrarti sulla composizione della logica di deployment utilizzando i meccanismi forniti, anziché doverli implementare manualmente. Ad esempio, puoi utilizzare Cloud Deploy per implementare i processi di deployment.

Quando progetti e implementi i processi di deployment, valuta come inserire file di configurazione e secret nei carichi di lavoro e come gestire i dati per i carichi di lavoro stateful. I file di configurazione e l'inserimento di secret sono fondamentali per produrre artefatti immutabili. Se implementi artefatti immutabili, puoi:

  • Ad esempio, puoi eseguire il deployment degli artefatti nel tuo ambiente di sviluppo. Dopodiché, dopo averli testati e convalidati, li sposti nell'ambiente di controllo qualità. Infine, li sposti nell'ambiente di produzione.
  • Riduzione delle probabilità di problemi negli ambienti di produzione perché lo stesso artefatto è stato sottoposto a più attività di test e convalida.

Se i tuoi workload sono stateful, ti consigliamo di eseguire il provisioning e configurare lo spazio di archiviazione permanente necessario per i tuoi dati. Su Google Cloud, hai diverse opzioni:

Ottimizzare l'ambiente

Dopo aver implementato il processo di deployment, puoi utilizzare gli strumenti di orchestrazione dei container per iniziare a ottimizzare i processi di deployment. Per maggiori informazioni, vedi Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente.

I requisiti di questa iterazione di ottimizzazione sono i seguenti:

  • Estendi il sistema di monitoraggio in base alle esigenze.
  • Estendi la copertura dei test.
  • Aumenta la sicurezza del tuo ambiente.

Estendi il sistema di monitoraggio per coprire la nuova produzione di artefatti, i processi di deployment e tutti i nuovi ambienti di runtime.

Se vuoi monitorare, automatizzare e codificare in modo efficace i tuoi processi il più possibile, ti consigliamo di aumentare la copertura dei test. Nella fase di valutazione, hai verificato di avere almeno una copertura minima dei test end-to-end. Durante la fase di ottimizzazione, puoi espandere le suite di test per coprire più casi d'uso.

Infine, se vuoi aumentare la sicurezza dei tuoi ambienti, puoi configurare l'autorizzazione binaria per consentire il deployment nei cluster solo di un insieme di immagini firmate. Puoi anche attivare Artifact Analysis per analizzare le immagini container archiviate in Artifact Registry alla ricerca di vulnerabilità.

Esegui la migrazione all'automazione del deployment

Dopo la migrazione agli strumenti di orchestrazione dei container, puoi passare all'automazione completa del deployment ed estendere i processi di produzione e deployment degli artefatti per eseguire il deployment automatico dei tuoi workload.

Valutare e individuare i carichi di lavoro

Basandoti sulla valutazione precedente, ora puoi concentrarti sui requisiti dei tuoi processi di deployment:

  • Passaggi di approvazione manuale: valuta se devi supportare passaggi manuali nei processi di deployment.
  • Unità di deployment per unità di tempo: valuta quante unità di deployment per unità di tempo devi supportare.
  • Fattori che causano un nuovo deployment: valuta quali sistemi esterni interagiscono con i tuoi processi di deployment.

Se devi supportare i passaggi di deployment manuale, non significa che la tua procedura non possa essere automatizzata. In questo caso, automatizzi ogni passaggio del processo e inserisci i punti di approvazione manuale dove opportuno.

Supportare più deployment al giorno o all'ora è più complesso che supportare pochi deployment al mese o all'anno. Tuttavia, se non esegui spesso il deployment, la tua agilità e la tua capacità di reagire ai problemi e di rilasciare nuove funzionalità nei tuoi carichi di lavoro potrebbero essere ridotte. Per questo motivo, prima di progettare e implementare un processo di deployment completamente automatizzato, è consigliabile definire le aspettative e gli obiettivi.

Valuta anche quali fattori attivano un nuovo deployment negli ambienti di runtime. Ad esempio, potresti eseguire il deployment di ogni nuova release nell'ambiente di sviluppo, ma eseguire il deployment della release nell'ambiente di controllo qualità solo se soddisfa determinati criteri di qualità.

Pianificare e costruire una base

Per ampliare le basi create nel passaggio precedente, esegui il provisioning e configura i servizi per supportare i processi di deployment automatizzati.

Per ogni ambiente di runtime, configura l'infrastruttura necessaria per supportare i processi di deployment. Ad esempio, se esegui il provisioning e la configurazione dei processi di deployment negli ambienti di sviluppo, garanzia di qualità, pre-produzione e produzione, hai la libertà e la flessibilità di testare le modifiche ai processi. Tuttavia, se utilizzi una singola infrastruttura per il deployment degli ambienti di runtime, gli ambienti sono più semplici da gestire, ma meno flessibili quando devi modificare i processi.

Quando esegui il provisioning dei service account e dei ruoli, valuta la possibilità di isolare gli ambienti e i carichi di lavoro creando service account dedicati che non condividano le responsabilità. Ad esempio, non riutilizzare gli stessi account di servizio per i diversi ambienti di runtime.

Esegui il deployment degli artefatti con processi completamente automatizzati

In questa fase, configuri i processi di deployment per eseguire il deployment degli artefatti senza interventi manuali, ad eccezione dei passaggi di approvazione.

Puoi utilizzare strumenti come Cloud Deploy per implementare i processi di deployment automatizzati, in base ai requisiti raccolti nella fase di valutazione di questo passaggio di migrazione.

Per qualsiasi artefatto, ogni processo di deployment deve eseguire le seguenti attività:

  1. Esegui il deployment dell'artefatto nell'ambiente di runtime di destinazione.
  2. Inserisci i file di configurazione e i secret nell'artefatto di cui è stato eseguito il deployment.
  3. Esegui la suite di test di conformità sull'artefatto appena implementato.
  4. Promuovi l'artefatto nell'ambiente di produzione.

Assicurati che i processi di deployment forniscano interfacce per attivare nuovi deployment in base ai tuoi requisiti.

La revisione del codice è un passaggio necessario durante l'implementazione di processi di deployment automatizzati, a causa del breve ciclo di feedback che fa parte di questi processi per progettazione. Ad esempio, se implementi modifiche all'ambiente di produzione senza alcuna revisione, influisci sulla stabilità e sull'affidabilità dell'ambiente di produzione. Una modifica non esaminata, con formato non corretto o dannosa potrebbe causare un'interruzione del servizio.

Ottimizzare l'ambiente

Dopo aver automatizzato i processi di deployment, puoi eseguire un'altra iterazione di ottimizzazione. I requisiti di questa iterazione sono i seguenti:

  • Estendi il sistema di monitoraggio per coprire l'infrastruttura che supporta i processi di deployment automatizzati.
  • Implementa pattern di deployment più avanzati.
  • Implementa una procedura di accesso di emergenza.

Un sistema di monitoraggio efficace ti consente di pianificare ulteriori ottimizzazioni per il tuo ambiente. Quando misuri il comportamento del tuo ambiente, puoi trovare eventuali colli di bottiglia che ostacolano le prestazioni o altri problemi, come accessi e exploit non autorizzati o accidentali. Ad esempio, configuri il tuo ambiente in modo da ricevere avvisi quando il consumo di determinate risorse raggiunge una soglia.

Quando riesci a orchestrare in modo efficiente i container, puoi implementare pattern di deployment avanzati a seconda delle tue esigenze. Ad esempio, puoi implementare deployment blu/verde per aumentare l'affidabilità del tuo ambiente e ridurre l'impatto di eventuali problemi per i tuoi utenti.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect