‫Tutto ok.
‫Ovunque tu stia utilizzando il Docker, possiamo effettivamente creare uno sciame di singoli nodi per i nostri scopi
‫di test.
‫Il modo in cui posso dire se Swarm è attivo o meno, posso semplicemente fare un'informazione sulla finestra mobile e noterai che Swarm
‫è inattivo.
‫Quindi sappiamo che Swarm non è stato abilitato qui. Di nuovo, per impostazione predefinita, Docker non abilita
‫nessuna delle funzioni di Swarm.
‫Posso eseguire un init swarm docker per l'inizializzazione. Ci sono voluti circa mezzo secondo e abbiamo finito.
‫Quello che abbiamo ora è uno sciame di singoli nodi con tutte le caratteristiche e le funzionalità
‫che otteniamo.
‫Quindi quella era probabilmente la demo più breve di questo intero corso.
‫Voglio dire, cos'è successo? Abbiamo digitato un comando e una magia. In realtà non era una magia.
‫Sono state molte cose molto veloci ed efficienti nella programmazione Go di Docker, ma in sostanza, appena fuori dalla
‫scatola, fa
‫un sacco di PKI e roba di sicurezza. Crea un certificato di origine per lo sciame che utilizzerà per stabilire
‫la fiducia e firmare i certificati per tutti i nodi e tutti i gestori. è un gestore rispetto a un lavoratore.
‫Creerà un certificato speciale per questo primo nodo gestore perché
‫Quindi crea questi token che possiamo effettivamente usare su altri nodi per unire questo sciame.
‫Poi un po 'di altre cose in background dove abilita l'API swarm e crea qualcosa chiamato Raft
‫Consensus Database, di cui parleremo più avanti in una parte di produzione del corso.
‫Solo per quel che ne sai, Raft è un protocollo che garantisce effettivamente la coerenza tra più nodi, ed è ideale
‫per l'utilizzo nel Cloud dove non possiamo garantire che una sola cosa sarà disponibile per un qualsiasi
‫momento nel tempo.
‫Crea quel database su disco. gestore e in realtà lo crittografa.
‫Memorizza la configurazione dello sciame e quel primo
‫Supponendo che tu sia nella versione 1. 13 o più recente. Quindi attenderà altri nodi prima che inizi
‫effettivamente a replicare il database su di essi.
‫Di nuovo, tutto questo traffico che farebbe una volta che creeremo altri nodi sarà tutto criptato.
‫Uno dei componenti chiave di Swarm che lo differenziava quando è uscito per la prima volta
‫era che non avevamo bisogno di un ulteriore sistema di memorizzazione dei valori delle chiavi o di qualche architettura di database per la
‫gestione della configurazione di backend del nostro sciame.
‫devi rendere ridondante che memorizzerà tutte le informazioni sul tuo sistema di orchestrazione e automazione.
‫Se sei stato nel settore per anni o decenni, c'è questo concetto tipicamente del db config, che è
‫questo sistema di database separato che di solito Swarm lo ha costruito direttamente nel
‫Docker direttamente nel demone e lo gestisce per noi.
‫Non abbiamo mai veramente bisogno di fare nulla. Non ci sono password di cui preoccuparsi. Non ci sono servizi
‫speciali da avviare o simili. se voglio aggiungere un lavoratore allo
‫Quindi, torna alla riga di comando. sciame, ho davvero bisogno di tagliarlo
‫Noterai qui di cui parla. e incollarlo sugli altri server che vorrei aggiungere. In seguito, costruiremo uno sciame
‫multi-nodo, ma per ora lo terremo in un solo nodo. Diamo un'occhiata a un paio di comandi che ne usciranno.
‫La prima cosa è che possiamo fare il nodo docker ls. In questo caso, stiamo visualizzando il nodo del gestore
‫unico che abbiamo creato.
‫Noterai che è contrassegnato come leader e che può esserci un solo leader alla volta tra tutti i manager.
‫Di nuovo, dal momento che ne abbiamo solo uno, quindi ovviamente è il leader. Possiamo
‫guardare l'aiuto per vedere quali altre opzioni abbiamo qui. In realtà, i comandi dei nodi utilizzati per portare i server dentro e fuori dallo sciame, o promuoverli
‫dai lavoratori ai manager, o retrocedere dai manager ai lavoratori.
‫Se si ripristina un po 'il comando dello
‫sciame dei dockers, noteremo che in realtà è un ambito molto ristretto da comandare.
‫In realtà è solo per inizializzare, sia entrare o uscire.
‫Il nuovo comando di sblocco, di cui possiamo parlare in una conferenza successiva.
‫Per ora, concentriamoci sull'emozionante nuovo comando di servizio Docker.
‫Di nuovo, il servizio in uno sciame sostituisce la corsa Docker.
‫Non lo so per certo, ma penso davvero che fosse incentrato sull'idea
‫che non volevamo interrompere la funzionalità di Docker esistente, ma l'esecuzione di
‫Docker è sempre stata costruita da zero come una singola soluzione host.
‫L'idea era di concentrarsi sui contenitori locali sul sistema con cui sta parlando. a parlare di un cluster, non ci interessa molto dei singoli nodi.
‫Mentre, quando iniziamo
‫In realtà, probabilmente non li chiamiamo. Li trattiamo come bestiame, se hai mai
‫sentito parlare degli animali contro l'analogia del bestiame, dove sono solo un numero.
‫In realtà non andiamo individualmente su ciascun nodo e avviiamo un singolo contenitore.
‫In realtà, gettiamo semplicemente le richieste allo sciame
‫sotto forma di servizi e poi orchestreremo come deve esporre tutto
‫ciò, su quali nodi devono essere, e sappiamo solo che ci sta dando le spalle. creare il servizio docker è come dargli
‫alcuni nuovi ordini. Facciamo qualcosa di veramente semplice.
‫Iniziamo solo con l'immagine alpina. Poi avremo l'immagine alpina, basta
‫usare il ping per colpire 8. 8. 8. 8, che in realtà è un server DNS
‫di Google, ma vogliamo davvero dargli qualcosa da fare mentre indaghiamo su cosa succede.
‫Quindi vedrai come l'esecuzione della finestra mobile, restituisce un ID, solo che non è l'ID del contenitore. Questo è in
‫realtà l'ID di servizio.
‫Vedrai che ora abbiamo elencato un servizio. Proprio come con il nostro comando di esecuzione
‫docker, dal momento che non lo
‫abbiamo nominato, ha dato un nome casuale. Possiamo vedere che in realtà è già roteato.
‫Quello di uno. Quando guardi i
‫servizi, vedrai sempre questo numero con / al centro. Quello che rappresenta quello a sinistra è quanti ne stanno effettivamente correndo.
‫E quello a destra è quanti ne hai specificato per farlo funzionare.
‫L'obiettivo dell'orchestratore è far corrispondere questi numeri, qualunque cosa sia necessaria.
‫Ma questo di nuovo in realtà non ci mostra il vero contenitore.
‫Questo ci mostra semplicemente un elenco dei nostri servizi, così possiamo approfondire un po 'di più.
‫Facciamo un servizio docker ps, e poi gli diamo
‫il nome o l'ID del servizio e questo ci mostrerà effettivamente le attività oi contenitori per questo servizio. multi server, potremmo aver bisogno di sapere su quale server è effettivamente in esecuzione.
‫Vedrai che è simile al comando ls del docker container, ma attualmente ha questo componente del nodo
‫perché quando hai a che fare con scenari Noterai che in realtà gli ha
‫dato un nome di un incremento sul nome del servizio.
‫Se torniamo al comando ls del contenitore docker, funziona ancora.
‫In questo caso, l'orchestrazione di Swarm aggiunge effettivamente
‫alcune informazioni ai nomi e alle immagini reali in esecuzione. Copriremo anche alcune di quelle sottili differenze in seguito.
‫Per ora, prendiamo effettivamente questo servizio e lo scaliamo. Per questo, useremo l'aggiornamento del servizio docker, e quindi il nome del nostro servizio, o l'ID
‫in questo caso, farò l'ID. attributo sul servizio.
‫E voglio cambiare un
‫In questo caso, voglio cambiare il numero di repliche.
‫Quindi, se facciamo di nuovo un servizio docker, ora ne vediamo tre su tre. Se eseguiamo
‫un servizio docker ps, ora vediamo tre attività. Noterai che due sono stati creati pochi secondi fa.
‫Se fossimo abbastanza veloci, e se stessimo implementando qualcosa di abbastanza grande, potremmo effettivamente eseguire il
‫servizio ls e vederlo effettivamente mostrarci zero su tre. Uno dei tre.
‫In realtà aumenterà all'avvio delle cose. Accade solo che Alpine fosse già su questa macchina, in termini di immagine, e non ci è voluto
‫molto tempo per avviare un comando ping.
‫Non potremmo essere così veloci.
‫La cosa interessante di questo comando di aggiornamento è che puoi
‫immaginare la differenza tra il comando di esecuzione
‫di Docker che potresti usare su un singolo dev o server di test o sul
‫tuo computer locale, e i problemi di produzione di mantenere sempre qualcosa disponibile il più possibile.
‫Questo è uno degli obiettivi di design di Swarm. Quel comando che in realtà non abbiamo ancora usato è il
‫comando di aggiornamento Docker. Quello era un comando per il Docker che
‫lanciava container che ci permetteva di aggiornare determinate variabili sul nostro contenitore in esecuzione senza doverlo uccidere e riavviarlo.
‫Quasi tutte queste opzioni sono correlate alla limitazione e al controllo dell'utilizzo delle risorse per quel contenitore.
‫Perché è una delle cose tipiche che si vedono quando si esegue un'applicazione a
‫lungo termine è che è necessario modificare le sue risorse, forse perché i database sono diventati più grandi e hanno bisogno di più RAM.
‫O forse hai un processo fuori controllo che sta consumando troppa CPU e devi limitarlo.
‫Se facciamo un aiuto sul comando di aggiornamento del servizio docker, vedremo che abbiamo molte più opzioni.
‫Perché l'obiettivo di un servizio Swarm è che è
‫in grado di sostituire i contenitori e aggiornare le modifiche nel servizio senza interrompere il tutto.
‫uno alla volta per apportare una modifica e fare una sorta di aggiornamento continuo, che è il modello blu verde di cui abbiamo parlato.
‫Se disponevi di un servizio con tre contenitori, puoi tecnicamente abbattere Ecco perché vediamo molte più opzioni perché è
‫possibile modificare queste opzioni che potrebbero richiedere il riavvio di un contenitore, ma lo sciame si
‫accerterà in modo intelligente che il modo
‫in cui li aggiorniamo è in un modello che garantisce una disponibilità coerente.
‫Quindi torniamo alla lista dei container della nostra finestra mobile molto velocemente. Noterai che ora abbiamo questi tre, e se entrassi e, come un ladro, feci diciamo che ho battuto il primo
‫un container docker, e ho Tutto ok.
‫specificato uno di questi contenitori, e l'ho forzato. e lo faccio fuori. Ora faccio un servizio di docker ls, e vedi come mostra due su tre?
‫realtà ho portato via un container in corsa, lo identificherà e ne verrà lanciato uno nuovo in pochi secondi per sostituire quello che è andato giù.
‫Perché sono andato dietro il retro di Swarm
‫e in
‫Quindi, se ho fatto un servizio docker su frosty, vedrai che in realtà mostra la cronologia della prima
‫attività qui nella lista è che ne è fallito uno e ne ha avviato uno nuovo 24 secondi fa.
‫Questa è una delle responsabilità di un sistema di orchestrazione dei
‫contenitori
‫è quello di assicurarsi che i servizi che hai specificato siano sempre in esecuzione, e se falliscono, recupera da quell'errore. Qual è la differenza rispetto alla finestra mobile, giusto? l'esecuzione della finestra mobile non ricreava
‫mai un contenitore.
‫Ecco perché ogni volta che eseguiamo uno qualsiasi di questi comandi del servizio Docker, in realtà non
‫stiamo parlando direttamente a un'azione come creare un contenitore.
‫In realtà stiamo dicendo un sistema di orchestrazione, hey metti questo lavoro in coda.
‫Quando puoi raggiungerlo, per favore, esegui le azioni sullo sciame che ho chiesto qui. Questa
‫è una grande differenza.
‫È sottile nella riga di comando, ma è una grande differenza perché significa che esistono possibilità di rollback.
‫C'è una mitigazione del fallimento e molta intelligenza incorporata in questo.
‫volessi rimuovere tutti questi contenitori, dovrei rimuovere il servizio.
‫In questo caso, se Dovrei fare il servizio docker rm.
‫E poi il gelido.
‫Se facciamo un servizio di docker ls, non vediamo nulla. Se eseguiamo una finestra mobile container
‫ls, vediamo tre contenitori.
‫Oh e eccoci.
‫Questo mostra proprio lì l'automazione che sta accadendo nel back-end.
‫Siamo stati in grado di mostrare rapidamente che abbiamo eliminato il servizio, ma
‫il sistema di orchestrazione non aveva attraversato tutti i suoi processi di pulizia del servizio e l'attività dietro di esso. di Docker che abbiamo avuto in precedenza in questo corso.
‫Questi concetti dovrebbero essere abbastanza
‫facili da capire perché stanno semplicemente espandendo i concetti di esecuzione
‫In seguito costruiamo uno sciame multi-nodo e iniziamo a ridimensionare i nostri contenitori.
‫