‫Aggiornamenti di servizio Probabilmente hai sempre pensato che ci sia un modo per aggiornare i tuoi servizi
‫anche se non ci siamo ancora concentrati su questo.
‫Parliamone perché gli aggiornamenti hanno un sacco di cose in corso sotto le coperte. La funzionalità di aggiornamento di Swarm è incentrata su
‫un modello di aggiornamento continuo per le tue repliche. Il che significa che se si dispone di un
‫servizio con più di una replica e, si spera, lo si arrotolerà per impostazione predefinita,
‫uno alla volta, aggiornando ciascun contenitore sostituendolo con le nuove impostazioni che si stanno
‫inserendo nell'aggiornamento comando.
‫che gli orchestratori prevengono i tempi di inattività degli aggiornamenti, ma non dirò che questo previene i tempi di fermo.
‫Un sacco di gente dirà
‫Devo dire che limita i tempi di fermo. Perché prevenire i tempi di fermo in qualsiasi sistema è il lavoro di test.
‫Hai davvero bisogno di iniziare a testare come esegui i tuoi aggiornamenti e determinare, ha impatto sui miei utenti?
‫L'aggiornamento di un database ha impatto sulla mia applicazione web? Probabilmente lo fa.
‫Ogni applicazione per cui hai un servizio si aggiornerà e influenzerà in modo diverso le altre cose
‫intorno ad essa.
‫Questo non è il lavoro di un orchestratore.
‫
‫Un orchestratore non può determinare che questo sia un protocollo di database e questo è un protocollo di
‫applicazione REST facile.
‫Quindi quelle saranno cose diverse e complicate che dovrai affrontare.
‫Nel caso degli aggiornamenti di servizio, se si tratta solo di un'API REST o di un frontend Web che non sta
‫facendo niente di particolare come socket Web o polling lungo, se si tratta di qualcosa di molto semplice o di un
‫sito web statico, probabilmente avrai un aggiornamento facile e non sarà un problema queste saranno sempre una sfida,
‫Ma altri servizi come database o archiviazione persistente o tutto ciò che richiede una connessione persistente. non importa cosa tu stia cercando di aggiornare. Quindi prova presto e prova spesso.
‫Come ho detto prima, questo sostituirà definitivamente i contenitori nella maggior parte degli aggiornamenti. si verificheranno e cambieranno ogni contenitore con uno completamente nuovo.
‫A meno che tu non stia aggiornando un'etichetta
‫o alcuni altri metadati con il servizio,
‫Preparati per quello. Ha molte opzioni. In effetti, l'ultimo che ho contato, c'erano
‫almeno 77 opzioni per il comando di aggiornamento. Ma tutto ciò che vuoi fare può
‫essere ottimizzato.
‫Molte delle opzioni nel comando di aggiornamento sono in realtà le opzioni di creazione che hanno
‫solo un -rm e un -add alla fine di loro. Perché se si tratta di un'opzione che
‫può essere utilizzata per più valori, diciamo una porta per pubblicare o una variabile di ambiente, quelli che è possibile utilizzare molti di essi.
‫Destra?
‫Quindi, devi essere in grado di dire al comando di aggiornamento quali stai aggiungendo e quali rimuovi.
‫Vedremo quelli tra un minuto.
‫Questo include anche opzioni di rollback e controllo sanitario.
‫Dovresti esaminare le opzioni per quelle e vedere se i loro valori predefiniti
‫non sono ideali per la tua applicazione e testare impostazioni diverse per vedere se rende un aggiornamento più facile per te e il tuo sistema.
‫Vedrai anche che qui abbiamo le opzioni di ridimensionamento e rollback che ora sono i loro stessi comandi.
‫rendendo una specie di cittadini di prima classe nella riga di comando.
‫Erano le opzioni che dovevi specificare con il --rollback o --scale, ma
‫così tante persone hanno usato quelle così frequentemente che Docker ora le sta
‫Potrebbero aggiungerne altri in futuro.
‫Infine, prima di arrivare ad alcuni
‫esempi, se si stanno facendo stack, uno stack distribuire nello stesso stack è un aggiornamento.
‫In realtà, non esiste un'opzione separata per gli aggiornamenti dello stack.
‫Basta fare una distribuzione di stack con lo stesso file che è stato modificato.
‫Quindi, funzionerà con i comandi di servizio e le reti, e ogni altra cosa che fa. eventuali modifiche siano necessarie, che vengano applicate.
‫Funzionerà con loro per assicurarsi che
‫Diamo un'occhiata ad alcuni esempi rapidi e poi arriveremo alla riga di comando.
‫Questo è probabilmente l'esempio più comune che userete, che è
‫quello di cambiare l'immagine di un servizio.
‫Ogni volta che aggiorni la tua app e crei una nuova immagine, dovrai eseguire un comando di aggiornamento del servizio, con il nome dell'immagine e quindi il
‫nome del servizio.
‫Quindi in questo caso, forse avevo la mia applicazione con un tag di 1. 2. 0.
‫E in questo caso sto applicando un 1. 2. da quella che ho in esecuzione nel mio servizio, e andremo ad aggiornarli.
‫1 immagine, e il servizio
‫determinerà, ah sì, è un'immagine diversa In questo prossimo, mostreremo come è
‫possibile eseguire più cose contemporaneamente in un unico comando di aggiornamento.
‫È possibile aggiungere una variabile di ambiente con env-add, quindi rimuovere
‫una porta con il comando -rm.
‫Potremmo anche aggiungere e rimuovere le variabili di ambiente e pubblicare le porte nello stesso comando di aggiornamento
‫tanto quanto vogliamo. Su quest'ultimo, questo
‫mostra come possiamo utilizzare questi nuovi comandi di ridimensionamento e di rollback su più servizi contemporaneamente. rispetto al comando update è che possono essere applicati a più servizi.
‫Uno dei vantaggi del loro utilizzo
‫In questo caso, cambierò effettivamente il numero
‫di repliche del web e dei servizi API allo stesso tempo.
‫Come ho detto qualche tempo fa, negli aggiornamenti Swarm, non hai un comando di distribuzione diverso.
‫È lo stesso stack di
‫dock per la distribuzione, con il file che hai modificato, ed è compito lavorare con tutte
‫le altre parti dell'API per determinare se sono necessarie delle modifiche e poi rilasciarle con un aggiornamento del servizio.
‫Tutto ok. Iniziamo creando un servizio in modo da poterlo manipolare con alcuni comandi di aggiornamento.
‫servizio docker crea -p 8088 80 nome web, e useremo Nginx, e stiamo andando
‫a specificare una versione come dovremmo sempre nella produzione.
‫È bello, ora che abbiamo effettivamente nell'ultima metà del 2017, l'opzione di scollegamento con il nostro servizio di creazione e aggiornamento dei comandi, possiamo
‫effettivamente vederlo accadere in modo sincrono in tempo reale.
‫Quindi questo è utile per i comandi di aggiornamento per vedere come gli aggiornamenti vengono effettivamente implementati tramite la riga di comando.
‫Tutto ok. Ora, se facciamo un servizio di docker ls, vediamo che il
‫nostro servizio è in esecuzione e che ha 1 su 1 repliche, quindi è bello andare.
‫Ora aumentiamo il nostro servizio in modo che possiamo avere più repliche con cui lavorare. Web = 5.
‫scala di servizio docker E hai appena visto che uno di quelli era
‫già in esecuzione, e gli altri 4 dovevano iniziare. Passò piuttosto rapidamente sul mio perché avevo già scaricato l'immagine, ma
‫i tuoi potrebbero impiegare alcuni minuti mentre sono in
‫attesa di essere caricati sugli altri nodi.
‫Tutto ok.
‫Facciamo un aggiornamento continuo cambiando l'immagine di quel Nginx.
‫Vedrai qui che ho scelto un'immagine più vecchia.
‫Ora, Docker non si preoccupa di cosa sia realmente l'immagine.
‫Potrebbe essere un'applicazione completamente
‫diversa per tutto ciò che importa. Sa solo che in questo servizio, lo sto cambiando in un'immagine diversa.
‫Ricorda, per impostazione predefinita, passerà qui uno alla volta.
‫Prima lo rimuoverà, ne creerà uno nuovo, e
‫poi quando quello è buono da fare, e sembrerà sano, inizierà nel prossimo. Nel prossimo esempio,
‫cambieremo la porta pubblicata.
‫Ma non puoi cambiare porto.
‫Devi effettivamente aggiungerli e rimuoverli allo stesso tempo.
‫Quindi, in questo caso, poiché per la prima
‫volta l'abbiamo pubblicato con un 8088, è necessario eseguire un aggiornamento del servizio docker pubblicando rm 8088. Non ho bisogno di specificare il valore. Ho solo bisogno di specificare la chiave. Quindi pubblicheremo
‫il nuovo 9090. Quindi il valore, che in questo caso è 80. Vedrai che farà lo stesso processo di aggiornamento
‫di prima.
‫L'ultimo esempio di cui voglio parlare è una specie di suggerimento. Perché spesso avrai una
‫sfida con qualcosa chiamato ribilanciamento. O se cambi il numero di nodi o se muovi un sacco di cose in giro, se
‫hai molti contenitori nel tuo sciame, potresti scoprire che non sono realmente equilibrati. chiari su quanti contenitori sono in esecuzione
‫e altri che hanno molto.
‫Forse alcuni nodi sono abbastanza Se cambiano molte cose, Swarm non si
‫muoverà per mantenere tutto in equilibrio in termini di numero di risorse utilizzate.
‫Ma quello che puoi fare è che puoi forzare l'aggiornamento di un servizio anche senza modificare nulla in quel servizio.
‫Quindi, eseguirà nuovamente le attività e, in tal caso, sceglierà i nodi meno utilizzati, che è una forma di riequilibrio.
‫Un sacco di volte in uno sciame più piccolo quando sposto qualcosa di grosso, o aggiungo un mucchio di nodi,
‫improvvisamente ho un sacco di server vuoti che non fanno nulla e ho bisogno di lavorare su di loro.
‫Quindi, quello che farò è prendere uno o due dei miei servizi, e farò un aggiornamento del servizio docker - forza,
‫e in questo caso si verificherà e sostituirà completamente le attività.
‫Ovviamente utilizzerà l'impostazione predefinita di ricerca dei nodi con il minor
‫numero di contenitori e il minor numero di risorse utilizzate.
‫È una specie di trucco per aggirare una quantità irregolare di lavoro sui tuoi nodi.
‫Ricordati di pulire rimuovendo il servizio che abbiamo creato in questa lezione.
‫