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

Last reviewed 2023-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 Cloud utilizzando strumenti cloud-native e servizi gestiti di Google Cloud.

Questo documento fa parte di una serie in più parti sulla migrazione a Google Cloud:

Questo documento è utile se stai pianificando di modernizzare i processi di deployment, se stai migrando da processi di deployment manuali e legacy a deployment automatici e containerizzati, o se stai valutando l'opportunità di eseguire la migrazione e vuoi scoprire che aspetto potrebbe avere.

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

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

È difficile passare dai deployment manuali direttamente a deployment completamente automatizzati e containerizzati. Consigliamo invece di eseguire i seguenti passaggi di migrazione:

  1. Eseguire il deployment tramite gli strumenti di orchestrazione dei container.
  2. Esegui il deployment automatico.

Durante ogni passaggio della migrazione, segui le fasi definite in Eseguire la migrazione a Google Cloud: inizia:

  1. Valuta e scopri i tuoi carichi di lavoro.
  2. Pianifica e getta le basi.
  3. Esegui il deployment dei tuoi carichi di lavoro.
  4. Ottimizza il tuo ambiente e i tuoi carichi di lavoro.

Il seguente diagramma illustra le fasi della migrazione di ogni passaggio.

Percorso di migrazione con quattro fasi.

Questo percorso di migrazione è ideale, ma puoi interromperti prima del processo di migrazione se i vantaggi del passaggio alla fase successiva superano i costi del tuo caso specifico. Ad esempio, se non prevedi di eseguire il deployment automatico dei carichi di lavoro, puoi interromperlo dopo il deployment utilizzando gli strumenti di orchestrazione dei container. Puoi rivedere questo documento in futuro, quando sarai pronto a proseguire il percorso.

Quando passi da un passaggio della migrazione a un altro, esiste una fase di transizione in cui potresti utilizzare processi di deployment diversi contemporaneamente. Infatti, non è necessario scegliere una sola opzione di deployment per tutti i carichi di lavoro. Ad esempio, potresti avere un ambiente ibrido in cui gestisci la tua infrastruttura applicando il pattern IaC, continuando a eseguire il deployment dei carichi di lavoro con gli strumenti di orchestrazione dei container.

Esegui la migrazione agli strumenti di orchestrazione dei container

Uno dei primi passaggi per abbandonare i deployment manuali è eseguire il deployment dei carichi di lavoro con gli 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 carichi di lavoro non sono già containerizzati, utilizzerai molto lavoro per containerizzarli. Non tutti i carichi di lavoro sono adatti alla containerizzazione. Se esegui il deployment di un carico di lavoro che non è pronto per il cloud o non pronto per la containerizzazione, potrebbe non valere la pena containerizzare i carichi di lavoro. Alcuni carichi di lavoro non supportano nemmeno la containerizzazione, per motivi tecnici o di licenza.

Valuta e scopri i tuoi carichi di lavoro

Per definire l'ambito della migrazione, devi prima avere un inventario degli artefatti che produci e distribuisci insieme alle loro dipendenze da altri sistemi e artefatti. Per creare questo inventario, devi utilizzare le competenze dei team che hanno progettato e implementato i tuoi attuali processi di produzione e deployment degli artefatti. Il documento Migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro descrive come valutare il tuo ambiente durante una migrazione e come creare un inventario di app.

Per ogni artefatto, devi valutare la relativa copertura di test attuale. Prima di andare al passaggio successivo, assicurati di avere una copertura di test adeguata per tutti gli artefatti. Se devi testare e convalidare manualmente ogni artefatto, l'automazione non trarrà vantaggio. Adotta una metodologia che evidenzi l'importanza dei test, come lo sviluppo basato su test.

Quando valuti le procedure, considera quante versioni diverse degli artefatti potresti avere in produzione. Ad esempio, se la versione più recente di un artefatto è preceduta da molte versioni rispetto alle istanze che devi supportare, devi progettare un modello che supporti entrambe le versioni.

Considera anche la strategia di diramazione che utilizzi per gestire il codebase. Una strategia con più diramazioni è solo una parte di un modello di collaborazione che devi valutare e devi valutare 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, determinerai anche come rendere gli artefatti che stai producendo più efficienti e adatti per la containerizzazione rispetto agli 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 ambiente di runtime.
  • Requisiti dell'ambiente di runtime: valuta se puoi semplificare gli ambienti di runtime per ridurne la varianza. Ad esempio, se utilizzi diversi ambienti di runtime per eseguire tutti i tuoi carichi di lavoro, valuta la possibilità di partire da una base comune per ridurre il carico di manutenzione.
  • Componenti non necessari: valuta se gli artefatti contengono parti non necessarie. Ad esempio, potresti avere strumenti di utilità non strettamente necessari, come quelli di debug e risoluzione dei problemi.
  • Configurazione e inserimento dei secret: valuta come stai configurando i tuoi artefatti in base ai requisiti del tuo 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 carico di lavoro di avere privilegi di super user, accesso diretto alle risorse di sistema o single-tenant.
  • Requisiti della logica di deployment: valuta se devi implementare processi di deployment avanzati. Ad esempio, se devi implementare un processo di deployment canary, puoi determinare se lo strumento di orchestrazione dei container lo supporta.

Pianifica e getta le basi

Successivamente, esegui il provisioning e la configurazione dell'infrastruttura e dei servizi Google Cloud per supportare i processi di deployment su Google Cloud. Il documento Migrazione a Google Cloud: crea la tua base contiene indicazioni su come creare le basi.

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

Quando definisci le identità di utente e servizio, per un isolamento ottimale è necessario almeno un account di servizio per ogni passaggio del processo di deployment. Ad esempio, se il tuo processo esegue passaggi per produrre l'artefatto e gestirne l'archiviazione in un repository, sono necessari almeno due account di servizio. Se vuoi eseguire il provisioning e configurare ambienti di sviluppo e test per i processi di deployment, potrebbe essere necessario creare altri account di servizio. Se disponi di un insieme distinto di account di servizio per ambiente, rendi gli ambienti indipendenti gli uni dagli altri. Anche se questa configurazione aumenta la complessità dell'infrastruttura e grava sul team operativo, offre la flessibilità necessaria per testare e convalidare in modo indipendente ogni modifica ai processi di deployment.

Devi inoltre eseguire il provisioning e la configurazione dei servizi e dell'infrastruttura per supportare i carichi di lavoro containerizzati:

Grazie agli 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 tuo 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 queste operazioni:

  • Containerizza i tuoi carichi di lavoro.
  • Implementare procedure 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 è coprire le tue esigenze, come il networking e la gestione del traffico, l'archiviazione permanente, l'inserimento di secret e configurazione e i requisiti di tolleranza agli errori. Questo documento riguarda due attività: la creazione di un set di immagini container da utilizzare come base e la creazione di un set di immagini container per i carichi di lavoro.

In primo luogo, automatizza la produzione degli artefatti, in modo da non dover produrre manualmente una nuova immagine per ogni nuovo deployment. Il processo di creazione degli artefatti dovrebbe essere attivato automaticamente ogni volta che viene modificato il codice sorgente, in modo da avere un feedback immediato su ogni modifica.

Per produrre ogni immagine, esegui questi 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 Container Registry. Per scoprire di più sulla creazione di immagini container, consulta le best practice per la creazione dei container.

Devi inoltre stabilire regole e convenzioni per l'identificazione degli artefatti. Quando produci le immagini, etichettale per rendere ripetibile ogni esecuzione dei tuoi processi. Ad esempio, una convenzione comune è identificare le release utilizzando il controllo delle versioni semantico, che prevede il tagging delle immagini container durante la produzione di una release. Quando produci immagini che hanno ancora bisogno di lavoro prima del rilascio, puoi utilizzare un identificatore che le colleghi al punto del codebase da cui il processo le ha prodotte. Ad esempio, se utilizzi repository Git, puoi utilizzare l'hash del commit come identificatore per l'immagine container corrispondente che hai prodotto quando hai eseguito il push di un commit nel ramo principale del tuo repository.

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

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

Quando hai finito di containerizzare i carichi di lavoro e di implementare le procedure per produrre automaticamente queste immagini container, implementerai le procedure di deployment per utilizzare gli strumenti di orchestrazione dei container. Nella fase di valutazione, utilizzerai le informazioni sui requisiti della logica di deployment che hai raccolto per progettare procedure di deployment avanzate. Grazie agli strumenti di orchestrazione dei container, puoi concentrarti sulla scrittura della logica di deployment utilizzando i meccanismi forniti, anziché doverli implementare manualmente.

Durante la progettazione e l'implementazione delle procedure di deployment, considera come inserire file di configurazione e secrets nei carichi di lavoro e come gestire i dati per i carichi di lavoro stateful. I file di configurazione e l'inserimento dei secret sono fondamentali per produrre artefatti immutabili. Eseguendo il deployment di artefatti immutabili, puoi:

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

Se i carichi di lavoro sono stateful, ti consigliamo di eseguire il provisioning e la configurazione dell'archiviazione permanente necessaria per i dati. Su Google Cloud sono disponibili diverse opzioni:

Quando sei in grado di produrre automaticamente gli artefatti di cui eseguire il deployment, puoi configurare gli ambienti di runtime per gli strumenti che utilizzi per eseguire il deployment dei carichi di lavoro. Per controllare l'ambiente di runtime per gli strumenti di deployment, puoi configurare l'ambiente come build in Cloud Build e utilizzare questa build come unico mezzo per eseguire il deployment degli artefatti nei tuoi ambienti. Se utilizzi Cloud Build, non è necessario che ogni operatore configuri un ambiente di runtime sulle proprie macchine. Puoi controllare immediatamente la procedura che crea l'ambiente di runtime e i suoi contenuti esaminando il codice sorgente della configurazione della build.

Ottimizza il tuo 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, consulta Eseguire la migrazione a Google Cloud: ottimizza il tuo ambiente.

I requisiti di questa iterazione di ottimizzazione sono i seguenti:

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

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

Se vuoi monitorare, automatizzare e codificare il più possibile i processi in modo efficace, ti consigliamo di aumentare la copertura dei test. Nella fase di valutazione, hai verificato di disporre almeno di una copertura di test end-to-end minima. 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 abilitare Artifact Analysis per scansionare le immagini container archiviate in Artifact Registry per rilevare eventuali 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 le procedure di produzione e deployment degli artefatti per eseguire automaticamente il deployment dei tuoi carichi di lavoro.

Valuta e scopri i tuoi carichi di lavoro

Sulla base della valutazione precedente, puoi ora concentrarti sui requisiti dei processi di deployment:

  • Passaggi di approvazione manuali: valuta se è necessario supportare eventuali passaggi manuali nelle procedure di deployment.
  • Unità di deployment per tempo: valuta quante unità di deployment hai bisogno di supportare
  • Fattori che causano un nuovo deployment: valuta quali sistemi esterni interagiscono con le tue procedure di deployment.

Se devi supportare i passaggi di deployment manuale, non significa che la procedura non possa essere automatizzata. In questo caso, automatizzi ogni passaggio della procedura e posizioni i limiti di approvazione manuali dove appropriato.

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, potrebbero essere ridotte l'agilità e la capacità di reagire ai problemi e di distribuire nuove funzionalità nei tuoi carichi di lavoro. Per questo motivo, prima di progettare e implementare una procedura di deployment completamente automatica, è consigliabile definire le aspettative e gli obiettivi.

Valuta anche quali fattori attivano un nuovo deployment nei tuoi ambienti di runtime. Ad esempio, puoi 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à.

Pianifica e getta le basi

Per estendere gli elementi di base creati nel passaggio precedente, esegui il provisioning e la configurazione dei servizi per supportare le procedure di deployment automatizzate.

Per ciascuno dei tuoi ambienti di runtime, configura l'infrastruttura necessaria per supportare le procedure di deployment. Ad esempio, se esegui il provisioning e la configurazione delle procedure di deployment nei tuoi ambienti di sviluppo, garanzia di qualità, pre-produzione e produzione, hai la libertà e la flessibilità di testare le modifiche apportate alle tue procedure. Tuttavia, se utilizzi un'unica infrastruttura per eseguire il deployment degli ambienti di runtime, gli ambienti sono più semplici da gestire, ma meno flessibili quando devi cambiare le procedure.

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

Esegui il deployment degli artefatti con procedure completamente automatizzate

In questa fase, configurerai le procedure di deployment per eseguire il deployment degli artefatti senza alcun intervento manuale, se non tramite passaggi di approvazione.

Puoi utilizzare strumenti come Cloud Deploy per implementare le procedure di deployment automatiche, in base ai requisiti che hai raccolto nella fase di valutazione di questo passaggio della migrazione.

Per ogni artefatto, ogni procedura 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 di cui è stato appena eseguito il deployment.
  4. Promuovi l'artefatto nell'ambiente di produzione.

Assicurati che le procedure di deployment forniscano interfacce per attivare nuovi deployment in base ai tuoi requisiti.

La revisione del codice è un passaggio necessario durante l'implementazione di procedure di deployment automatizzate, a causa del breve ciclo di feedback che fa parte di queste procedure per via della progettazione. Ad esempio, se esegui il deployment di modifiche all'ambiente di produzione senza alcuna revisione, ciò influisce sulla stabilità e sull'affidabilità dell'ambiente di produzione. Una modifica non esaminata, errata o dannosa potrebbe causare un'interruzione del servizio.

Ottimizza il tuo ambiente

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

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

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

Se sei in grado di orchestrare in modo efficiente i container, puoi implementare pattern di deployment avanzati in base alle tue esigenze. Ad esempio, puoi implementare i deployment blu/verde per aumentare l'affidabilità del tuo ambiente e ridurre l'impatto di qualsiasi problema per gli utenti.

Passaggi successivi