Cu excepția cazului în care ați locuit într-un container de transport, probabil ați auzit despre containere. Industria a făcut o mișcare distinctă de la infrastructura persistentă la cea efemeră, iar containerele sunt pătrate în mijlocul acelei mutări. Motivul este destul de simplu: în timp ce containerele ajută cu siguranță echipele de dezvoltatori să funcționeze rapid, au și mai mult potențial de a schimba complet fața operațiunilor.

Dar cum arată exact asta? Ce se întâmplă când sunteți gata să faceți saltul containerelor care rulează local sau manual pe câteva servere? Într-o lume ideală, doriți să aruncați aplicația asupra unui grup de servere și să spuneți „rulați-o!”

Ei bine, din fericire, asta este unde suntem astăzi.

În acest articol, vom explora ce este Docker Swarm, împreună cu câteva dintre caracteristicile excelente pe care le are de oferit. Apoi vom arunca o privire la cum arată efectiv utilizarea modului Swarm și implementarea pe un roi și vom încheia cu câteva exemple despre cum sunt operațiunile zilnice cu un roi implementat. O cunoaștere de bază despre Docker și containere este cu siguranță recomandată, dar puteți verifica acest lucru excelent postare pe blog mai întâi dacă sunteți nou la containere.

Ce este Docker Swarm?

Înainte să ne scufundăm în crearea și implementarea în primul nostru roi, este util să avem o idee despre ce este Docker Swarm. Docker în sine există de ani de zile și majoritatea oamenilor de astăzi se gândesc la asta ca la un timp de rulare pentru containere. În realitate, Docker este alcătuit din multe piese diferite, toate lucrând împreună. De exemplu, acea porțiune de rulare a containerului este gestionată de două componente mai mici, numite runC și containerd . Pe măsură ce Docker a evoluat și a dat înapoi comunității, au descoperit că crearea acestor componente mai mici este cel mai bun mod de a crește și de a adăuga rapid funcții. Ca atare, acum avem SwarmKit și modul Swarm, care este încorporat direct în Docker.

Docker Swarm este un motor de orchestrare a containerelor. La un nivel ridicat, este nevoie de mai multe motoare Docker care rulează pe diferite gazde și vă permite să le utilizați împreună. Utilizarea este simplă: declarați aplicațiile dvs. ca stive de servicii și lăsați Docker să se ocupe de restul. Serviciile pot fi de la instanțe de aplicație la baze de date sau utilitare precum Redis sau RabbitMQ. Acest lucru ar trebui să pară familiar dacă ați lucrat vreodată cu docker-compose în curs de dezvoltare, deoarece este exact același concept. De fapt, o declarație stivă este literalmente doar un docker-compose.yml fișier cu sintaxa versiunii 3.1. Acest lucru înseamnă că puteți utiliza o configurație similară (și, în multe cazuri, identică) de compunere pentru dezvoltare și implementarea roiului, dar am un pic înainte de mine aici. Ce se întâmplă atunci când aveți instanțe de Docker în modul Swarm?

Nu cădea de pe plută

Avem două tipuri de noduri (servere) în lumea Swarm: manageri și lucrători. Este important să rețineți că managerii sunt și muncitori, ei au doar responsabilitatea suplimentară de a menține lucrurile în funcțiune. Fiecare roi începe cu un nod manager desemnat ca lider. De acolo, este doar o chestiune de a rula o comandă pentru a adăuga în siguranță noduri la roi.

Swarm este extrem de disponibil datorită implementării algoritmului Raft. Nu voi intra în prea multe detalii despre Raft pentru că există deja un mare tutorial despre modul în care funcționează, dar iată ideea generală: nodul lider verifică în mod constant cu nodurile sale colegii de manager și le sincronizează stările. Pentru ca o schimbare de stat să fie „acceptată”, nodurile managerului ajung la un consens, ceea ce se întâmplă atunci când majoritatea nodurilor recunosc schimbarea de stat.

Frumusețea este că nodurile managerului pot scădea sporadic fără a compromite consensul roiului. Dacă o schimbare de stat ajunge la consens, știm că există garanția că există pe majoritatea nodurilor managerilor și va persista chiar dacă actualul lider eșuează.

Să presupunem că avem trei noduri manager numite A, B și C. Desigur, A este liderul nostru neînfricat. Ei bine, într-o zi, o eroare tranzitorie de rețea bate A offline, lăsând B și C în pace. După ce nu au aflat de A de mult timp (câteva sute de milisecunde), B și C așteaptă o perioadă de timp generată aleatoriu înainte de a se prezenta la alegeri și de a-l anunța pe celălalt. Desigur, primul care va urca la alegeri, în acest caz, va fi ales. În acest exemplu, B devine noul lider și se restabilește cvorumul. Dar apoi, complot: ce se întâmplă când A revine online? Se va crede că este încă lider, nu? Fiecare alegere are un termen asociat, așa că A a fost de fapt ales în mandatul 1. De îndată ce A revine online și începe să comande B și C în jur, îi vor anunța cu amabilitate că B este liderul termenului 2 și A va demisiona.

Același proces funcționează la o scară mult mai mare, desigur. Puteți avea mai mult de trei noduri manager. Voi adăuga însă o altă notă rapidă. Fiecare roi poate lua doar un anumit număr de pierderi de manager. Un roi de n noduri manager poate pierde (n-1)/2 manageri fără a pierde cvorumul. Asta înseamnă că pentru un roi de trei manageri poți pierde unul, pentru cinci poți pierde doi etc. Motivul care stă la baza acestui lucru revine la ideea despre consens majoritar și este cu siguranță ceva de care trebuie să ții cont în timp ce mergi la producție.

Programarea sarcinilor și reconcilierea

Până în prezent, am stabilit că managerii noștri sunt foarte buni să rămână sincronizați. Grozav! Dar ce fac ei de fapt? Vă amintiți cum am spus că implementați o mulțime de servicii în Swarm? Când declarați serviciile dvs., furnizați Swarm informații importante despre modul în care doriți efectiv ca serviciile dvs. să fie rulate. Aceasta include parametri precum câte replici doriți de la fiecare serviciu, cum ar trebui distribuite replicile, dacă acestea ar trebui să fie rulate numai pe anumite noduri și multe altele.

Odată ce un serviciu este implementat, este sarcina managerilor să se asigure că toate cerințele de implementare pe care le setați continuă să fie îndeplinite. Să presupunem că implementați un serviciu Nginx și specificați că ar trebui să existe trei replici. Managerii vor vedea că nu rulează containere și distribuie uniform cele trei containere între nodurile disponibile.

Ceea ce este și mai cool, totuși, este că, dacă un container ar eșua (sau un întreg nod ar fi deconectat), Swarm va crea automat containere pe nodurile rămase pentru a compensa diferența. Dacă spuneți că doriți să ruleze trei containere, veți avea trei containere care rulează, în timp ce Swarm gestionează toate detaliile pline de grijă. Plus - și acesta este un mare plus - extinderea în sus sau în jos este la fel de ușoară ca a oferi Swarm o nouă setare de replicare.

Descoperirea serviciului și echilibrarea încărcării

Vreau să subliniez un detaliu important, dar subtil, din ultimul exemplu: dacă Swarm pornește inteligent containere pe nodurile la alegere, nu știm neapărat unde vor rula aceste containere. La început, poate suna înfricoșător, dar este de fapt una dintre cele mai puternice caracteristici ale lui Swarm.

Continuând același exemplu Nginx, imaginați-vă că i-am spus lui Docker că respectivele containere ar trebui să expună portul 80. Dacă îndreptați browserul către un nod care rulează acel container pe portul 80, veți vedea conținutul acelui container. Nu există nicio surpriză acolo. Ceea ce poate fi surprinzător este însă că, dacă trimiteți solicitarea dvs. către un nod care nu rulează acel container, veți vedea în continuare același conținut! Ce se intampla aici?

Swarm folosește de fapt o rețea de intrare pentru a trimite solicitarea dvs. către un nod disponibil care rulează acel container și echilibrează încărcarea în același timp. Deci, dacă efectuați trei cereri către același nod, probabil că veți atinge cele trei containere diferite. Atâta timp cât știți IP-ul unui singur nod din roi, puteți accesa orice rulează în el. În schimb, acest lucru vă permite să îndreptați un echilibrator de sarcină (cum ar fi un ELB) către toate nodurile din roi, fără a fi nevoie să vă faceți griji cu privire la ceea ce rulează unde.

Nu se oprește la conexiunile externe. Serviciile care rulează pe aceeași stivă au o rețea suprapusă care le permite să comunice între ele. În loc să codificați adrese IP în codul dvs., puteți utiliza pur și simplu numele serviciului ca nume de gazdă la care doriți să vă conectați. De exemplu, dacă aplicația dvs. trebuie să comunice cu un serviciu Redis numit „redis”, acesta poate folosi pur și simplu „redis” ca nume de gazdă și Swarm își va direcționa solicitarea către containerul corespunzător. Și pentru că acest lucru funcționează perfect în dezvoltarea cu docker-compose și în producție cu Docker Swarm, este un lucru mai puțin de care să vă faceți griji atunci când implementați aplicația.

Actualizări continue

Dacă sunteți în operații, probabil că ați experimentat un atac de panică atunci când o actualizare a producției merge în mod îngrozitor. Ar putea fi o actualizare proastă a codului sau chiar doar o eroare de configurare, dar brusc producția nu mai funcționează! Șansele sunt că șefului nu îi va păsa în niciun fel. Vor ști doar că e vina ta. Ei bine, nu vă faceți griji, Swarm și-a pus spatele și pe acesta.

Când actualizați un serviciu, puteți defini câte containere trebuie actualizate la un moment dat și ce ar trebui să se întâmple dacă noile containere încep să eșueze. După un anumit prag, Swarm poate opri actualizarea sau (începând cu Docker 17.04) poate întoarce containerele la imaginea și setările anterioare. Nu vă faceți griji că trebuie să vă aduceți șefului o cafea mâine dimineață.

Securitate

Nu în ultimul rând, dar aproape deloc, Docker Swarm vine cu caracteristici excelente de securitate. Când un nod se alătură roiului, acesta folosește un simbol care nu numai că se verifică, ci verifică și faptul că se alătură roiului pe care credeți că este. Din acel moment, toate comunicările între noduri au loc folosind criptarea reciprocă TLS. Această criptare este asigurată și gestionată automat de către Swarm, astfel încât nu trebuie să vă faceți griji cu privire la reînnoirea certificatelor și a altor probleme tipice de securitate. Și, bineînțeles, dacă doriți să forțați o rotație a tastei, există o comandă pentru asta.

Cea mai recentă versiune a Docker Swarm vine, de asemenea, cu gestionarea secretelor încorporată. Acest lucru vă permite să implementați în siguranță secrete, cum ar fi cheile și parolele, către serviciile care au nevoie de ele și numai serviciile care au nevoie de ele. Când furnizați un serviciu cu un secret, containerele pentru acel serviciu vor avea un fișier special montat în sistemul lor de fișiere care include valoarea secretului. Este de la sine înțeles, dar acest lucru este mult mai sigur decât utilizarea variabilelor de mediu, care erau abordarea tradițională.

Scufundându-se în roi

Dacă ești ceva ca mine, îți vine să sărești și să iei toate aceste funcții la întoarcere! Deci, fără alte întrebări, să ne scufundăm!

Exemplu de aplicație Docker Swarm

Am creat o aplicație Flask foarte rudimentară pentru a demonstra puterea și ușurința utilizării Docker Swarm. Aplicația web afișează pur și simplu o pagină care vă spune care container a servit solicitarea dvs., câte solicitări totale au fost servite și care este parola de bază de date „secretă”.

Este împărțit în trei servicii: aplicația reală Flask, un proxy invers Nginx și un depozit de chei Redis. La fiecare solicitare, aplicația mărește num_requests tasta Redis, deci, indiferent de instanța Flask pe care o atingeți, veți vedea numărul corect de solicitări reflectate.

Tot codul sursă este disponibil pe GitHub dacă doriți să „verificați” ce se întâmplă.

Joacă-te cu Docker!

Simțiți-vă liber să vă folosiți propriile servere pe măsură ce parcurgeți acest tutorial, dar vă recomand să îl utilizați juca-cu-docker.com dacă doriți să intrați. Este un site administrat de câțiva dezvoltatori Docker care vă permite să învârtiți mai multe noduri din rețea care au Docker preinstalat. Vor fi închise după patru ore, dar acest lucru este suficient pentru acest exemplu!

Crearea unui roi

Bine, iată-ne! Continuați și creați trei instanțe în PWD (play-with-docker) sau rotiți trei servere în serviciul dvs. preferat VPS (server privat virtual) și instalați motorul Docker pe toate. Rețineți că ați putea întotdeauna să creați o imagine și să o reutilizați atunci când adăugați noduri în viitor. Nu există nicio diferență din punct de vedere software între un nod manager și un nod lucrător, deci nu este nevoie să mențineți două imagini diferite.

Încă te învârți? Nu vă faceți griji, voi aștepta. Bine, acum vom crea primul nostru manager și nod lider. În prima instanță, inițializați un roi:

docker swarm init --advertise-addr

Înlocuiți cu adresa IP a nodului dvs. Pe PWD, adresa IP este afișată în partea de sus și, dacă utilizați propriul dvs. VPS, nu ezitați să utilizați adresa IP privată a serverului, atât timp cât este accesibilă din celelalte noduri din rețeaua dvs.

Acum ai un roi! Totuși, este un roi destul de plictisitor, deoarece are doar un nod. Să mergem mai departe și să adăugăm celelalte noduri. Veți observa că, atunci când ați rulat init, a afișat un mesaj lung care explica modul de utilizare a jetonului de asociere. Nu o vom folosi pentru că ar face ca celelalte noduri să funcționeze și dorim ca aceștia să fie manageri. Să obținem jetonul de unire pentru un manager executând acest lucru pe primul nod:

docker swarm join-token manager

Copiați comanda rezultată și rulați-o pe al doilea și al treilea nod. Iată, un roi cu trei noduri! Să verificăm dacă toate nodurile noastre există într-adevăr. docker node ls comanda va enumera toate nodurile din roiul nostru. Ar trebui să vedeți așa ceva:

$ docker node ls ID HOSTNAME STATUS AVAILABILITY MANAGER STATUS su1bgh1uxqsikf1129tjhg5r8 * node1 Ready Active Leader t1tgnq38wb0cehsry2pdku10h node3 Ready Active Reachable wxie5wf65akdug7sfr9uuleui node2 Ready Active Reachable

Observați cum primul nostru nod are un asterisc lângă ID. Asta ne spune pur și simplu că acesta este nodul la care suntem conectați în prezent. Putem vedea, de asemenea, că acest nod este în prezent Leader, iar celelalte noduri sunt accesibile, dacă i s-ar întâmpla ceva.

Luați un moment pentru a aprecia cât de ușor a fost și să implementăm prima noastră aplicație!

Trimite-l!

Chiar în acest moment, echipa de dezvoltare a afacerii a promis unui client că noua lor aplicație va fi implementată și gata în decurs de o oră! Tipic, știu. Dar nu vă temeți, nu vom avea nevoie de aproape atât de mult timp, deoarece a fost construit folosind Docker! Dezvoltatorii au avut amabilitatea să ne împrumute docker-compose lor fişier:

version: '3.1' services: web: image: lsapan/docker-swarm-demo-web command: gunicorn --bind 0.0.0.0:5000 wsgi:app deploy: replicas: 2 secrets: - db_password nginx: image: lsapan/docker-swarm-demo-nginx ports: - 8000:80 deploy: mode: global redis: image: redis deploy: replicas: 1 secrets: db_password: external: true

O vom descompune într-o clipă, dar încă nu avem timp pentru asta. Să-l implementăm! Continuați și creați un fișier pe primul dvs. nod numit docker-compose.yml și completați-l cu configurația de mai sus. Puteți face acest lucru cu ușurință cu echo '' > docker-compose.yml.

De obicei, am putea implementa acest lucru, dar configurația noastră menționează că folosim un secret numit db_password, deci să creăm rapid acel secret:

echo 'supersecretpassword' | docker secret create db_password -

Grozav! Acum tot ce trebuie să facem este să-i spunem lui Docker să folosească configurația noastră:

docker stack deploy -c docker-compose.yml demo

Când rulați această comandă, veți vedea Docker creând cele trei servicii pe care le-am definit: web, nginx și redis. Cu toate acestea, pentru că am denumit demo-ul nostru de stivă, serviciile noastre sunt denumite de fapt demo_web, demo_nginx și demo_redis. Ne putem uita la serviciile noastre care rulează executând docker service ls comandă, care ar trebui să arate așa ceva:

$ docker service ls ID NAME MODE REPLICAS IMAGE PORTS cih6u1t88vx7 demo_web replicated 2/2 lsapan/docker-swarm-demo-web:latest u0p1gd6tykvu demo_nginx global 3/3 lsapan/docker-swarm-demo-nginx:latest *:8000->80/ tcp wa1gz80ker2g demo_redis replicated 1/1 redis:latest

Voila! Docker a descărcat imaginile noastre în nodurile corespunzătoare și a creat containere pentru serviciile noastre. Dacă replicile dvs. nu sunt încă la capacitate maximă, așteptați un moment și verificați din nou. Probabil că Docker încă descarcă imaginile.

A vedea e a crede

Totuși, nu luați cuvântul meu (sau cuvântul lui Docker). Să încercăm să ne conectăm la aplicația noastră. Configurarea serviciului nostru îi spune lui Docker să expună NGINX pe portul 8000. Dacă sunteți pe PWD, ar trebui să existe un link albastru în partea de sus a paginii care să scrie „8000”. PWD a detectat automat că avem un serviciu care rulează pe acel port! Faceți clic pe acesta și vă va direcționa către nodul selectat de pe portul 8000. Dacă ați rulat propriile servere, pur și simplu navigați la unul dintre adresele IP ale serverelor dvs. de pe portul 8000.

Veți fi întâmpinat cu un ecran frumos, care vă oferă câteva informații de bază:

Faceți o notă a containerului care a servit solicitarea dvs. și apoi actualizați pagina. Șansele sunt schimbate. Dar de ce? Ei bine, i-am spus lui Docker să creeze două replici ale aplicației noastre Flask și distribuie cereri către ambele instanțe. Tocmai ați lovit celălalt container a doua oară. De asemenea, veți observa că numărul de solicitări a crescut, deoarece ambele containere Flask comunică cu singura instanță Redis pe care am specificat-o.

Simțiți-vă liber să încercați să atingeți portul 8000 din orice nod. Veți fi în continuare corect direcționat către aplicație.

Demitizarea magiei

În acest moment, totul funcționează și, sperăm, ați găsit că procesul este nedureros! Să aruncăm o privire mai atentă asupra acestui docker-compose.yml înregistrați și vedeți ce i-am spus de fapt lui Docker. La un nivel ridicat, vedem că am definit trei servicii: web, nginx și redis. La fel ca un fișier normal de compunere, am oferit Docker o imagine de utilizat pentru fiecare serviciu, precum și o comandă de executat. În cazul nginx, am specificat, de asemenea, că portul 8000 de pe gazdă ar trebui să fie mapat la portul 80 din container. Toate acestea sunt sintaxa standard de compunere până acum.

Ceea ce este nou aici sunt cheile de implementare și secrete. Aceste chei sunt ignorate de docker-compose, deci nu vor afecta mediul dvs. de dezvoltare, dar sunt utilizate de docker stack. Să ne uităm la serviciul web. Destul de simplu, îi spunem lui Docker că am dori să rulăm două replici aplicația noastră Flask. Îi anunțăm, de asemenea, pe Docker că serviciul web necesită db_password secret. Aceasta este ceea ce asigură că containerul va avea un fișier numit /run/secrets/db_password care conține valoarea secretului.

Trecând la Nginx, putem vedea că modul de implementare este setat la global. Valoarea implicită (care este utilizată implicit în web) este replicated, ceea ce înseamnă că vom specifica câte replici dorim. Când specificăm global, acesta îi spune lui Docker că fiecare nod din roi trebuie să ruleze exact o instanță a serviciului. Rulați docker service ls din nou, veți observa că nginx are trei replici, una pentru fiecare nod din roiul nostru.

În cele din urmă, i-am instruit lui Docker să ruleze o singură instanță de Redis undeva în roi. Nu contează unde, deoarece containerele noastre web sunt direcționate automat către acesta atunci când solicită gazda Redis.

Folosind Swarm de la o zi la alta

Felicitări pentru implementarea primei aplicații într-un Docker Swarm! Să luăm un moment pentru a examina câteva comenzi obișnuite pe care le veți folosi.

Inspectându-vă roiul

Trebuie să vă verificați serviciile? Încercați docker service ls și docker service ps . Primul vă arată o imagine de ansamblu la nivel înalt a fiecărui serviciu, iar cel din urmă vă oferă informații despre fiecare container care rulează pentru serviciul specificat. Acesta este deosebit de util atunci când doriți să vedeți ce noduri rulează un serviciu.

Actualizări continue

Dar când sunteți gata să actualizați o aplicație? Ei bine, interesantul despre docker stack deploy este că va aplica, de fapt, actualizări și la o stivă existentă. Să presupunem că ați împins o nouă imagine Docker în depozitul dvs. De fapt, puteți rula aceeași comandă de implementare pe care ați folosit-o prima dată și roiul dvs. va descărca și implementa noua imagine.

Desigur, este posibil să nu doriți întotdeauna să actualizați fiecare serviciu din stiva dvs. Putem efectua actualizări și la nivel de serviciu. Să presupunem că am actualizat recent imaginea pentru serviciul meu web. Pot emite această comandă pentru a actualiza toate containerele mele web:

docker service update --image lsapan/docker-swarm-demo-web:latest demo_web

Un avantaj suplimentar la acea comandă este că va aplica o actualizare continuă dacă ați specificat că ar trebui să fie în configurația originală. Și chiar dacă nu ați făcut-o, puteți transmite steaguri pentru actualizare, care îi vor instrui să facă o actualizare continuă astfel:

docker service update --image lsapan/docker-swarm-demo-web:latest --update-parallelism 1 --update-delay 30s demo_web

Aceasta va actualiza câte un container la un moment dat, așteptând 30 de secunde între actualizări.

Scalarea serviciilor în sus sau în jos

A avea două containere web este minunat, dar știi ce este mai bine? Având zece! Scalarea serviciilor în sus și în jos într-un roi este la fel de ușoară ca:

docker service scale demo_web=10

Rulați acea comandă și verificați ieșirea docker service ps demo_web. Veți vedea că acum avem zece containere, iar opt dintre ele au fost pornite acum un moment. Dacă sunteți interesat, puteți, de asemenea, să reveniți la aplicația web și să reîmprospătați pagina de câteva ori pentru a vedea că acum primiți mai mult decât cele două ID-uri originale ale containerului.

Eliminarea stivelor și a serviciilor

Stivele și serviciile dvs. sunt implementate și scalate, minunat! Dar acum doriți să le scoateți offline. Acest lucru se poate face cu rm respectiv comanda. Pentru a elimina stiva noastră demo, rulați comanda:

docker stack rm demo

Sau, dacă preferați să eliminați un singur serviciu, utilizați doar:

docker service rm demo_web

Noduri de scurgere

Amintiți-vă când am fugit docker node ls mai devreme pentru a verifica nodurile din roiul nostru? Acesta a furnizat o grămadă de informații cu privire la fiecare nod, inclusiv a acestuia Disponibilitate . În mod implicit, nodurile sunt Activ , ceea ce înseamnă că sunt jocuri corecte pentru a rula containere. Cu toate acestea, există momente în care poate fi necesar să luați temporar un nod offline pentru a efectua întreținerea. Sigur, ai putea să-l închizi și roiul să-și revină, dar este plăcut să-i dai lui Moby (balena Docker) o notificare.

Aici intervin nodurile de scurgere. Când marcați un nod ca Scurgere , Docker Swarm va delega orice containere care rulează pe acesta către alte noduri și nu va porni niciun container pe nod până nu îi schimbați disponibilitatea înapoi la Activ .

Să presupunem că vrem să drenăm node1. Putem alerga:

docker node update --availability drain node1

Uşor! Când sunteți gata să o readuceți la lucru:

docker node update --availability active node1

Încheierea

După cum am văzut, Docker, împreună cu modul Swarm, ne permit să implementăm aplicații mai eficient și mai sigur decât oricând. Merită menționat faptul că Docker Swarm nu este în niciun caz singurul motor de orchestrare a containerelor care există. De fapt, este unul dintre cei mai tineri. Guvernatori a fost mai mult timp și este cu siguranță utilizat în mai multe aplicații de producție. Acestea fiind spuse, Swarm este cel dezvoltat oficial de Docker și lucrează pentru a adăuga și mai multe funcții în fiecare zi. Indiferent de care alegeți să utilizați, continuați să vă limitați!

Înțelegerea elementelor de bază

Ce este Docker Swarm?

Docker Swarm este un motor de orchestrare a containerelor. Ca atare, gestionează planificarea și echilibrarea containerelor între nodurile din clusterul dvs. într-un mod extrem de disponibil.

De ce ați folosi Docker Swarm?

În loc să vă gestionați infrastructura manual, Docker Swarm vă permite să specificați în mod declarativ modul în care aplicațiile dvs. ar trebui să fie implementate și scalate. Odată implementat, se va asigura că specificațiile dvs. sunt îndeplinite continuu.

Ce este nevoie pentru ca un Docker Swarm să ruleze?

Nu prea mult! Pur și simplu instalați Docker pe gazdele dvs. și solicitați ca unul dintre ele să inițializeze un roi. Odată ce ați terminat, celelalte gazde se pot alătura rapid.

Cum poate Docker Swarm să reducă diferența dintre dezvoltare și operațiuni?

Datorită stivelor Docker care utilizează aceeași sintaxă ca și docker-compose, dezvoltatorii dvs. vor fi făcut deja cea mai mare parte a activității de scriere a configurației stivei! Acest lucru înseamnă mai puține surprize când intrați în direct și este întotdeauna un lucru bun.