‫Una delle grandi promesse di contenitori è che possiamo facilmente distribuire le nostre app come se fossimo un servizio di piattaforma, sai,
‫come Heroku o qualcosa del genere. Possiamo farlo sull'hardware di chiunque, sia sul nostro hardware, sia
‫su un fornitore di servizi cloud, che sia virtuale o fisico. Con Docker, le nostre app possono funzionare allo stesso modo,
‫sia che si tratti di Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud o altro. Senza tutte queste funzionalità della piattaforma, come
‫possiamo implementare e mantenere facilmente le nostre dozzine, centinaia o persino migliaia di
‫container su molti server o istanze? O nodi o gocce o altro.
‫Ciò porta a sopportare alcuni problemi davvero nuovi che non erano in precedenza problemi per le piccole organizzazioni.
‫che scalano migliaia e migliaia di nodi e decine di migliaia di nodi e hanno molti ingegneri.
‫Sappiamo tutti di Netflix e di grandi organizzazioni come quella
‫Ma se hai solo un paio di persone nel tuo team, o se sei solo uno sviluppatore solista, come
‫prendi i contenitori, li ridimensiona e gestisci l'intero ciclo di vita? Dal dispiegarli, a farli partire, a riavviarli,
‫a ricrearli, a eliminarli e ad aggiornarli e tutto il resto.
‫Iniziamo a fare domande su come fa esattamente Docker o addirittura lo fa?
‫Alcune delle domande che ci poniamo sono cose come, come scalare? Come aumentiamo? Come possiamo garantire che
‫i nostri contenitori si riavviano se falliscono?
‫Come sostituiremo quei contenitori quando effettivamente abbiamo un aggiornamento per loro? vengono rimossi dal pool per portarne di nuovi.
‫Qual è il cosiddetto verde blu che viene distribuito oggigiorno, il che significa che non ci sono
‫tempi di inattività e che i server Finisci sempre con qualcosa di disponibile in
‫modo da non essere mai deluso quando aggiorni. Come facciamo a sapere se abbiamo dozzine di nodi o anche solo
‫tre nodi in cui abbiamo avviato questi contenitori? Su quale nodo si trova il nostro contenitore? Come possiamo parlare attraverso quei
‫diversi nodi o server con il nostro networking all'interno dei container?
‫Quando si parla di sicurezza, come possiamo essere sicuri che i nostri contenitori stiano funzionando solo sulle
‫macchine che abbiamo intenzione di farli funzionare?
‫informazioni private di cui abbiamo bisogno per i nostri contenitori, come i segreti o le password?
‫Ora che stiamo spostando le cose e implementandole dinamicamente al volo, come immagazziniamo le
‫Quindi questo ci porta ad una importante evoluzione nell'ambito di ciò che Docker cerca di risolvere.
‫Quando le persone parlano con me e pensano che Docker sia solo un runtime contenitore, è
‫in questo momento che menziono solo Swarm Mode, una funzionalità completamente nuova nel 2016 che riunisce anni di comprensione delle
‫esigenze dei contenitori e di come eseguirli realmente dal vivo in produzione.
‫in realtà una soluzione di clustering di server che riunisce diversi sistemi operativi o host, o nodi,
‫o qualsiasi altra cosa
‫si voglia chiamare, in un'unica unità gestibile che è in grado di orchestrare il ciclo di vita dei contenitori.
‫Quindi, al suo interno, Swarm è Per essere chiari, in realtà non stiamo parlando di Swarm,
‫che chiamerò Swarm Classic, che era un componente aggiuntivo di Docker prima dell'1. 12 è uscito. Era davvero un contenitore che doveva essere eseguito all'interno
‫di Docker, che in realtà richiedeva
‫solo l'esecuzione dei comandi da parte di Docker e li ripeteva su più server.
‫Ha risolto alcuni problemi, ma non era proprio alla scala che avevamo veramente bisogno di risolvere l'80% dei casi
‫per come farai funzionare i tuoi contenitori.
‫realtà Docker ha annunciato Swarm
‫Kit, che consisteva in una serie di librerie o un kit di strumenti relativi a un intero gruppo di nuove funzionalità di Swarm.
‫Nell'estate 2016, alla dockercon 2016, in
‫Poi lo hanno bloccato nel server Docker. In tutto questo corso, hai effettivamente le
‫funzionalità disponibili nella CLI e sul tuo server.
‫Ora finalmente ci tuffiamo in loro.
‫A gennaio 2017, 1. 13 sono usciti e, naturalmente, poiché lo Swarm
‫Mode era nuovo nel 2016, continueranno a renderlo migliore negli anni a venire.
‫A gennaio, hanno aggiunto funzionalità aggiuntive chiamate Stacks and Secrets, nonché altri
‫bonus di cui parleremo in seguito. È importante notare che Swarm non è effettivamente abilitato fuori dalla scatola.
‫In effetti, sul tuo computer, non puoi usare questi comandi elencati qui adesso. Questo in realtà ti darebbe un
‫errore perché Swarm deve essere abilitato.
‫Quello era uno degli obiettivi di progettazione era che nessuno del codice Swarm avrebbe influenzato
‫il demone Docker esistente, e che tutti gli strumenti e i sistemi là fuori che stavano già
‫facendo affidamento su Docker, o forse avevano la propria orchestrazione su Docker, avrebbero Swarm è ora parte
‫integrante
‫di Docker e continua a funzionare senza essere disturbato. che queste scatole blu che vedete in alto sono quelle che
‫chiamiamo Nodi Manager e in realtà hanno un database localmente su di esse noto come Raft Database.
‫Alcuni concetti veramente basilari prima di iniziare ad immergerci, è
‫Memorizza la loro configurazione e dà loro tutte le informazioni di cui hanno bisogno per essere l'autorità
‫all'interno di uno sciame.
‫Quindi quello che abbiamo qui sono tre diversi manager che sono stati tutti aggiunti allo sciame,
‫e tutti mantengono una copia di quel database e crittografano il loro traffico al fine di garantire l'integrità e garantire la fiducia
‫che sono in grado di gestire questo sciame in modo sicuro .
‫Sotto nel verde, abbiamo effettivamente note di lavoro. Ora puoi vedere nel concetto di
‫Swarm, ora abbiamo manager e lavoratori.
‫Ognuna di queste sarebbe una macchina virtuale, o un host fisico, che esegue una distribuzione di
‫Linux o server Windows.
‫Questo sta mostrando come stanno effettivamente comunicando su ciò che chiamiamo il Piano di Controllo, che è il modo
‫in cui gli ordini vengono inviati intorno allo sciame, le azioni di partecipazione. In una visione un po 'più complicata, abbiamo questo database
‫di consenso Raft che ho menzionato, che viene replicato di nuovo tra tutti i nodi.
‫Rilasciano gli ordini ai lavoratori.
‫Gli stessi manager possono anche essere lavoratori. Naturalmente, puoi abbassare la soglia e promuovere
‫lavoratori e manager nei due diversi ruoli.
‫Quando pensi a un manager, di solito pensi a un lavoratore con le autorizzazioni per controllare lo sciame.
‫Anche in questo caso, gli unici requisiti per ciascuno di questi server è che
‫stanno eseguendo la stessa Docker che stai già utilizzando ora. Con questo concetto di sciame e questi gestori, ora abbiamo nuovi concetti
‫su come sono i nostri contenitori.
‫Quindi, con il comando di esecuzione di Docker, potevamo davvero solo distribuire un container.
‫Creerebbe solo un contenitore.
‫Era sempre su qualsiasi macchina con la CLI Docker stesse parlando.
‫Di solito è la tua macchina locale, o forse un server a cui sono collegati. su come ridimensionare o scalare.
‫Il comando di esecuzione di Docker non aveva concetti
‫Quindi avevamo bisogno di nuovi comandi per affrontarlo.
‫Ecco da dove viene il comando di servizio Docker. In uno sciame, sostituisce il comando
‫di esecuzione di Docker e ci consente di aggiungere funzionalità extra al nostro contenitore quando lo eseguiamo,
‫come le repliche per dirci quanti di quelli che vuole eseguire.
‫Quelli sono conosciuti come compiti.
‫Un singolo servizio può avere più attività e ciascuna di queste attività avvierà un contenitore.
‫il servizio di docker creato per creare un servizio Nginx utilizzando l'immagine Nginx come abbiamo fatto diverse volte prima.
‫In questo esempio, abbiamo creato un servizio utilizzando
‫Ma abbiamo detto che vorremmo tre repliche.
‫Quindi userà i nodi manager per decidere dove posizionare gli sciami. Per impostazione predefinita, tenta di
‫distribuirli.
‫Ogni nodo otterrebbe la propria copia del contenitore Nginx fino alle tre repliche che gli avevamo
‫detto di aver bisogno.
‫Questa è una comprensione rapida e di base su come funzionano i manager e su cosa stanno facendo in background.
‫Tutte queste funzionalità sono nuove.
‫Non si tratta semplicemente di prendere il comando e di eseguirlo su un'API come faremmo con un
‫comando di esecuzione Docker.
‫C'è in realtà una API Swarm totalmente nuova che ha un sacco di servizi in background, come lo schedulatore e il
‫dispatcher, e l'allocatore e l'orchestratore, che aiutano a prendere decisioni intorno a ciò che i lavoratori
‫devono eseguire in un dato momento.
‫Così gli operai riportano costantemente ai manager e chiedono un nuovo lavoro.
‫I manager distribuiscono costantemente nuovi lavori e valutano ciò che gli hai detto di fare contro ciò che
‫stanno facendo in realtà.
‫Quindi, se si verifica una riconciliazione, questi apporteranno tali modifiche, ad esempio se glielo hai detto
‫di avviare altre tre attività di replica in quel servizio.
‫Quindi l'orchestratore se ne renderà conto e quindi impartirà gli ordini agli operai e così via.
‫Con questa modalità Swarm, abbiamo davvero un set di funzionalità ricco di funzionalità che ci consentono di utilizzare già le
‫competenze Docker esistenti che abbiamo per distribuire i nostri contenitori su Internet in modo affidabile
‫e risolvere un sacco di problemi che avremmo quando
‫andremo in produzione.