‫Una dintre marile promisiuni ale containerelor este că putem implementa cu ușurință aplicațiile noastre ca și cum am fi un serviciu de platformă,
‫știi, ca Heroku sau ceva asemănător. Putem face asta pe hardware-ul cuiva, indiferent dacă e pe
‫hardware-ul nostru, este un furnizor de cloud, fie virtual sau fizic. Cu Docker, aplicațiile noastre pot rula la fel
‫dacă sunt un Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud sau orice altceva. Fără toate aceste caracteristici ale platformei, cum putem
‫implementa și menține cu ușurință zeci sau sute sau chiar mii de containere pe
‫mai multe servere sau instanțe? Sau noduri sau picături sau orice altceva.
‫Acest lucru aduce unele probleme cu adevărat noi, care nu au fost anterior probleme pentru organizațiile mici.
‫Știm cu toții despre Netflix și despre organizații mari de genul ăla de mii și mii de noduri
‫și zeci de mii de noduri și au mulți ingineri.
‫Dar, dacă aveți doar câteva persoane în echipa dvs. sau dacă sunteți doar un dezvoltator solo, cum să vă luați recipientele și să
‫le scalați și să vă ocupați de întregul lor ciclu de viață? De la implementarea lor, la pornirea lor, la
‫repornirea lor, la recrearea lor, la ștergerea lor și la actualizarea acestora și la toate acestea.
‫Începem să punem întrebări în legătură cu modul în care Docker face exact acest lucru sau chiar face acest lucru deloc?
‫Unele dintre întrebările pe care le punem noi înșine sunt lucruri cum ar fi: cum putem să scarăm? Cum putem mări? Cum ne asigurăm
‫că containerele noastre se repornesc dacă nu reușesc?
‫Cum putem înlocui aceste containere când avem de fapt o actualizare pentru ei? Ceea ce se folosește în zilele noastre,
‫numit verde albastru, înseamnă că aveți zero timp de întrerupere și luați serverele din piscină
‫pentru a le aduce noi. Încheie cu ceva întotdeauna disponibil, astfel
‫încât să nu fii niciodată jos când te actualizezi. De unde știm dacă avem zeci de noduri sau chiar doar trei
‫noduri de unde am pornit acele containere? Pe ce nod este containerul nostru? Cum putem vorbi prin
‫acele noduri sau servere diferite cu rețeaua noastră în interiorul containerelor?
‫Când vine vorba de securitate, cum putem fi siguri că containerele noastre rulează doar pe mașinile pe
‫care le-am propus să le execute?
‫Acum, când ne mișcăm lucrurile în jurul nostru și le desfășurăm dinamic în mișcare, cum stocăm informațiile
‫private de care avem nevoie pentru containere, cum ar fi secrete sau parole?
‫Deci, acest lucru ne duce la o evoluție majoră în domeniul a ceea ce Docker încearcă să rezolve.
‫Cand oamenii vorbesc cu mine si cred ca Docker este doar un runtime pentru containere,
‫atunci m-am referit doar la modul Swarm, care este o caracteristica noua in 2016, care imbina anii de intelegere
‫a necesitatilor containerelor si de a le rula efectiv in productie.
‫Deci, în centrul său, Swarm este de fapt o soluție de grupare a serverului care reunește diferite sisteme
‫de operare sau
‫gazde sau noduri sau orice doriți să le numiți într-o singură unitate administrabilă pe care să o orchestrați apoi
‫în ciclul de viață al containerelor dvs. Doar pentru a fi clar, nu vorbim de Swarm, pe care
‫o voi numi Swarm Classic, care a fost o componentă suplimentară pentru Docker înainte de 1. 12 a ieșit. Era într-adevăr un container care ar fi rulat
‫în interiorul lui Docker, care
‫tocmai a luat comenzile Docker și le-a repetat pe mai multe servere.
‫A rezolvat câteva probleme, dar nu a fost într-adevăr la scară că avem nevoie pentru a rezolva cu adevărat 80% din cazuri pentru modul
‫în care aveți de gând să executați containerele.
‫În vara anului 2016,
‫la Dockercon 2016, de fapt, Docker a anunțat Swarm Kit, care a fost un set de biblioteci sau un set de instrumente legate de
‫o grămadă de noi caracteristici Swarm.
‫Apoi au blocat acel drept pe serverul Docker. De-a lungul acestui curs, de fapt ai
‫avut caracteristicile disponibile în CLI și pe serverul tău.
‫Acum ajungem să ne scufundăm în ele.
‫În ianuarie 2017, 1. 13 au ieșit și, bineînțeles, pentru că Modul Swarm
‫a fost nou în 2016, ei vor continua să o facă mai bine în anii următori.
‫În ianuarie, au adăugat caracteristici suplimentare numite Stacks and Secrets, precum și alte bonusuri pe
‫care le vom vorbi mai târziu. Este important să rețineți că Swarm nu este activat de fapt din cutie.
‫De fapt, pe mașina dvs., nu ați putut folosi aceste comenzi afișate aici chiar acum. Aceasta ar fi de fapt
‫o eroare deoarece Swarm trebuie activat.
‫Acesta a fost unul dintre scopurile de proiectare: niciunul din codurile Swarm nu ar
‫afecta daemonul Docker existent și că toate instrumentele și sistemele de acolo, care se bazau deja
‫pe Docker, sau poate că aveau o orchestrație proprie pe Docker, continuă să funcționeze și să nu
‫se
‫interfereze cu faptul că Swarm face parte din Docker. Unele concepte cu adevărat de bază înainte să începem să vă scufundăm este că aceste
‫cutii albastre pe care le vedeți în partea de sus sunt ceea ce numim Noduri Manager și de fapt au o bază de
‫date locală despre ele, cunoscută sub numele de Baza de Date Raft.
‫Stochează configurația și le oferă toate informațiile de care au nevoie pentru a fi autoritatea în
‫interiorul unui roi.
‫Deci, ceea ce avem aici sunt trei manageri diferiți care au fost adăugați la
‫roiuri și toți păstrează o copie a bazei de date și criptează traficul pentru a asigura integritatea și pentru a
‫garanta încrederea că pot gestiona acest roi în siguranță .
‫Mai jos, în verde, avem de fapt note de muncitori. Acum, puteți vedea în conceptul de Swarm,
‫avem acum manageri și lucrători.
‫Fiecare dintre acestea ar fi o mașină virtuală sau o gazdă fizică care rulează o distribuție a
‫serverului Linux sau Windows.
‫Acest lucru arată cum comunică de fapt ceea ce noi numim Planul de control, care este
‫modul în care comenzile sunt trimise în jurul roiului, parcurgând acțiunile. Într-o viziune puțin mai complicată, avem această bază de
‫date consens, pe care am menționat-o, care este reprodusă din nou printre toate nodurile.
‫Ei dau ordine muncitorilor.
‫Managerii înșiși pot fi, de asemenea, lucrători. Desigur, puteți degrada și promova lucrătorii și
‫managerii în cele două roluri diferite.
‫Când vă gândiți la un manager, gândiți-vă de obicei la un lucrător cu permisiuni de a controla roiul.
‫Din nou, singurele cerințe pentru fiecare dintre aceste servere sunt că rulează
‫același Docker pe care îl utilizați deja acum. Cu acest concept de roi, și acești manageri, avem acum noi concepte
‫despre cum arată containerele noastre.
‫Deci, cu comanda Docker, am putea să instalezi un container.
‫Ar crea doar un container.
‫Era întotdeauna pe orice mașină cu care vorbise Docker CLI.
‫Aceasta este de obicei mașina dvs. locală, sau poate un server în care sunt conectați. Comanda de la Docker nu
‫avea concepții despre cum să scadă sau să crească.
‫Avem nevoie de noi comenzi pentru a face față acestei situații.
‫De aici vine comanda de serviciu Docker. Într-un roi, înlocuiește comanda de rulare
‫Docker și ne permite să adăugăm noi caracteristici containerului nostru atunci când îl executăm, cum ar fi replici pentru
‫a ne spune câte dintre cei pe care vrea să le execute.
‫Acestea sunt cunoscute ca sarcini.
‫Un singur serviciu poate avea mai multe sarcini și fiecare dintre aceste sarcini va lansa un container.
‫În acest exemplu, am creat un serviciu care utilizează serviciul docker pentru a transforma un serviciu Nginx utilizând imaginea Nginx, așa
‫cum am făcut-o de mai multe ori înainte.
‫Dar am spus că ne-ar plăcea trei replici.
‫Deci, va folosi nodurile managerului pentru a decide unde în roiuri să le plaseze pe acestea. În mod implicit, încearcă să le
‫extindă.
‫Fiecare nod ar primi propria sa copie a containerului Nginx până la cele trei replici pe care i le-am
‫spus că avem nevoie.
‫Aceasta este o înțelegere rapidă și de bază a modului în care managerii lucrează și ce fac în fundal.
‫Toate aceste caracteristici sunt noi.
‫Nu pur și simplu luați comanda dvs. și rulați-o pe un API ca și cum am fi experimentat cu o
‫comanda de rulare Docker.
‫Există de fapt un nou API Swarm, care are o grămadă de servicii de fundal, cum ar fi planificatorul, dispecerul, distribuitorul
‫și orchestratorul, care ajută la luarea deciziilor în legătură cu ceea ce muncitorii ar trebui să
‫execute la un moment dat.
‫Lucrătorii raportează în mod constant managerilor și solicită o nouă activitate.
‫Managerii fac în mod constant o muncă nouă și evaluează ceea ce le-ați spus să facă față de ceea
‫ce fac de fapt.
‫Atunci, dacă se va întâmpla o reconciliere, aceștia vor face acele schimbări, cum ar fi poate că
‫i-ați spus să facă alte trei sarcini replicate în acel serviciu.
‫Astfel, orchestratorul va realiza acest lucru și apoi va emite ordine până la lucrători și așa mai departe.
‫Cu acest modul Swarm, avem de fapt un set de capabilități din pachet care ne permite să folosim deja abilitățile existente ale Docker-ului pe care
‫le avem în scopul de a implementa containerele noastre pe Internet într-un mod sigur și de a rezolva
‫o mulțime de problemele pe care le-am avea odată ce mergem
‫la producție.