Questo documento può aiutarti a pianificare e progettare la fase di implementazione della migrazione a Google Cloud. Dopo aver valutato l'ambiente attuale, pianificato la migrazione a Google Cloude creato le basi diGoogle Cloud , puoi eseguire il deployment dei carichi di lavoro.
Questo documento fa parte della seguente serie in più parti sulla migrazione a Google Cloud:
- Esegui la migrazione a Google Cloud: inizia
- Migrazione a Google Cloud: valutazione e individuazione dei carichi di lavoro
- Esegui la migrazione a Google Cloud: pianifica e getta le basi
- Migrazione a Google Cloud: trasferimento dei tuoi set di dati di grandi dimensioni
- Migrazione a Google Cloud: deployment dei carichi di lavoro (questo documento)
- Esegui la migrazione a Google Cloud: esegui la migrazione dai deployment manuali ai deployment automatizzati e basati su container
- Esegui la migrazione a Google Cloud: ottimizza il tuo ambiente
- Migrate to Google Cloud: Best practices for validating a migration plan
- Esegui la migrazione a Google Cloud: riduci al minimo i costi
Il seguente diagramma illustra il percorso del tuo viaggio di migrazione.
La fase di deployment è la terza fase della migrazione a Google Cloud in cui progetti un processo di deployment per i tuoi carichi di lavoro.
Questo documento è utile se stai pianificando una migrazione da un ambiente on-premise, da un ambiente di hosting privato, da un altro cloud provider aGoogle Cloudo se stai valutando l'opportunità di eseguire la migrazione e vuoi esplorare come potrebbe essere.
In questo documento vengono esaminati i diversi tipi di processo di deployment, in ordine di flessibilità, automazione e complessità, insieme ai criteri per scegliere un approccio adatto alle tue esigenze:
- Esegui il deployment manualmente.
- Esegui il deployment con gli strumenti di gestione della configurazione (CM).
- Esegui il deployment utilizzando gli strumenti di orchestrazione dei container.
- Esegui il deployment automaticamente.
Prima di eseguire il deployment dei carichi di lavoro, pianifica e progetta la fase di deployment. Innanzitutto, valuta i diversi tipi di procedure di deployment che implementi per i tuoi carichi di lavoro. Quando valuti i tipi di processo di deployment, puoi decidere di iniziare con un processo mirato e passare a uno più complesso in futuro. Questo approccio può portare a risultati più rapidi, ma può anche introdurre attrito quando passi a un processo più avanzato, perché devi assorbire il debito tecnico accumulato durante l'utilizzo del processo mirato. Ad esempio, se passi da deployment completamente manuali a una soluzione automatizzata, potresti dover gestire gli upgrade della pipeline di deployment e delle app.
Sebbene sia possibile implementare diversi tipi di processi di deployment in base alle esigenze dei carichi di lavoro, questo approccio può anche aumentare la complessità di questa fase. Se implementi diversi tipi di processi di deployment, puoi usufruire della maggiore flessibilità, ma potresti aver bisogno di competenze, strumenti e risorse personalizzati per ogni processo, il che si traduce in un maggiore impegno da parte tua.
Esegui il deployment manualmente
Un deployment completamente manuale è supportato da un processo di provisioning, configurazione e deployment completamente non automatizzato. Sebbene possano esistere specifiche e liste di controllo per ogni fase della procedura, non esiste un controllo o un'applicazione automatica di queste specifiche. Un processo manuale è soggetto a errori umani, non è ripetibile e il suo rendimento è limitato dal fattore umano.
I processi di deployment completamente manuali possono essere utili, ad esempio, quando devi strumentare rapidamente un esperimento in un ambiente sandbox. La configurazione di un processo strutturato e automatizzato per un esperimento che dura pochi minuti può rallentare inutilmente il tuo ritmo, soprattutto nelle prime fasi della migrazione, quando potresti non avere le competenze necessarie negli strumenti e nelle pratiche che ti consentono di creare un processo automatizzato.
Sebbene questa limitazione non si applichi a Google Cloud, le implementazioni completamente manuali potrebbero essere la tua unica opzione quando hai a che fare con ambienti bare metal che non dispongono delle API di gestione necessarie. In questo caso, non puoi implementare un processo automatizzato a causa della mancanza delle interfacce necessarie. Se hai un'infrastruttura virtualizzata legacy che non supporta l'automazione, potresti essere costretto a implementare una procedura completamente manuale.
Ti consigliamo di evitare un deployment completamente manuale a meno che non tu non abbia altre opzioni.
Puoi implementare un processo di provisioning, configurazione e deployment completamente manuale utilizzando strumenti come la consoleGoogle Cloud , Cloud Shell, API Cloud e Google Cloud CLI.
Esegui il deployment con gli strumenti di gestione della configurazione
Gli strumenti di gestione della configurazione ti consentono di configurare un ambiente in modo ripetibile e controllato. Questi strumenti includono un insieme di plug-in e moduli che implementano già operazioni di configurazione comuni. Questi strumenti ti consentono di concentrarti sullo stato finale che vuoi raggiungere per il tuo ambiente, anziché implementare la logica per raggiungere questo stato finale. Se il set di operazioni incluso non è sufficiente, gli strumenti CM spesso includono un sistema di estensioni che puoi utilizzare per sviluppare i tuoi moduli. Sebbene queste estensioni siano possibili, prova a utilizzare i moduli e i plug-in predefiniti, ove applicabile, per evitare un carico di sviluppo e manutenzione aggiuntivo.
Utilizzi gli strumenti di CM quando devi configurare gli ambienti. Puoi anche utilizzarli per eseguire il provisioning dell'infrastruttura e implementare un processo di deployment per i tuoi carichi di lavoro. Gli strumenti di gestione della configurazione sono un processo migliore rispetto a un processo di provisioning, configurazione e deployment completamente manuale perché è ripetibile, controllato e verificabile. Tuttavia, ci sono diversi svantaggi, perché gli strumenti CM non sono progettati per attività di provisioning o deployment. Di solito non dispongono di funzionalità integrate per implementare una logica di provisioning elaborata, come il rilevamento e la gestione delle differenze tra lo stato reale dell'infrastruttura e lo stato desiderato o processi di deployment avanzati, come i deployment senza tempi di inattività o i deployment blu/verdi. Puoi implementare le funzionalità mancanti utilizzando i punti di estensione menzionati in precedenza. Queste estensioni possono comportare un impegno maggiore e aumentare la complessità complessiva del processo di implementazione, perché richiedono le competenze necessarie per progettare, sviluppare e gestire una soluzione di implementazione personalizzata.
Puoi implementare questo tipo di provisioning, configurazione e deployment utilizzando strumenti come Ansible, Chef, Puppet e SaltStack.
Un processo di deployment di base che utilizza gli strumenti CM può preparare gli ambienti di runtime ed eseguire il deployment dei carichi di lavoro in questi ambienti. Ad esempio, il tuo processo potrebbe creare un'istanza Compute Engine, installare il software richiesto e eseguire il deployment dei tuoi workload. La configurazione di un ambiente di runtime che supporti i tuoi carichi di lavoro richiede tempo. Per ridurre il tempo necessario per configurare un ambiente di runtime, puoi implementare un processo che esegue gli strumenti CM per produrre un modello, ad esempio un'immagine del sistema operativo. Puoi utilizzare questo modello per creare istanze del tuo ambiente di runtime pronte per i tuoi carichi di lavoro. Ad esempio, puoi utilizzare Cloud Build per creare immagini Compute Engine. Queste immagini vengono spesso chiamate golden image o silver image, entrambe modelli immutabili, come le immagini del sistema operativo, che crei per i tuoi ambienti di runtime. La differenza tra i due dipende dalla quantità di lavoro che un processo di deployment deve completare prima che le immagini possano eseguire un workload:
- Golden image: un modello che crei per i tuoi ambienti di runtime o che prepari da un modello di base. Le golden image includono tutti i dati e le informazioni di configurazione necessari agli ambienti di runtime per svolgere le attività assegnate. Puoi preparare diversi tipi di immagini dorate per svolgere attività diverse. I sinonimi di tipi di immagini dorate includono varianti, versioni e archetipi.
- Immagine silver: un modello che crei per i tuoi ambienti di runtime applicando modifiche minime a un'immagine golden o a un modello di base. Gli ambienti di runtime che eseguono un'immagine silver completano il provisioning e la configurazione al primo avvio, in base alle esigenze dei casi d'uso che devono supportare.
Esegui il deployment utilizzando gli strumenti di orchestrazione dei container
Se hai già investito o prevedi di investire nella containerizzazione dei tuoi carichi di lavoro, puoi utilizzare uno strumento di orchestrazione dei container per eseguire il deployment dei tuoi carichi di lavoro.
Uno strumento di orchestrazione dei container si occupa della gestione dell'infrastruttura che supporta il tuo ambiente e supporta un'ampia gamma di operazioni e blocchi di costruzione di deployment per implementare la logica di deployment che puoi utilizzare quando quelli integrati non sono sufficienti. Utilizzando questi strumenti, puoi concentrarti sulla composizione della logica di deployment effettiva utilizzando i meccanismi forniti, anziché doverli implementare.
Gli strumenti di orchestrazione dei container forniscono anche astrazioni che puoi utilizzare per generalizzare i processi di deployment in diversi ambienti sottostanti, in modo da non dover progettare e implementare più processi per ciascuno dei tuoi ambienti. Ad esempio, questi strumenti di solito includono la logica per lo scaling e l'upgrade dei deployment, quindi non devi implementarli autonomamente. Puoi persino iniziare a sfruttare questi strumenti per implementare i processi di deployment nell'ambiente attuale e poi trasferirli nell'ambiente di destinazione, perché l'implementazione è in gran parte la stessa, per progettazione. Se adotti questi strumenti in anticipo, acquisisci esperienza nell'amministrazione di ambienti in contenitori, e questa esperienza è utile per la migrazione a Google Cloud.
Utilizzi uno strumento di orchestrazione dei container se i tuoi carichi di lavoro sono già in container o se puoi inserirli in container in futuro e prevedi di investire in questo sforzo. In quest'ultimo caso, devi eseguire un'analisi approfondita di ogni workload per determinare quanto segue:
- Assicurati che sia possibile la containerizzazione del workload.
- Valuta i potenziali vantaggi che potresti ottenere containerizzando il carico di lavoro.
Se i potenziali problemi superano i vantaggi della containerizzazione, devi utilizzare uno strumento di orchestrazione dei container solo se i tuoi team si sono già impegnati a utilizzarli e se non vuoi gestire ambienti eterogenei.
Ad esempio, le soluzioni di data warehouse non vengono in genere implementate utilizzando strumenti di orchestrazione dei container, perché non sono progettate per essere eseguite in container effimeri.
Puoi implementare questo processo di deployment utilizzando Google Kubernetes Engine (GKE) su Google Cloud. Se ti interessa un ambiente serverless, puoi utilizzare strumenti come Cloud Run.
Esegui il deployment automatico
Indipendentemente dagli strumenti di provisioning, configurazione, deployment e orchestrazione che utilizzi nel tuo ambiente, puoi implementare processi di deployment completamente automatizzati per ridurre al minimo gli errori umani e per consolidare, semplificare e standardizzare i processi in tutta l'organizzazione. Se necessario, puoi anche inserire passaggi di approvazione manuale nel processo di deployment, ma ogni passaggio è automatizzato.
I passaggi di una tipica pipeline di deployment end-to-end sono i seguenti:
- Revisione del codice.
- Integrazione continua (CI).
- Produzione di artefatti.
- Deployment continuo (CD), con approvazioni manuali finali.
Puoi automatizzare ogni passaggio in modo indipendente dagli altri, in modo da poter eseguire la migrazione graduale dei processi di deployment attuali verso una soluzione automatizzata oppure implementare un nuovo processo direttamente nell'ambiente di destinazione. Affinché questa procedura sia efficace, sono necessarie procedure di test e convalida in ogni passaggio della pipeline, non solo durante il passaggio di revisione del codice o il passaggio di CI.
Per ogni modifica al codebase, devi eseguire una revisione approfondita per valutare la qualità della modifica. La maggior parte degli strumenti di gestione del codice sorgente supporta la revisione del codice di primo livello. Spesso supportano anche la creazione e l'inizializzazione automatiche delle revisioni esaminando l'area del codice sorgente modificata, a condizione che tu abbia configurato i team responsabili di ogni area del tuo codebase. In ogni revisione puoi anche eseguire controlli automatici sul codice sorgente, ad esempio linters e analizzatori statici per applicare standard di coerenza e qualità in tutto il codebase.
Dopo aver esaminato e integrato una modifica nel codebase, lo strumento CI può eseguire automaticamente i test, valutare i risultati e quindi notificarti eventuali problemi con la build corrente. Puoi aggiungere valore a questo passaggio seguendo un processo di sviluppo basato sui test per una copertura completa dei test delle funzionalità di ogni carico di lavoro.
Per ogni build riuscita, puoi automatizzare la creazione di artefatti di deployment. Questi artefatti rappresentano una versione delle tue applicazioni pronta per il deployment, con le modifiche più recenti. Nell'ambito del passaggio di creazione dell'artefatto, puoi anche eseguire una convalida automatizzata dell'artefatto stesso. Ad esempio, esegui una scansione delle vulnerabilità rispetto ai problemi noti e approvi l'artefatto per il deployment solo se non vengono rilevate vulnerabilità. Ad esempio, puoi utilizzare Artifact Registry per analizzare gli artefatti alla ricerca di vulnerabilità note.
Infine, puoi automatizzare il deployment di ogni artefatto approvato nell'ambiente di destinazione. Se hai più ambienti di runtime, puoi anche implementare una logica di deployment univoca per ciascuno, aggiungendo anche passaggi di approvazione manuale, se necessario. Ad esempio, puoi eseguire il deployment automatico di nuove versioni dei tuoi carichi di lavoro negli ambienti di sviluppo, controllo qualità e pre-produzione, richiedendo comunque una revisione e un'approvazione manuali da parte del tuo team di controllo della produzione per il deployment nell'ambiente di produzione.
Sebbene un processo end-to-end completamente automatizzato sia una delle opzioni migliori se hai bisogno di un processo automatizzato, strutturato, semplificato e controllabile, l'implementazione di questo processo non è un'attività banale. Prima di scegliere questo tipo di processo, devi avere una visione chiara dei vantaggi previsti, dei costi coinvolti e se il tuo attuale livello di conoscenza ed esperienza del team è sufficiente per implementare un processo di deployment completamente automatizzato.
Puoi implementare processi di deployment completamente automatizzati con Cloud Deploy.
Passaggi successivi
- Scopri come eseguire la migrazione dei processi di deployment.
- Scopri quando trovare assistenza per le migrazioni.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autore: Marco Ferrari | Cloud Solutions Architect