‫In regula.
‫Ori de câte ori executați Docker-ul dvs., putem crea un roi de un singur nod pentru propriile scopuri
‫de testare.
‫Cum pot să spun dacă Swarm este sau nu, pot să fac doar o informație despre docker și veți observa că Swarm
‫este inactiv.
‫Deci știm că Swarm nu a fost activat aici. Din nou, în mod prestabilit, Docker nu permite nici
‫una din funcțiile Swarm.
‫Pot rula un inel de docare init pentru a inițializa. A trecut cam o jumătate de secundă și am terminat.
‫Ceea ce avem acum este un roi unic cu toate caracteristicile și funcționalitatea pe care le scoatem
‫din cutie.
‫Asta a fost probabil cel mai scurt demo al acestui curs.
‫Adică, ce sa întâmplat? Am scris o comandă și o magie. Nu era deloc magie.
‫Au fost o mulțime de lucruri foarte rapide și eficiente în programarea Go a Docker, dar în esență, chiar din
‫cutie,
‫face o mulțime de PKI și chestii de securitate. Creează un certificat rădăcină pentru roiul pe care îl va utiliza
‫pentru a stabili certificatele de încredere și semnarea certificatelor pentru toate nodurile și toți managerii. Acesta va crea un certificat special pentru
‫acest prim nod manager deoarece este un manager față de un lucrător.
‫Apoi creează aceste jetoane pe care le putem folosi de fapt pe alte noduri pentru a intra în acest roi.
‫Apoi, o grămadă de alte lucruri în fundal, unde permite API-ul de tip swarm și creează ceva numit Baze de
‫date Consens pentru Raft, despre care vom vorbi mai târziu într-o parte de producție a cursului.
‫Doar pentru ca tu stii, Raft este un protocol care asigura de fapt consistenta pe mai multe noduri si este ideal
‫pentru utilizarea in Cloud unde nu putem garanta ca orice lucru va fi disponibil pentru orice moment
‫in timp.
‫Creează acea bază de date pe disc. Se stochează configurația roiului, și
‫primul manager, și de fapt o criptează.
‫Presupunând că sunteți pe versiunea 1. 13 sau mai nou. Apoi, va aștepta orice alte noduri înainte
‫de a începe efectiv replicarea bazei de date peste ele.
‫Din nou, tot traficul pe care îl va face odată ce vom crea alte noduri va fi criptat.
‫Una dintre componentele cheie ale lui Swarm care i-au diferențiat atunci când a ieșit pentru prima oară
‫a fost că nu aveam nevoie de un sistem suplimentar de stocare a valorii cheie sau de o arhitectură de baze de date care
‫să fie managementul configurației backendului roiului nostru.
‫Dacă ați fost în jurul valorii de industrie de ani sau zeci de ani chiar, există acest concept de
‫obicei de config db, care este acest sistem de baze de date separat de care aveți nevoie pentru a face redundant, care
‫va stoca toate informațiile despre orchestrație și sistemul de automatizare. Swarm a construit acel drept
‫în Docker chiar în daemon și ne ocupă de el.
‫Niciodată nu trebuie să facem nimic. Nu există parole de care să vă faceți griji. Nu există servicii speciale pentru
‫a începe sau ceva de genul asta.
‫Deci, înapoi la linia de comandă.
‫Veți observa aici că vorbește despre ... dacă vreau să adaug un muncitor la
‫roi, trebuie doar să tăiem și să lipim acest lucru pe celelalte servere pe care le-aș adăuga.
‫Mai târziu, de fapt, vom construi un roi cu mai multe noduri, dar deocamdată, vom păstra
‫acest lucru la un singur nod. Să aruncăm o privire la câteva dintre comenzile care vor ieși din ea.
‫Primul lucru este că putem face nodul docker. În acest caz, vedem doar un singur nod manager pe care
‫l-am creat.
‫Veți observa că este marcat ca lider și că nu poate fi decât un lider la un moment dat între toți managerii.
‫Din nou, din moment ce avem doar unul, atunci evident este liderul. Ne putem uita la ajutor pentru
‫a vedea ce alte opțiuni avem aici. Într-adevăr, comenzile de noduri utilizate pentru a vă aduce serverele în și
‫din roi sau pentru a le promova de la muncitori la manageri sau pentru a le înlătura de la manageri până la muncitori.
‫Dacă vă întoarceți din nou comanda de rotire a dockerilor, vom observa că este de fapt un domeniu foarte restrâns
‫de comandă.
‫Chiar este doar de a inițializa, fie să se alăture, fie să plece.
‫Noua comandă de deblocare, despre care putem vorbi într-o conferință ulterioară.
‫Pentru moment, hai să ne concentrăm pe noua comandă de serviciu Docker.
‫Din nou, serviciul într-un roi înlocuiește runul Docker.
‫Nu știu de fapt, dar cred că acest lucru a fost centrat în jurul ideii
‫că nu am vrut să rupem funcționalitatea Docker existentă, dar rularea Docker a fost întotdeauna construită de la bază ca
‫o singură soluție gazdă.
‫Ideea a fost să se concentreze asupra containerelor locale pe care le vorbește. Întrucât, atunci când începem să vorbim
‫despre un cluster, nu ne pasă atât de mult de nodurile individuale.
‫Probabil nu le numim. Noi le tratăm ca pe bovine, dacă ați
‫auzit vreodată de analogia animalelor și a bovinelor, unde sunt doar un număr.
‫Nu mergem individual la fiecare nod și începem un container individual.
‫Chiar aruncam cerințe în roiuri sub formă de servicii și apoi vom orchestra cum trebuie să pună totul în
‫afară, pe care noduri trebuie să fie și știm
‫doar că ne-a luat înapoi. serviciul docker create este modul
‫în care îi oferim niște comenzi noi. Să facem ceva foarte simplu.
‫Să presupunem de fapt să pornim imaginea alpină. Apoi vom avea imaginea Alpine folosind doar ping pentru
‫a lovi 8. 8. 8. 8, care este de fapt un server Google DNS, dar într-adevăr doar
‫vrem să îi oferim ceva de făcut în timp ce investigăm ce se întâmplă.
‫Apoi, veți vedea ca docker alerga, spits înapoi un ID, doar că nu este ID-ul containerului. Acesta este de fapt
‫ID-ul serviciului.
‫Veți vedea că acum avem un serviciu enumerat. Ca și comanda noastră de comandă a docker-ului,
‫deoarece nu
‫l-am numit, i-a dat un nume aleator. Putem vedea că de fapt a fost deja răsucite.
‫Celălalt. Când te uiți la servicii, vei vedea întotdeauna acest
‫număr cu un / în mijloc. Aceasta reprezintă cea din stânga este numărul de alergători.
‫Iar cel din dreapta este numărul de persoane pe care le-ați specificat pentru ca acestea să ruleze.
‫Scopul orchestratorului este de a face ca aceste numere să se potrivească, oricare ar fi acesta.
‫Dar din nou acest lucru nu ne arată adevăratul container.
‫Acest lucru ne arată doar o listă a serviciilor noastre, astfel încât să putem trece puțin mai departe.
‫Facem un serviciu de service docker, iar apoi îi oferim numele sau ID-ul serviciului și asta ne va arăta
‫de fapt sarcinile sau containerele pentru acest serviciu. Veți vedea că este similar cu comanda ls container container, dar de
‫fapt are acum această componentă nod, deoarece atunci când aveți de-a face cu scenarii cu mai multe servere, este posibil să
‫avem nevoie să știm de ce server rulează de fapt. Veți observa că de fapt
‫a dat un nume de creștere a numelui serviciului.
‫Dacă ne-am întors la comanda ls container container, care încă mai funcționează.
‫În acest caz, orchestrarea lui Swarm adaugă de fapt câteva informații la numele și la
‫imaginile reale care se execută. Vom acoperi și câteva dintre aceste diferențe subtile mai târziu.
‫Deocamdată, să luăm serviciul respectiv și să-l mărim. Pentru aceasta, vom folosi actualizarea serviciului de docare, apoi
‫numele serviciului nostru sau ID-ul în acest caz, voi face ID-ul. Și vreau să schimb un atribut
‫despre serviciu.
‫În acest caz, vreau să schimb numărul de replici.
‫Deci, dacă facem din nou un serviciu de docare, vedem trei din trei. Dacă facem un service doc de doc,
‫acum vedem trei sarcini. Veți observa că două au fost create cu doar câteva secunde în urmă.
‫Dacă eram destul de repede și dacă am fi desfășurat ceva destul de mare, am putea rula de fapt serviciul ls și de fapt,
‫să vedem că ne arată zero la trei. Unul din trei.
‫De fapt, va crește cu începutul lucrurilor. Se întâmplă ca Alpine să fi fost deja pe această mașină, din punctul
‫de vedere al imaginii sale, și nu a durat prea mult timp pentru a porni o comandă de ping.
‫Nu am putut fi atât de repede.
‫Ceea ce este interesant în legătură cu acea comandă de actualizare este că vă puteți imagina diferența dintre
‫comanda de rulare Docker pe care ați putea-o utiliza pe un singur server dev sau test sau pe mașina dvs.
‫locală și preocupările de producție de a păstra întotdeauna ceva cât
‫mai mult posibil.
‫Acesta este unul dintre obiectivele de design ale lui Swarm. Comanda pe care nu am
‫folosit-o încă este comanda de actualizare Docker. Aceasta a fost o comandă pentru containerele care rulează Docker, care ne-au
‫permis să actualizăm anumite variabile pe containerul nostru care rulează, fără a trebui să-l omoare și să-l repornească.
‫Aproape toate aceste opțiuni sunt legate de limitarea și controlul utilizării resurselor pentru acel container.
‫Deoarece acesta este unul dintre lucrurile tipice pe care le vedeți atunci când executați o cerere pe termen
‫lung este că trebuie să vă schimbați resursele, poate pentru că bazele de date au devenit mai mari și au nevoie de mai mult RAM.
‫Sau poate aveți un proces în afara controlului, care consumă prea mult CPU și trebuie să-l limitați.
‫Dacă vom ajuta la comanda de actualizare a serviciului docker, veți vedea că avem mai multe opțiuni.
‫Deoarece scopul unui serviciu Swarm este acela că poate să înlocuiască containerele și să actualizeze modificările în
‫serviciu fără a lua totul în jos.
‫Dacă ai avea un serviciu cu trei containere în el, ai putea lua tehnic o dată la un moment dat pentru a face o schimbare și să facem un fel
‫de actualizare rulantă, care este modelul verde albastru despre care am vorbit. De aceea vedem mai multe opțiuni aici
‫pentru că putem schimba aceste opțiuni care ar putea necesita o repornire a containerului, dar
‫roama se va asigura în mod inteligent că modul în care le actualizăm este într-un model
‫care asigură o disponibilitate constantă.
‫Așa că întoarceți-vă rapid la lista noastră de containere. Veți observa că avem acum trei, și
‫dacă am intrat și, ca un necinstit, am făcut un container de docare și am specificat unul dintre aceste
‫containere și l-am forțat ... să zicem că am bătut prima și l-am luat.
‫In regula.
‫Acum fac un serviciu de docare și vezi cum arată două din trei?
‫Pentru că am intrat în spatele lui Swarm și am luat de fapt un container de alergare, va
‫identifica acest lucru și va lansa unul nou în câteva secunde pentru ao înlocui pe cel care
‫a coborât.
‫Deci, daca am facut un serviciu de docking ps pe geroasa, veti vedea ca arata de fapt istoria primei sarcini aici in lista este ca a
‫avut unul care a esuat si a inceput un nou unul acum 24 de secunde.
‫Aceasta este una dintre responsabilitățile unui sistem de orchestrare a containerului este să vă asigurați că serviciile pe
‫care le-ați specificat sunt întotdeauna difuzate și, dacă nu
‫reușesc, se recuperează din acel eșec. Care este cu totul altceva decât a alerga docker, nu? docker-ul nu ar
‫crea niciodată un container.
‫De aceea, de fiecare dată când facem oricare dintre aceste comenzi de service Docker, nu vorbim direct
‫de o acțiune cum ar fi crearea unui container.
‫Spunem de fapt un sistem de orchestrație, și-a pus slujba în coada ta.
‫Când puteți ajunge la ele, vă rugăm să efectuați acțiunile pe care le-am întrebat aici. Asta eo mare
‫diferență.
‫Este subtil în linia de comandă, dar este o mare diferență, deoarece înseamnă că există posibilități de redirecționare.
‫Există o atenuare a eșecului și o mulțime de inteligență încorporată în asta.
‫În acest caz, dacă aș vrea să eliminăm toate aceste
‫containere, aș fi nevoit să eliminăm serviciul. Va trebui să fac serviciul docker rm.
‫Și apoi înghețatul.
‫Dacă facem un serviciu de docare, nu vedem nimic. Dacă facem un
‫container de docuri, vedem trei containere.
‫Oh și acolo mergem.
‫Asta arată că automatizarea se întâmplă pe backend.
‫Am reușit să arătăm repede că am șters serviciul, dar sistemul de orchestrație nu a trecut prin toate
‫procesele de curățare a serviciului și sarcina din spatele acestuia. Aceste concepte ar trebui să fie destul de ușor de înțeles, pentru
‫că ele se extind foarte mult pe conceptele Docker pe care le-am avut mai devreme în
‫acest curs.
‫În continuare, să construim un colț cu mai multe noduri și să începem să scară containerele noastre.