‫Actualizări de servicii. Probabil că ați presupus că există o modalitate de a vă actualiza serviciile,
‫chiar dacă nu ne-am concentrat încă pe asta.
‫Să vorbim despre asta, deoarece actualizările au o mulțime de lucruri care se petrec sub capace. Funcția de actualizare a roboților este centrată în jurul
‫unui model de actualizare rulant pentru replicile dvs. Ceea ce înseamnă că dacă aveți un serviciu cu mai
‫mult de o replică și, sperăm că o faceți, va trece prin ele în mod implicit,
‫unul câte unul, actualizând fiecare container înlocuindu-l cu noile setări pe care le puneți în
‫actualizare comanda.
‫O mulțime de oameni vor spune că orchestrații împiedică downtime-ul în actualizări, dar nu am de gând să spun
‫că acest lucru previne întreruperi.
‫O să spun că limitează perioada de nefuncționare. Deoarece prevenirea perioadelor de nefuncționare în orice sistem este sarcina de testare.
‫Chiar trebuie să începeți să testați cum faceți actualizările și să determinați, are impact asupra utilizatorilor mei?
‫Actualizarea unei baze de date influențează aplicația web? Probabil că o face.
‫Fiecare aplicație pentru care aveți un serviciu se va actualiza și va afecta alte lucruri în jurul acesteia
‫în mod diferit.
‫Nu e treaba unui orchestrator.
‫Un orchestrator nu poate determina că acesta este un protocol de bază de date, iar acesta este un protocol de aplicație
‫REST ușor.
‫Deci, acestea vor fi diferite, lucruri complicate cu care trebuie să vă ocupați.
‫În cazul actualizărilor de servicii, dacă este vorba doar de un API REST sau de un interfață web care nu face nimic
‫fantezist ca prize web sau o interogare lungă, dacă este ceva foarte simplu ca acesta sau un site web static,
‫probabil veți avea o actualizare ușoară și nu va fi o problemă.
‫Dar alte servicii cum ar fi bazele de date sau stocarea permanentă sau orice altceva care necesită o conexiune persistentă ...
‫acestea vor fi întotdeauna o provocare indiferent de ceea ce încercați să actualizați.
‫Deci, testați devreme și testați des.
‫După cum am spus mai devreme, acest lucru va înlocui cu siguranță containerele în cele mai multe actualizări. Cu excepția cazului în care
‫actualizați o etichetă sau alte metadate cu serviciul, acesta
‫va trece prin și va schimba fiecare container cu unul complet nou.
‫Fii pregătită pentru asta. Are multe opțiuni. De fapt, ultimul număr pe
‫care l-am numărat, au fost cel puțin 77 de opțiuni pentru comanda de actualizare. Dar tot ceea ce vrei să faci
‫poate fi modificat.
‫O mulțime de opțiuni din comanda de actualizare sunt de fapt opțiuni de creare care au
‫doar -rm și -add la sfârșitul lor. Deoarece dacă este o opțiune care poate fi folosită pentru mai multe
‫valori, să spunem un port pentru a publica sau o variabilă de mediu, cele pe care le puteți utiliza multe dintre ele.
‫Dreapta?
‫Deci, trebuie să puteți spune comenzii de actualizare pe care le adăugați și pe care le eliminați.
‫O să vedem asta într-un minut.
‫Aceasta include, de asemenea, opțiunile de revizuire și de verificare a sănătății.
‫Ar trebui să vă uitați la opțiunile pentru acestea și să vedeți dacă valorile lor implicite nu sunt ideale pentru aplicația
‫dvs. și să testați setări diferite pentru a vedea dacă ușurează actualizarea pentru dvs. și pentru sistemul dvs.
‫De asemenea, veți vedea că avem opțiuni de scalare și de redirecționare, care sunt comenzile proprii acum.
‫Acestea erau opțiunile pe care trebuia să le specificați cu --rollback sau --scale, dar atât de mulți oameni le
‫foloseau atât de frecvent încât Docker îi face acum un fel de cetățeni de primă clasă în
‫linia de comandă.
‫Ar putea adăuga mai mulți dintre aceștia în viitor.
‫În cele din urmă, înainte de a ajunge la câteva exemple, dacă faceți stive, o stivă care se desfășoară în același stack este
‫o actualizare.
‫De fapt, nu există o opțiune separată pentru actualizările stivei.
‫Faceți doar o implementare de stivă cu același fișier care a fost editat.
‫Apoi, va funcționa cu comenzile de serviciu și cu rețelele și cu toate celelalte lucruri pe care le are. Acesta va lucra cu ei pentru
‫a se asigura dacă sunt necesare schimbări, ca acestea să fie aplicate.
‫Să ne uităm la câteva exemple rapide și apoi vom ajunge la linia de comandă.
‫Acesta este probabil cel mai frecvent exemplu pe care îl veți folosi, și anume să schimbați imaginea
‫unui serviciu.
‫De fiecare dată când actualizați aplicația și construiți o imagine nouă, va trebui să faceți
‫o comandă de actualizare a serviciului, cu numele imaginii și apoi numele serviciului.
‫Deci, în acest caz, poate am avut aplicația mea cu o etichetă de 1. 2. 0.
‫Și în acest caz, aplic acum 1. 2. 1, iar serviciul va determina, ah
‫da, aceasta este o imagine diferită de cea pe care am
‫executat-o ​​în serviciul meu și vom merge și le vom actualiza. Pe următoarea, vom arăta cum puteți face mai multe lucruri simultan
‫într-o singură comandă de actualizare.
‫Puteți adăuga o variabilă de mediu cu env-add, și apoi puteți elimina un port cu
‫publicarea -rm.
‫De asemenea, am putea adăuga și elimina variabilele de mediu și să publicăm porturi în
‫aceeași comandă de actualizare cât dorim. În ultimul, aceasta arată modul în care putem utiliza aceste noi
‫comenzi de scară și de revocare în mai multe servicii în același timp. Care este unul dintre avantajele utilizării acestora prin intermediul
‫comenzii de actualizare este că acestea se pot aplica la mai multe servicii.
‫În acest caz, de fapt, voi modifica în același timp numărul de replici ale webului
‫și ale serviciilor API.
‫După cum am spus acum ceva timp, în actualizările Swarm, nu aveți o altă comandă de implementare.
‫Este vorba doar de același set de stack de docuri, cu fișierul pe care l-ați editat și este de datoria
‫să lucrați cu toate celelalte părți ale API pentru a determina
‫dacă sunt necesare modificări și apoi să le lansați cu o actualizare de serviciu.
‫In regula. Să începem prin crearea unui serviciu astfel încât să îl putem manipula cu unele comenzi de actualizare.
‫serviciul docker crea -p 8088 80 nume web, și vom folosi Nginx, și vom specifica o versiune
‫cum ar fi întotdeauna în producție.
‫Este frumos, acum că avem de fapt în ultima jumătate a anului 2017, opțiunea detach cu serviciul nostru de a crea și actualiza comenzi,
‫putem vedea de fapt acest lucru să se întâmple sincron în timp real.
‫Deci, acest lucru va fi bun pentru comenzile de actualizare pentru a vedea cum actualizările se desfășoară efectiv prin linia de comandă.
‫In regula. Acum, dacă facem un serviciu de docare, vedem că serviciul
‫nostru se execută și că are 1 din 1 replici, așa că este bine să mergem.
‫Acum permiteți-ne să scalăm serviciile noastre, astfel încât să putem avea mai multe replici la care să lucrăm. docker service scară Web
‫= 5. Și tocmai ați văzut că unul dintre ele fugea deja,
‫iar ceilalți 4 trebuiau să înceapă. A trecut destul de repede pe a mea pentru că
‫am avut deja imaginea descărcată, dar dvs. poate dura câteva minute în timp ce acestea sunt în stare în așteptare ca imaginile descărcate
‫pe celelalte noduri.
‫In regula.
‫Să facem o actualizare prin schimbarea imaginii acelui Nginx.
‫Veți vedea aici că am ales o imagine mai veche.
‫Acum, Docker nu-i pasă de ce este de fapt imaginea.
‫Ar putea fi o aplicație
‫complet diferită pentru tot ce-i pasă. Știe doar că, în acest serviciu, o schimb în altă imagine.
‫Amintiți-vă, în mod implicit, va trece aici unul câte unul.
‫Mai întâi îl va elimina, va crea una nouă, iar atunci când este bună
‫să meargă și arată sănătoasă, va începe în următoarea. În următorul exemplu, vom schimba portul
‫publicat.
‫Dar nu poți schimba un port.
‫Trebuie să adăugați și să le eliminați în același timp.
‫Deci, în acest caz, pentru că am publicat-o pentru prima oară cu un 8088, trebuie să facem o actualizare a
‫serviciului docker update rm 8088. Nu trebuie să precizez valoarea. Trebuie doar să precizez cheia. Atunci
‫vom publica noul, 9090. Apoi valoarea, care în acest caz este de 80. Veți vedea că va
‫face același proces de actualizare ca înainte.
‫Ultimul exemplu despre care vreau să vorbesc este un fel de sfat. Deoarece veți avea adesea o provocare
‫cu ceva numit reechilibrare. Sau dacă schimbați numărul de noduri sau dacă vă mutați multe lucruri în jur, dacă aveți
‫multe containere în roiurile voastre, s-ar putea să știți că nu sunt chiar ieșiți. Ai ceva noduri
‫destul de luminoase pe cât de multe containere rulează
‫și pe altele care au multe. Dacă aveți multe lucruri în schimbare, Swarm nu va muta lucrurile în jurul valorii de a
‫păstra totul echilibrat în ceea ce privește numărul de resurse utilizate.
‫Dar ceea ce puteți face este că puteți forța actualizarea unui serviciu chiar fără a schimba nimic în acest serviciu.
‫Apoi, ea va reimpune sarcinile și în acest caz va alege cele mai puțin utilizate noduri, care reprezintă o formă de reechilibrare.
‫De multe ori într-un roi mai mic când mă mișc ceva mare sau adaug o grămadă de noduri, deodată am o grămadă de
‫servere goale care nu fac nimic și trebuie să lucrez la ele.
‫Așadar, ceea ce voi face este să iau una sau două dintre serviciile mele și voi face o actualizare
‫a serviciului docker - forță, și în acest caz va trece prin și va înlocui complet sarcinile.
‫Bineînțeles, va folosi programul implicit de a căuta noduri cu cel mai mic număr de containere și
‫cel mai mic număr de resurse folosite.
‫Este un truc pentru a obține o cantitate neuniformă de lucru pe nodurile tale.
‫Nu uitați să curățați prin eliminarea serviciului pe care l-am creat în această lecție.