Migrazione a Google Cloud: migrazione dai deployment manuali a quelli containerizzati e automatici

Last reviewed 2023-12-08 UTC

Questo documento ti aiuta a pianificare e progettare un percorso di migrazione da manuale ai deployment automatizzati e containerizzati in Google Cloud utilizzando strumenti cloud-native e i servizi gestiti di Google Cloud.

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

Questo documento è utile se hai intenzione di modernizzare il deployment se stai eseguendo la migrazione dai processi di deployment manuale e legacy a deployment automatizzati e containerizzati o se stai valutando l'opportunità eseguire la migrazione.

Prima di avviare la migrazione, ti consigliamo di valutarne l'ambito e lo stato dei tuoi attuali processi di deployment, oltre a definire le tue aspettative e obiettivi. Scegli il punto di partenza in base a come Stai eseguendo il deployment dei tuoi carichi di lavoro:

  • Stai eseguendo 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 ai deployment completamente automatizzati deployment containerizzati. 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.

Durante ogni fase della migrazione, segui le fasi definite nella Eseguire la migrazione a Google Cloud: per iniziare:

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

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

Percorso di migrazione con quattro fasi.

Questo percorso di migrazione è ideale, ma puoi fermarti prima durante il processo se i vantaggi del passaggio alla fase successiva superano i costi caso particolare. 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 vorrai continuare su durante il viaggio.

Quando passi da un passaggio della migrazione all'altro, c'è una fase di transizione in cui potresti utilizzare contemporaneamente procedure di implementazione diverse. Infatti, non è necessario scegliere una sola opzione di deployment per tutti i carichi di lavoro con scale out impegnativi. Ad esempio, ipotizziamo che tu abbia un ambiente ibrido in cui gestisci dell'infrastruttura applicando il pattern IaC, continuando a eseguire il deployment carichi di lavoro con strumenti di orchestrazione dei container.

Esegui la 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 questa fase, devi progettare implementare un processo di deployment per gestire i carichi di lavoro containerizzati utilizzando di orchestrazione dei container, Kubernetes

Se i carichi di lavoro non sono già containerizzato, dedicherai un notevole impegno a containerizzarli. Non tutti i carichi di lavoro 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.

Valuta e scopri i tuoi 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 ricorrere all'esperienza i team che hanno progettato e implementato la produzione attuale degli artefatti i processi di deployment. 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 sua attuale 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. Adottare una metodologia che evidenzi l'importanza dei test, ad esempio sviluppo basato sui test.

Quando valuti le procedure, prendi in considerazione 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 alle procedure di collaborazione più ampie 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 stai producendo più efficienti e adatti alla containerizzazione rispetto alle attuale procedure di implementazione. 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 ridurne la varianza. Ad esempio, se utilizzi ambienti di runtime diversi 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 elementi non necessari parti. Potresti, ad esempio, avere strumenti di utilità, come il debug e strumenti per la risoluzione dei problemi che non sono strettamente necessari.
  • Configurazione e inserimento di secret: valuta il tuo rendimento e configurare gli artefatti in base ai requisiti del runtime completamente gestito di Google Cloud. 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 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 è necessario implementare soluzioni avanzate i processi di deployment. Ad esempio, se devi implementare una procedura di deployment canary, puoi determinare se lo strumento di orchestrazione dei container la supporta.

Pianifica e costruisci le basi

Poi esegui il provisioning e la configurazione dell'infrastruttura e dei servizi Google Cloud per supportare le tue procedure di implementazione su Google Cloud. La Esegui la migrazione a Google Cloud: pianifica e costruisci le tue basi documento contiene indicazioni su come costruire le tue basi.

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

Quando stabilisci identità di utenti e servizi, per un isolamento ottimale ti serve almeno un account di servizio per ogni passaggio del processo di deployment. 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 tra loro. Anche se questo aumenta la complessità della tua infrastruttura per il team operativo, offre la flessibilità necessaria per testare e convalidare ogni modifica ai processi di deployment.

Devi inoltre eseguire il provisioning e configurare i servizi 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. Per Ad esempio, puoi utilizzare Pilota automatico per gestire automaticamente la configurazione del cluster GKE.

Esegui il deployment dei tuoi artefatti con 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 carichi di lavoro.
  • Implementa procedure di deployment per gestire i carichi di lavoro containerizzati.

La containerizzazione dei carichi di lavoro è un'attività non banale. Di seguito è riportato un un elenco generalizzato di attività che devi adattare ed estendere per containerizzare carichi di lavoro con scale out impegnativi. 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 tratta due attività: la creazione di un set di immagini container da usare come base 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. L'artefatto dovrebbe essere attivato automaticamente ogni volta che il codice sorgente modificati in modo da avere 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. Archiviare l'immagine in un registro.

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 l'identificazione artefatti. Quando produci le immagini, etichettale in modo da renderle l'esecuzione dei processi è ripetibile. Ad esempio, una convenzione molto diffusa è identificare le release utilizzando controllo delle versioni semantico in cui codifichi le immagini container durante la produzione di una release. Quando per produrre immagini che devono ancora essere elaborate prima di essere rilasciate, puoi usare un identificatore che li collega al punto del codebase da cui il processo le ha 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. Puoi utilizzare le immagini di base come punto di partenza per e creare le immagini per i carichi di lavoro. L'insieme di immagini di base deve essere strettamente controllati e supportati per evitare la proliferazione ambienti di runtime.

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, ServerSpec e RSpec 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 valutazione di deployment, utilizzerai le informazioni sui requisiti della logica di deployment raccolte per progettare procedure di deployment avanzate. Utilizzando il container di orchestrazione, puoi concentrarti sulla composizione della logica di deployment usando i meccanismi forniti, invece di doverli implementare manualmente.

Quando progetti e implementi le tue procedure di deployment, valuta come inserire di configurazione e segreti per i carichi di lavoro e come gestire i dati per i carichi di lavoro stateful. Configurazione e l'iniezione segreta sono fondamentali per produrre artefatti immutabili. Se esegui il deployment di elementi immutabili, puoi:

  • Ad esempio, puoi eseguire il deployment degli artefatti nel tuo ambiente di sviluppo. Poi, dopo averli testati e convalidati, li sposti nella tua valutazione un ambiente di garanzia. Infine, li sposti nell'ambiente di produzione.
  • Riducono le probabilità di problemi nei tuoi ambienti di produzione perché 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 l'archiviazione permanente necessaria per i dati. Su Google Cloud hai diverse opzioni:

Quando riesci a produrre automaticamente gli elementi da eseguire il deployment, puoi configurare gli ambienti di runtime per gli strumenti che utilizzi per eseguire il deployment dei tuoi carichi di lavoro. Per controllare l'ambiente di runtime per gli strumenti di deployment, puoi configurare l'ambiente come build in Cloud Build e utilizzarla come unico mezzo per eseguire il deployment degli elementi nei tuoi ambienti. Utilizzando Cloud Build, non sono necessari i singoli operatori per configurare un runtime dell'ambiente sui propri computer. Puoi verificare immediatamente la procedura crea l'ambiente di runtime e i suoi contenuti esaminando il codice sorgente della configurazione della build.

Ottimizza l'ambiente

Dopo aver implementato il processo di deployment, puoi utilizzare l'orchestrazione dei container per iniziare a ottimizzare i processi di deployment. Per ulteriori informazioni, 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 esigenze.
  • Espandere la copertura dei test.
  • Aumenta la sicurezza del tuo ambiente.

Estendi il sistema di monitoraggio per coprire la produzione di nuovi artefatti, delle procedure di deployment e di 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, configura autorizzazione binaria per consentire il deployment nei cluster solo di un set di immagini firmate. Puoi abilitare anche Analisi degli artefatti per scansionare le immagini container archiviate in Artifact Registry le vulnerabilità.

Esegui la migrazione all'automazione del deployment

Dopo la migrazione agli strumenti di orchestrazione dei container, puoi passare all'automazione completa del deployment e 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

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

  • Procedura di approvazione manuale: valuta se devi supportare eventuali passaggi manuali nelle 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 procedure di deployment.

Se devi supportare passaggi di deployment manuale, non significa che il tuo non possono essere automatizzati. In questo caso, automatizzi ogni passaggio della procedura 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 offrire nuove funzionalità. carichi di lavoro ridotti. Per questo motivo, prima di progettare e implementare una procedura di deployment completamente automatizzata, è 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 di qualità se soddisfa determinati criteri di qualità.

Pianificare e creare una base

Per estendere gli elementi di base che hai creato nel passaggio precedente, esegui il provisioning e configurare i servizi per supportare le procedure di deployment automatizzato.

Per ciascuno dei tuoi ambienti di runtime, configura le necessarie dell'infrastruttura per supportare le tue procedure di deployment. Ad esempio, se esegui il provisioning e configuri le procedure di deployment negli ambienti di sviluppo, di garanzia di qualità, di pre-produzione e di produzione, hai la libertà e la flessibilità di testare le modifiche alle procedure. Tuttavia, se utilizzi una sola dell'infrastruttura per il deployment degli ambienti di runtime, più semplice da gestire, ma meno flessibile quando è necessario 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 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 artefatti con procedure completamente automatiche

In questa fase, configurerai le procedure di deployment per eseguire il deployment artefatti senza interventi manuali, ad eccezione delle fasi 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 specifico, ogni procedura di deployment deve eseguire quanto segue 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'elemento appena disegnato.
  4. Promuovi l'artefatto nell'ambiente di produzione.

Assicurati che le procedure di deployment forniscano interfacce per attivare nuovi deployment in base alle tue esigenze.

La revisione del codice è un passaggio necessario per l'implementazione del deployment automatico perché il breve ciclo di feedback fa parte di queste procedure è stato progettato. 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 l'ambiente

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

  • Estendi il tuo sistema di monitoraggio in modo da coprire l'infrastruttura di supporto le tue procedure di deployment automatizzato.
  • 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 stanno ostacolando le prestazioni 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 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 deployment blu/verde per aumentare l'affidabilità del tuo ambiente e ridurre l'impatto delle per i tuoi utenti.

Passaggi successivi