Qual è lo scopo delle distribuzioni blu / verdi in ambienti di grandi dimensioni?

3

Nella mia esperienza passata, il modo in cui abilitavamo le implementazioni in stile blu / verde era di fornire alcuni server per la nuova versione che erano copie dei server dell'ambiente di produzione dell'app, distribuire loro la nuova versione dell'app, testare e poi passare instradamento del traffico per puntare ai nuovi server. Quando ho suggerito questo nel mio nuovo team, hanno detto che la loro impressione era che il blu / verde dovrebbe essere attraverso l'intero ambiente IT - si ha una copia di tutte le app e server duplicati in ogni momento, e si passa avanti e indietro quando le modifiche vengono apportate .

Questo mi ha sorpreso un po 'perché è sembrato un sovraccarico eccessivo passare il routing avanti e indietro per centinaia di app su centinaia di server ogni volta che viene aggiornata una singola app. Sono tornato indietro e ho riletto l'articolo Martin Fowler e non mi è chiaro quale sia il solito scopo; parla ripetutamente di ambienti identici, ma l'immagine di esempio sembra essere un singolo stack di app (un server Web blu, un server delle applicazioni, un database e uno per il verde). Ho trovato descrizioni simili altrove nel web; tutti parlano di un ambiente duplicato, ma danno un esempio focalizzato su una singola app.

Quindi, come hai impostato le distribuzioni blu / verdi? Mi sto sfuggendo qualcosa concentrandomi sul singolo livello di app / servizio?

    
posta GJCode 16.08.2017 - 03:26
fonte

2 risposte

1

Non sono sicuro del motivo per cui si desidera disporre di una distribuzione blu / verde attivata per tutti i server (supponendo che ciascuna applicazione sia in esecuzione su un server separato) quando è stata aggiornata solo una singola applicazione. Ho difficoltà a vedere quali sono i vantaggi di un tale sistema e posso solo immaginare che ciò darebbe maggiori possibilità di errore durante il passaggio sui server in cui non sono state apportate modifiche.

Ci sono 3 motivi per utilizzare una distribuzione blu / verde come la vedo io:

  1. Puoi testare l'aggiornamento sul nuovo server prima che sia reso live.
  2. Non ci sono tempi morti quando passi a una nuova versione.
  3. Puoi ripristinare facilmente e rapidamente la versione precedente se qualcosa non funziona con la nuova versione.

Non ci sarebbe alcun vantaggio nel cambiare un'applicazione che non è stata aggiornata e rimuoverebbe il 3o vantaggio dal momento che entrambi i server blu e verde ora avranno l'ultima versione.

Penso che tu abbia risposto in qualche modo alla tua stessa domanda nell'ultima frase. Ogni singola app / servizio dovrebbe essere visualizzata da sola e disporre di una propria implementazione blu-verde.

    
risposta data 16.08.2017 - 08:32
fonte
0

L'articolo di Martin Fowler è stato scritto prima che Docker esistesse. Certo, la mia esperienza mi spinge verso i container, ma negli ultimi due anni credo sia diventato sempre più raro fare cose come le installazioni blu / verdi senza contenitori, specialmente in ambienti di grandi dimensioni. Recentemente non ho visto nessun tutorial sul fare blu / verde a livello di server, come descrivi, per non parlare del modo in cui i tuoi colleghi descrivono.

L'uso dei contenitori ti consente di usare uno schedulatore come Nomad o Kubernetes per far apparire la prossima versione della tua app sugli stessi server, mentre usi lo stesso server web e i contenitori db se non sono cambiati , eseguire controlli sanitari e / o altri test su di essi, quindi eseguire il rollback o la promozione.

    
risposta data 16.08.2017 - 13:41
fonte

Leggi altre domande sui tag