Questo documento fornisce una panoramica delle applicazioni di uso comune pattern di deployment e test. Prende in esame il funzionamento degli schemi, i vantaggi offerti e gli aspetti da considerare quando li implementi.
Supponiamo di voler eseguire l'upgrade di un'applicazione in esecuzione a una nuova versione. Per garantire un'implementazione semplice, di solito prendi in considerazione quanto segue:
- Come ridurre al minimo i tempi di inattività delle applicazioni, se presenti.
- Come gestire e risolvere gli incidenti con un impatto minimo sugli utenti.
- Come gestire i deployment non riusciti in modo affidabile ed efficace.
- come ridurre al minimo le persone e gli errori nei processi per ottenere risultati e ripetibili.
Il pattern di deployment che scegli dipende molto dai tuoi obiettivi aziendali. Per Ad esempio, potresti dover implementare le modifiche senza tempi di inattività modifiche a un ambiente o a un sottoinsieme di utenti prima di apportare una caratteristica in disponibilità generale. Ogni metodologia illustrata in questo documento spiega a determinati obiettivi da raggiungere prima che un deployment venga considerato riuscito.
Questo documento è rivolto agli amministratori di sistema e ai DevOps Engineer che per definire e implementare strategie di rilascio e deployment per applicazioni, sistemi e framework.
Strategie di deployment
Quando esegui il deployment di un servizio, non è sempre esposto immediatamente agli utenti. A volte, le modifiche vengono visualizzate dagli utenti solo dopo il rilascio del servizio nell'applicazione. Tuttavia, quando un servizio viene rilasciato sul posto, i deployment e il rilascio avvengono contemporaneamente. In questo caso, quando esegui il deployment della nuova versione, inizia ad accettare traffico di produzione. In alternativa, esistono modelli e il provisioning di più versioni del servizio in parallelo. Questi i pattern di deployment consentono di controllare e gestire la versione che riceve richiesta in entrata. Leggi Kubernetes e le sfide della distribuzione continua del software per saperne di più su deployment, release e concetti correlati.
I pattern di deployment discussi in questa sezione offrono flessibilità automatizzando il rilascio di nuovo software. L'approccio migliore per te dipende in base ai tuoi obiettivi.
Ricrea il pattern di deployment
Con un deployment di nuova creazione, fai fare lo scale down completo dell'applicazione esistente dell'applicazione prima di fare lo scale up della nuova versione dell'applicazione.
Il seguente diagramma mostra come funziona il deployment di una nuova creazione per un'applicazione.
La versione 1 rappresenta la versione corrente dell'applicazione, mentre la versione 2 rappresenta la nuova versione dell'applicazione. Quando aggiorni la versione corrente dell'applicazione, devi prima fare lo scale down delle repliche esistenti della versione 1 fino a zero, il deployment delle repliche con la nuova versione.
Vantaggi principali
Il vantaggio dell'approccio di ricreazione è la sua semplicità. Non è necessario gestire più di una versione dell'applicazione in parallelo, evitando così problemi di compatibilità con le versioni precedenti di dati e applicazioni.
Considerazioni
Il metodo di ricreazione comporta tempi di inattività durante il processo di aggiornamento. Il tempo di riposo è non sarà un problema per le applicazioni in grado di gestire periodi di manutenzione o interruzioni. Tuttavia, se hai applicazioni mission critical con un livello di servizio elevato contratti (SLA) e i requisiti di disponibilità, potresti scegliere la tua strategia di deployment.
Pattern di deployment dell'aggiornamento in sequenza
In un deployment di aggiornamento in sequenza, aggiorni un sottoinsieme dell'applicazione in esecuzione anziché aggiornare contemporaneamente ogni istanza dell'applicazione, il seguente diagramma.
In questo approccio al deployment, il numero di istanze aggiornate è chiamata dimensione della finestra. Nel diagramma precedente, il valore l'aggiornamento in sequenza ha una finestra di 1. Viene aggiornata un'istanza dell'applicazione nel tempo. Se hai un cluster di grandi dimensioni, potresti aumentare la dimensione della finestra.
Gli aggiornamenti in sequenza offrono flessibilità nell'aggiornamento applicazione:
- Puoi fare lo scale up delle istanze dell'applicazione con la nuova versione prima fai fare lo scale down della versione precedente (una procedura nota come upgrade di incremento).
- Puoi specificare il numero massimo di istanze dell'applicazione rimanenti non è disponibile durante lo scale up di nuove istanze in parallelo.
Vantaggi principali
- Zero tempi di inattività. L'aggiornamento viene eseguito in modo incrementale in base alle dimensioni della finestra le destinazioni del deployment, ad esempio, una per una o due per due. Sei tu a indirizzare il traffico verso le destinazioni del deployment aggiornate solo dopo la nuova versione l'applicazione è pronta ad accettare il traffico.
- Rischio di deployment ridotto. Quando implementi un aggiornamento in modo incrementale, le instabilità della nuova versione interessano solo una parte degli utenti.
Considerazioni
- Rollback lento. Se la nuova implementazione non è stabile, puoi terminare le nuove repliche ed eseguire nuovamente il deployment della vecchia versione. Tuttavia, come un'implementazione, il rollback è un processo graduale e incrementale.
- Compatibilità con le versioni precedenti. Perché il nuovo codice e il vecchio codice convivono gli utenti potrebbero essere indirizzati arbitrariamente a una delle versioni. Assicurati quindi che il nuovo deployment sia compatibile con le versioni precedenti. cioè la nuova versione dell'applicazione può leggere e gestire i dati che la vecchia versione negozi. Questi dati possono includere dati archiviati su disco, in un database o come della sessione del browser di un utente.
- Sessioni persistenti. Se l'applicazione richiede persistenza della sessione, consigliamo che il bilanciatore del carico supporti stickiness e lo svuotamento della connessione. Inoltre, ti consigliamo di richiamare la condivisione delle sessioni quando possibile (tramite replica delle sessioni o gestione delle sessioni mediante un datastore), in modo che possono essere disaccoppiate dalle risorse sottostanti.
Pattern di deployment blu/verde
In un deployment blu/verde (noto anche come deployment rosso/nero), devi eseguire due deployment identici della tua applicazione, come mostra il seguente diagramma.
Nel diagramma, il blu rappresenta la versione corrente dell'applicazione e il verde rappresenta la nuova versione dell'applicazione. Pubblica una sola versione alla volta. Il traffico viene instradato al deployment blu mentre viene creato il deployment verde e testati. Al termine del test, instrada il traffico alla nuova versione.
Al termine del deployment, puoi mantenere il deployment blu un possibile rollback o dismissione. In alternativa, puoi eseguire il deployment dell'applicazione su queste istanze. In questo caso, lo stato attuale (blu) l'ambiente di gestione temporanea funge da area di gestione temporanea per la prossima release.
Vantaggi principali
- Zero tempi di inattività. Il deployment blu/verde consente il cutover rapidamente senza tempi di inattività.
- Rollback istantaneo. Puoi eseguire il rollback in qualsiasi momento durante di deployment mediante la regolazione del bilanciatore del carico in modo da reindirizzare il traffico nell'ambiente blu. L'impatto del tempo di inattività è limitato al tempo in cui per passare il traffico all'ambiente blu quando rilevi un problema.
- Separazione dell'ambiente. Il deployment blu/verde assicura che un ambiente verde parallelo non influisce sulle risorse che supportano blu. Questa separazione riduce il rischio di deployment.
Considerazioni
- Costi e overhead operativo. Adottare il deployment blu/verde può aumentare i costi e i costi operativi perché è necessario e mantenere ambienti duplicati con un'infrastruttura identica.
- Compatibilità con le versioni precedenti. I deployment blu e verde possono condividere dati e datastore. Ti consigliamo di verificare che entrambe le versioni l'applicazione può utilizzare lo schema del datastore e il formato del record. Questa compatibilità con le versioni precedenti è necessaria se vuoi passare senza interruzioni tra le due versioni se devi eseguire il rollback.
- Cutover. Se prevedi di ritirare la versione corrente, è consigliabile consentire lo svuotamento della connessione appropriato sugli asset esistenti transazioni e sessioni. Questo passaggio consente l'elaborazione delle richieste il deployment attuale possa essere completato o terminato normalmente.
Strategie di test
I pattern di test discussi in questa sezione sono generalmente utilizzati per convalidare l'affidabilità e la stabilità del servizio in un periodo ragionevole livello di contemporaneità e carico.
Pattern di test canary
Nei test canary, implementi parzialmente una modifica e poi ne valuti la delle prestazioni rispetto a un deployment di base, come mostra il seguente diagramma.
In questo pattern di test, esegui il deployment di una nuova versione dell'applicazione la versione di produzione. Puoi quindi suddividere e indirizzare una percentuale del traffico dalla versione di produzione alla versione canary e valutiamo il valore delle prestazioni.
Devi selezionare le metriche chiave per la valutazione quando configuri la versione canary. Me di confrontare la versione canary con una base di riferimento equivalente e non un ambiente di produzione live.
Per ridurre i fattori che potrebbero influire sull'analisi (ad esempio, memorizzazione nella cache, e oggetti hash), ti consigliamo di seguire questi passaggi per la versione di base della tua applicazione:
- Assicurati che le versioni di base e di produzione della tua applicazione sono identiche.
- Esegui il deployment della versione di base nel momento in cui esegui il deployment della versione canary.
- Assicurati che il deployment di base (ad esempio il numero di istanze istanze e criteri di scalabilità automatica) corrisponde al deployment canary.
- Utilizza la versione di base per gestire lo stesso traffico della versione canary.
Nei test canary, l'implementazione parziale può seguire varie strategie di partizionamento. Ad esempio, se l'applicazione ha utenti distribuiti a livello geografico, puoi prima di implementare la nuova versione in una regione o in una località specifica. Per maggiori informazioni le informazioni, vedi Automazione dell'analisi canary su GKE con Spinnaker.
Vantaggi principali
- Possibilità di testare il traffico di produzione in tempo reale. Anziché testare un utilizzando la simulazione del traffico in un ambiente di gestione temporanea, puoi eseguire test canary sul traffico di produzione in tempo reale. Con le implementazioni canary, di decidere in quali incrementi rilasciare la nuova applicazione e quando per attivare il passaggio successivo in una release. La versione canary ha bisogno di traffico sufficiente il monitoraggio può rilevare chiaramente eventuali problemi.
- Rollback veloce. Puoi eseguire rapidamente il rollback reindirizzando l'utente il traffico alla versione precedente dell'applicazione.
- Zero tempi di inattività. Le versioni canary ti consentono di indirizzare la produzione live a diverse versioni dell'applicazione senza tempi di inattività.
Considerazioni
- Implementazione lenta. Ogni release incrementale richiede il monitoraggio un periodo ragionevole e, di conseguenza, potrebbe ritardare la release complessiva. canary i test possono spesso richiedere diverse ore.
- Osservabilità. Un prerequisito per l'implementazione dei test canary è la capacità di osservare e monitorare in modo efficace l'infrastruttura e lo stack di applicazioni. L'implementazione di un monitoraggio affidabile può richiedere impegno.
- Compatibilità con le versioni precedenti e sessioni fisse. Come per gli aggiornamenti in sequenza, i test canary possono porre dei rischi con incompatibilità con le versioni precedenti persistenza perché nell'ambiente vengono eseguite più versioni dell'applicazione durante il deployment della versione canary.
Pattern del test A/B
Con il test A/B, verifichi un'ipotesi utilizzando implementazioni di varianti. Il test A/B viene usato per prendere decisioni aziendali (non solo per fare previsioni) sulla base di i risultati derivati dai dati.
Quando esegui un test A/B, indirizzi un sottoinsieme di utenti a una nuova funzionalità in base alle regole di routing, come mostra il seguente diagramma.
Le regole di routing spesso includono fattori come la versione del browser, lo user agent, geolocalizzazione e sistema operativo. Dopo aver misurato e confrontato le versioni, aggiorni l'ambiente di produzione con la versione che ha prodotto che consentono di analizzare i dati e visualizzare i risultati.
Vantaggi principali
Il test A/B è consigliato per misurare l'efficacia della funzionalità in una un'applicazione. I casi d'uso per i pattern di deployment discussi in precedenza sono incentrati il rilascio sicuro di nuovo software e il rollback prevedibile. Con il test A/B, controllare il pubblico di destinazione per conoscere le nuove funzionalità e monitorare con rilevanza statistica le differenze nel comportamento degli utenti.
Considerazioni
- Configurazione complessa. I test A/B richiedono campione rappresentativo che può essere utilizzato per dimostrare che una versione è migliore di e l'altro. Devi precalcolare la dimensione del campione (ad esempio, utilizzando una Calcolatrice delle dimensioni del campione per test A/B) ed eseguire i test per un periodo ragionevole per raggiungere la significatività statistica di almeno il 95%.
- Validità dei risultati. Diversi fattori possono alterare i risultati del test, inclusi falsi positivi, campionamento distorto, o fattori esterni (ad esempio stagionalità o promozioni di marketing).
- Osservabilità. Quando esegui più test A/B su sovrapposizioni il traffico, le procedure di monitoraggio e risoluzione dei problemi possono risultare difficili. Ad esempio, se testi la pagina del prodotto A rispetto alla pagina B o quella di pagamento pagina C e pagina di pagamento D, il tracciamento distribuito diventa importante Stabilire metriche come la suddivisione del traffico tra le versioni.
Pattern test shadow
Le tecniche basate su esperimenti sequenziali come i test canary possono potenzialmente esporre a una versione dell'applicazione inferiore durante le prime fasi del test. Puoi gestire questo rischio usando le tecniche offline come la simulazione. Tuttavia, le tecniche offline non convalidano i miglioramenti dell'applicazione perché non avviene alcuna interazione dell'utente con le nuove versioni.
Con il test shadow, esegui il deployment di una nuova versione ed eseguila insieme a quella attuale ma in modo tale che la nuova versione sia nascosta agli utenti, come il seguente diagramma.
Una richiesta in entrata viene sottoposta a mirroring e riprodotta in un ambiente di test. Questo processo può avvenire in tempo reale o in modo asincrono dopo che una copia il traffico di produzione acquisito viene riprodotto nuovamente sul servizio di cui è stato appena eseguito il deployment.
Devi assicurarti che i test shadow non causino effetti collaterali che possono modificare l'ambiente di produzione esistente o lo stato dell'utente.
Vantaggi principali
- Nessun impatto sulla produzione. Poiché il traffico è duplicato, eventuali bug presenti in che i servizi che elaborano i dati shadow non hanno alcun impatto sulla produzione.
- Test di nuove funzionalità di backend utilizzando il carico di produzione. Se utilizzato con strumenti come Difficile, lo shadowing del traffico consente di misurare il comportamento del servizio di produzione in tempo reale. Questa capacità consente di testare errori, eccezioni le prestazioni e la parità di risultati tra le versioni dell'applicazione.
- Rischio di deployment ridotto. Lo shadowing del traffico in genere è combinato con altri approcci come il test canary. Dopo aver testato una nuova funzionalità mediante lo shadowing del traffico, testerai l'esperienza utente gradualmente rilasciando la funzionalità a un numero crescente di utenti nel tempo. Nessuno pieno l'implementazione avviene finché l'applicazione non soddisfa i requisiti di stabilità i tuoi requisiti.
Considerazioni
- Effetti collaterali. Con lo shadowing del traffico, devi prestare attenzione alle come gestisci i servizi che cambiano stato o interagiscono con terze parti i servizi di machine learning. Ad esempio, se vuoi eseguire lo shadow test del servizio di pagamento per un piattaforma di carrello degli acquisti, i clienti potevano pagare l'ordine due volte. A evitare i test shadow che potrebbero causare mutazioni indesiderate o altri a rischio di interazioni, consigliamo di usare stub o di virtualizzazione come Passare in alto anziché su sistemi o datastore di terze parti.
- Costi e overhead operativo. Il test shadow è piuttosto complesso configurazione. Inoltre, come i deployment blu/verde, i deployment shadow comportano un costo e operative, perché la configurazione richiede l'esecuzione gestire due ambienti in parallelo.
Scelta della strategia giusta
Puoi sottoporre a deployment e rilasciare la tua applicazione in diversi modi. Ogni approccio ha vantaggi e svantaggi. La scelta migliore dipende dalle esigenze i vincoli della tua attività. Considera quanto segue:
- Quali sono le tue considerazioni più critiche? Ad esempio, sono i tempi di inattività accettabile? I costi sono vincolanti? Il tuo team ha le competenze giuste per eseguire complesse configurazioni di implementazione e rollback?
- Disponi di controlli rigorosi o vuoi testare nuove release rispetto al traffico di produzione per garantire la stabilità rilasciare e limitare qualsiasi impatto negativo?
- Vuoi testare le funzionalità tra un pool di utenti per eseguire verifiche incrociate di determinate di ipotesi di business? Puoi controllare se gli utenti target accettano i aggiornare? Ad esempio, gli aggiornamenti sui dispositivi mobili richiedono un'azione esplicita dell'utente e potrebbero richiedere autorizzazioni aggiuntive.
- I microservizi nel tuo ambiente sono completamente autonomi? Oppure, hai un un ibrido di applicazioni in stile microservizi che funzionano insieme a applicazioni difficili da modificare? Per ulteriori informazioni, vedi pattern di deployment in ambienti ibridi e multi-cloud.
- La nuova release comporta modifiche allo schema? Se sì, lo schema modifiche troppo complesse per essere svincolate dalle modifiche al codice?
La tabella seguente riassume le caratteristiche salienti del deployment e i pattern di test descritti in precedenza in questo documento. Quando pesi vantaggi e svantaggi dei vari approcci di deployment e test, tieni conto delle tue esigenze aziendali e delle risorse tecnologiche, quindi seleziona l'opzione più vantaggiosa.
| Deployment o pattern di test |
Nessun tempo di inattività | Test sul traffico di produzione reale | Rilascio agli utenti in base alle condizioni | Durata del rollback | Impatto sui costi di hardware e cloud |
|---|---|---|---|---|---|
| Ricrea La versione 1 viene terminata e la versione 2 viene implementata. |
x | x | x | Veloce ma di disturbo a causa dei tempi di inattività | Non è richiesta alcuna configurazione aggiuntiva |
| Aggiornamento in sequenza La versione 2 viene implementata gradualmente per sostituire la versione 1. |
✓ | x | x | Lento | Può richiedere una configurazione aggiuntiva per gli upgrade di sovraccarico |
| Blu/verde La versione 2 viene rilasciata insieme alla versione 1; il traffico passa a Versione 2 dopo il test. |
✓ | x | x | Istantaneo | È necessario mantenere contemporaneamente gli ambienti blu e verde |
| Canary La versione 2 viene rilasciata a un sottoinsieme di utenti, seguita dall'implementazione completa. |
✓ | ✓ | x | Rapida | Non è richiesta alcuna configurazione aggiuntiva |
| A/B La versione 2 viene rilasciata, in condizioni specifiche, a un sottoinsieme di utenti. |
✓ | ✓ | ✓ | Rapido | Non è richiesta alcuna configurazione aggiuntiva |
| Ombra La versione 2 riceve traffico reale senza influire sulle richieste degli utenti. |
✓ | ✓ | x | Non applicabile | Necessità di mantenere ambienti paralleli per l'acquisizione e la riproduzione richieste degli utenti |
Best practice
Per ridurre al minimo i rischi di deployment e test, i team delle applicazioni può seguire diverse best practice:
- Compatibilità con le versioni precedenti. Quando esegui più versioni dell'applicazione assicurati che il database sia compatibile con tutte le applicazioni e versioni successive. Ad esempio, una nuova release richiede uno schema una modifica al database (ad esempio, una nuova colonna). In questo scenario, è necessario modificare lo schema del database in modo che sia compatibile con le versioni precedenti con la versione precedente. Dopo aver completato un'implementazione completa, puoi rimuovere il supporto per lo schema precedente, lasciando il supporto solo per la versione più recente. Un modo per ottenere la compatibilità con le versioni precedenti è disaccoppiare le modifiche allo schema dalle modifiche al codice. Per ulteriori informazioni, vedi modifica parallela e refactoring del database pattern.
- Integrazione continua/deployment continuo (CI/CD). CI garantisce il codice archiviato nel ramo di funzionalità si unisce solo al ramo principale dopo aver superato i controlli di dipendenze, i test delle unità e di integrazione, e il processo di compilazione. Ogni modifica a un'applicazione viene quindi testata prima di poter eseguire il deployment. Con CD, l'artefatto di codice creato da CI viene pacchettizzato e pronto per il deployment in uno o più ambienti. Per ulteriori informazioni, vedi creazione di una pipeline CI/CD con Google Cloud.
- Automazione. Se fornisci continuamente aggiornamenti delle applicazioni agli utenti, ti consigliamo di creare un processo automatizzato che crea, testa ed esegue il deployment del software. Ti consigliamo inoltre di inserire il codice le modifiche passano automaticamente attraverso una pipeline CI/CD che include l'artefatto creazione, test delle unità, test funzionale e implementazione in produzione. Utilizzando strumenti di automazione come Cloud Build Cloud Deploy Spinnaker e Jenkins, puoi automatizzare i processi di deployment per essere più efficienti, affidabili e prevedibili.
- IaC e GitOps. Se hai bisogno di gestire deployment e test complicati strategie, valuta di utilizzare Infrastructure as Code (IaC) e GitOps i nostri strumenti. Utilizzo di IaC con Terraform e Connettore di configurazione può aiutarti a utilizzare il linguaggio dichiarativo per definire infrastruttura e strategie. Utilizzo di GitOps con Config Sync e CD Argo. può aiutarti a gestire il tuo codice con Git.
- Strategia di rollback. A volte può capitare che le cose vadano storte. Consigliamo di creare una strategia di rollback da seguire in caso di imprevisti. Una strategia di rollback affidabile può aiutare amministratori e DevOps Engineer gestiscono il rischio. Puoi creare una strategia di rollback usando una piattaforma che supporta i rollback come funzionalità integrate, come App Engine, e Cloud Run. Per supportare le tue esigenze di rollback, puoi anche usare strumenti di automazione del rilascio come Cloud Deploy Spinnaker e Argo RollOut.
- Monitoraggio post-deployment. Per monitorare le metriche critiche e creare avvisi al team responsabile quando un deployment o un test non va a buon fine, creare una configurazione di monitoraggio di sistema utilizzando Observability di Google Cloud. Puoi anche abilitare rollback automatici per i deployment che non superino i controlli di integrità. Utilizzo Error Reporting: Cloud Trace e Cloud Profiler può aiutarti a trovare la causa di problemi post-deployment semplici e complessi.
Passaggi successivi
- Leggi i concetti di questo documento in Kubernetes e le sfide della distribuzione continua del software.
- Scopri di più sugli altri Soluzioni DevOps su Google Cloud.
- Scopri di più su integrazione e distribuzione continue su GKE.
- Scopri di più su Lezioni di vita del team CRE per release e rollback affidabili.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Centro architetture cloud.