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 containerizzati e automatici in Google CloudGoogle Cloud utilizzando strumenti cloud-native e servizi gestiti.

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

Questo documento è utile se stai pianificando di modernizzare le tue procedure di deployment, se stai eseguendo la migrazione da procedure di deployment manuali e precedenti a deployment automatizzati e in container o se stai valutando la possibilità di eseguire la migrazione e vuoi capire come potrebbe essere.

Prima di iniziare questa migrazione, devi valutare l'ambito della migrazione e lo stato delle tue attuali procedure di implementazione, nonché impostare le tue aspettative e i tuoi obiettivi. Scegli il punto di partenza in base a come implementi attualmente i tuoi carichi di lavoro:

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

È difficile passare dai deployment manuali direttamente a quelli completamente automatizzati e con 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 procedura di 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 carichi di lavoro, puoi interrompere il processo dopo il deployment utilizzando gli strumenti di orchestrazione dei container. Puoi rivedere questo documento in futuro, quando sarà tutto pronto per continuare il tuo percorso.

Quando passi da un passaggio della migrazione all'altro, c'è una fase di transizione in cui potresti utilizzare contemporaneamente procedure di implementazione diverse. In effetti, 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 gli strumenti di CM, mentre esegui il deployment di altri carichi di lavoro con gli strumenti di orchestrazione dei container.

Per questa migrazione a Google Cloud, ti consigliamo di seguire il framework di migrazione descritto inEseguire la migrazione a Google Cloud: inizia.

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

Percorso di migrazione con quattro fasi.

Puoi eseguire la migrazione dall'ambiente di origine a Google Cloud in una serie di iterazioni, ad esempio puoi eseguire la migrazione di alcuni workload prima e di altri più tardi. Per ogni iterazione di migrazione distinta, segui le fasi del framework di migrazione generale:

  1. Valuta e scopri i tuoi carichi di lavoro 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 Google Cloud ambiente.

Per ulteriori informazioni sulle fasi di questo framework, consulta Eseguire la migrazione a Google Cloud: inizia.

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 aiutarti a convalidare il piano di migrazione, consulta Eseguire la migrazione a Google Cloud: best practice per convalidare un piano di migrazione.

Migrazione agli strumenti di orchestrazione dei container

Uno dei primi passaggi per passare dai 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, dovrai dedicare molto impegno alla loro containerizzazione. Non tutti i workload sono adatti alla containerizzazione. Se stai implementando un carico di lavoro che non è pronto per il cloud o per la containerizzazione, potrebbe non valere la pena di containerizzarlo. Alcuni carichi di lavoro non possono nemmeno supportare la containerizzazione per motivi tecnici o di licenza.

Valutare e scoprire i carichi di lavoro

Per definire l'ambito della migrazione, devi prima avere un inventario degli elementi che stai producendo e di cui stai eseguendo il deployment, insieme alle relative dipendenze da altri sistemi ed elementi. Per creare questo inventario, devi utilizzare le competenze dei team che hanno progettato e implementato le attuali procedure di produzione e di implementazione degli elementi. Il documento Esegui la migrazione a Google Cloud: valuta e scopri i tuoi carichi di lavoro illustra come valutare l'ambiente durante una migrazione e come creare un inventario di app.

Per ogni elemento, devi valutare la relativa copertura dei test. Prima di procedere con il passaggio successivo, devi disporre di una copertura di test adeguata per tutti gli elementi. Se devi testare e convalidare manualmente ogni artefatto, non puoi usufruire dell'automazione. Adotta una metodologia che metta in evidenza l'importanza dei test, come lo sviluppo guidato dai test.

Quando valuti le tue procedure, tieni conto di quante versioni diverse dei tuoi elementi potresti avere in produzione. Ad esempio, se la versione più recente di un elemento è molto più avanti rispetto alle istanze che devi supportare, devi progettare un modello che supporti entrambe le versioni.

Prendi in considerazione anche la strategia di branching che utilizzi per gestire il codebase. Una strategia di ramificazione è solo una parte di un modello di collaborazione che devi valutare, oltre ai processi di collaborazione più ampi all'interno e all'esterno dei tuoi team. Ad esempio, se adotti una strategia di branching flessibile, ma non la adatti al processo di comunicazione, l'efficienza di questi team potrebbe essere ridotta.

In questa fase di valutazione, puoi anche stabilire in che modo rendere gli elementi che produci più efficienti e adatti alla containerizzazione rispetto alle tue attuali procedure di implementazione. Un modo per migliorare l'efficienza è valutare quanto segue:

  • Componenti comuni: valuta cosa hanno in comune i tuoi elementi. 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 ridurne la 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 gli elementi contengono parti non necessarie. Ad esempio, potresti avere strumenti di utilità, come strumenti di debugging e risoluzione dei problemi, che non sono strettamente necessari.
  • Configurazione e inserimento di secret: valuta come stai configurando gli elementi 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 del contenitore soddisfa i tuoi requisiti. Ad esempio, il modello di sicurezza di un ambiente con contenitori potrebbe essere in conflitto con il requisito di un carico di lavoro che prevede privilegi di superutente, accesso diretto alle risorse di sistema o proprietà esclusiva.
  • Requisiti della logica di deployment: valuta se devi implementare procedure di deployment avanzate. Ad esempio, se devi implementare una procedura di deployment canary, puoi determinare se lo strumento di orchestrazione dei container la supporta.

Pianificare e creare una base

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

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

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

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

Per ulteriori informazioni su ciascuna di queste attività, consulta la sezione Eseguire la migrazione a Google Cloud: pianifica e crea le basi.

Per ottenere la flessibilità necessaria per gestire le Google Cloud risorse, 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à utente e di servizio, per un isolamento ottimale è necessario almeno un account di servizio per ogni passaggio della procedura di implementazione. Ad esempio, se il processo esegue i passaggi per produrre l'elemento e per gestire lo spazio di archiviazione dell'elemento in un repository, sono necessari almeno due account servizio. Se vuoi eseguire il provisioning e configurare ambienti di sviluppo e test per le tue procedure di deployment, potresti dover creare più service account. Se hai un insieme distinto di account di servizio per ambiente, gli ambienti sono indipendenti l'uno dall'altro. Sebbene questa configurazione aumenti la complessità dell'infrastruttura e aumenti il carico del team operativo, ti offre la flessibilità di testare e convalidare in modo indipendente ogni modifica ai processi di implementazione.

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

Utilizzando gli strumenti di orchestrazione dei container, non devi preoccuparti di eseguire il 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 elementi con gli strumenti di orchestrazione dei container

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

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

La containerizzazione dei carichi di lavoro non è un'operazione banale. Di seguito è riportato un elenco generale di attività che devi adattare ed estendere per containerizzare i carichi di lavoro. Il tuo obiettivo è soddisfare le tue esigenze, ad esempio la gestione della rete e del traffico, lo spazio di archiviazione permanente, l'iniezione di secret e configurazione e i requisiti di tolleranza di errore. Questo documento illustra 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 degli elementi, in modo da non dover produrre manualmente una nuova immagine per ogni nuovo deployment. Il processo di compilazione degli elementi 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 registry.

Ad esempio, puoi utilizzare Cloud Build per compilare 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 elementi. Quando produci le immagini, etichettale per rendere ripetibile ogni esecuzione delle tue procedure. Ad esempio, una convenzione molto utilizzata è identificare le release utilizzando il versionamento semantico, in cui tagghi le immagini dei contenitori durante la produzione di una release. Quando produci immagini che richiedono ancora lavoro prima del rilascio, puoi utilizzare un identificatore che le collega al punto della base di codice da cui sono state prodotte. Ad esempio, se utilizzi i repository Git, puoi utilizzare l'hash del commit come identificatore dell'immagine contenitore 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 elementi, sulle 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. Utilizza le immagini di base come punto di partenza per creare le immagini per i tuoi carichi di lavoro. L'insieme di immagini di base deve essere sottoposto a un controllo rigoroso e supportato per evitare la proliferazione di ambienti di runtime non supportati.

Quando produci immagini container da immagini di base, ricordati di estendere i set di test in modo che coprano 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.

Al termine della containerizzazione dei carichi di lavoro e dell'implementazione delle procedure per produrre automaticamente queste immagini container, implementa le procedure di deployment per utilizzare gli strumenti di orchestrazione dei container. Nella fase di valutazione, utilizzi le informazioni sui requisiti della logica di implementazione che hai raccolto per progettare processi di implementazione 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 le procedure di deployment, tieni presente come iniettare file di configurazione e secret nei carichi di lavoro e come gestire i dati per i carichi di lavoro con stato. I file di configurazione e l'iniezione di secret sono fondamentali per produrre artefatti immutabili. Se esegui il deployment di elementi immutabili, puoi:

  • Ad esempio, puoi eseguire il deployment degli elementi nell'ambiente di sviluppo. Dopo averli testati e convalidati, li sposti nell'ambiente di controllo qualità. Infine, li sposti nell'ambiente di produzione.
  • Riduci le 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 la configurazione dello spazio di archiviazione permanente necessario per i tuoi dati. Su Google Cloud, hai diverse opzioni:

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 saperne di più, consulta Eseguire la migrazione a Google Cloud: ottimizzare l'ambiente.

I requisiti di questa elaborazione di ottimizzazione sono i seguenti:

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

Espandi il sistema di monitoraggio in modo che includa la produzione di nuovi elementi, le procedure di deployment e tutti i nuovi ambienti di runtime.

Se vuoi monitorare, automatizzare e codificare i tuoi processi nel modo più efficace possibile, ti consigliamo di aumentare la copertura dei test. Nella fase di valutazione, hai verificato di disporre di 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 tuoi cluster solo di un insieme di immagini firmate. Puoi anche attivare Artifact Analysis per eseguire la scansione delle immagini container archiviate in Artifact Registry per rilevare eventuali vulnerabilità.

Eseguire 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 elementi per eseguire il deployment automatico dei tuoi carichi di lavoro.

Valutare e scoprire i carichi di lavoro

Sulla base della valutazione precedente, ora puoi concentrarti sui requisiti delle tue procedure di deployment:

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

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

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

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

Pianificare e creare una base

Per estendere le basi create nel passaggio precedente, esegui il provisioning e la configurazione dei servizi per supportare le procedure di deployment automatico.

Per ogni ambiente di runtime, configura l'infrastruttura necessaria per supportare le procedure di deployment. Ad esempio, se esegui il provisioning e configuri i 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 eseguire il deployment degli ambienti di runtime, questi sono più semplici da gestire, ma meno flessibili quando devi modificare i processi.

Quando esegui il provisioning degli account di servizio e dei ruoli, valuta la possibilità di isolare gli ambienti e i workload tra loro creando account di servizio dedicati che non condividono le responsabilità. Ad esempio, non riutilizzare gli stessi account di servizio per i diversi ambienti di runtime.

Esegui il deployment degli elementi con processi completamente automatici

In questa fase, configuri le procedure di deployment per eseguire il deployment degli elementi senza interventi manuali, ad eccezione dei passaggi di approvazione.

Puoi utilizzare strumenti come Cloud Deploy per implementare le procedure di deployment automatico, in base ai requisiti raccolti nella fase di valutazione di questo passaggio di migrazione.

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

  1. Esegui il deployment dell'elemento 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'elemento appena disegnato.
  4. Esegui la promozione dell'elemento 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 per l'implementazione di processi di deployment automatico, a causa del breve ciclo di feedback che fa parte di questi processi per progettazione. Ad esempio, se esegui il deployment di modifiche nell'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.

Ottimizza il tuo ambiente

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

  • Estendi il sistema di monitoraggio in modo da coprire l'infrastruttura che supporta i tuoi processi di deployment automatizzati.
  • Implementare pattern di deployment più avanzati.
  • Implementa un 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 stanno ostacolando il rendimento o altri problemi, come accessi e exploit 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.

Quando riesci a orchestrare in modo efficiente i container, puoi implementare modelli di deployment avanzati in base alle tue esigenze. Ad esempio, puoi implementare i deployment blue/green per aumentare l'affidabilità del tuo ambiente e ridurre l'impatto di eventuali problemi per gli utenti.

Passaggi successivi

Collaboratori

Autore: Marco Ferrari | Cloud Solutions Architect