Vă sugerez să citiți transcrierea raportului lui Alexander Sigachev de la Inventos „Proces de dezvoltare și testare cu Docker + Gitlab CI”
Cei care abia încep să implementeze procesul de dezvoltare și testare bazat pe Docker + Gitlab CI pun adesea întrebări de bază. Unde sa încep? Cum se organizează? Cum se testează?
Acest raport este bun pentru că vorbește într-un mod structurat despre procesul de dezvoltare și testare folosind Docker și Gitlab CI. Raportul în sine este din 2017. Cred că din acest raport puteți aduna elementele de bază, metodologia, ideea și experiența de utilizare.
Pentru cei interesați, vă rugăm să vedeți cat.
Numele meu este Alexander Sigachev. Lucrez pentru Inventos. Vă voi spune despre experiența mea în utilizarea Docker și despre modul în care îl implementăm treptat pe proiectele din companie.
Subiectul raportului: Procesul de dezvoltare folosind Docker și Gitlab CI.
Aceasta este a doua mea discuție despre Docker. La momentul primului raport, am folosit Docker doar în dezvoltare pe mașinile dezvoltate. Numărul de angajați care au folosit Docker a fost de aproximativ 2-3 persoane. Treptat, s-a căpătat experiență și am mers puțin mai departe. Link către nostru .
Ce va fi în acest raport? Vom împărtăși experiența noastră despre ce greble am colectat, ce probleme am rezolvat. Nu a fost frumos peste tot, dar ne-a permis să mergem mai departe.
Motto-ul nostru: dockerizezi tot ceea ce punem mâna.
Ce probleme rezolvam?
Când o companie are mai multe echipe, programatorul este o resursă comună. Există etape în care un programator este scos dintr-un proiect și dat unui alt proiect pentru o perioadă de timp.
Pentru ca un programator să înțeleagă rapid, trebuie să descarce codul sursă al proiectului și să lanseze un mediu cât mai repede posibil, ceea ce îi va permite să avanseze în continuare în rezolvarea problemelor acestui proiect.
De obicei, dacă porniți de la zero, există puțină documentație în proiect. Doar cei mai vechi au informații despre cum să-l configureze. Angajații își instalează singuri locul de muncă în una sau două zile. Pentru a accelera acest lucru, am folosit Docker.
Următorul motiv este standardizarea setărilor în Dezvoltare. Din experiența mea, dezvoltatorii iau întotdeauna inițiativa. În fiecare al cincilea caz, este introdus un domeniu personalizat, de exemplu vasya.dev. Lângă mine se află vecinul meu Petya, al cărui domeniu este petya.dev. Ei dezvoltă un site web sau o componentă de sistem folosind acest nume de domeniu.
Când sistemul crește și aceste nume de domenii încep să fie incluse în configurație, apare un conflict în mediile de dezvoltare și calea site-ului este rescrisă.
Același lucru se întâmplă cu setările bazei de date. Unii oameni nu se deranjează cu securitatea și lucrează cu o parolă de rădăcină goală. În etapa de instalare, MySQL a cerut cuiva o parolă, iar parola s-a dovedit a fi 123. Se întâmplă adesea ca configurația bazei de date să se schimbe în mod constant în funcție de angajamentul dezvoltatorului. Cineva a corectat, cineva nu a corectat configurația. Au fost trucuri când am pus niște configurații de testare .gitignore iar fiecare dezvoltator trebuia să instaleze baza de date. Acest lucru a făcut procesul de pornire mai dificil. Printre altele, trebuie să vă amintiți despre baza de date. Baza de date trebuie inițializată, trebuie înregistrată o parolă, trebuie înregistrat un utilizator, trebuie creat un semn și așa mai departe.
O altă problemă o reprezintă versiunile diferite de biblioteci. Se întâmplă adesea ca un dezvoltator să lucreze la diferite proiecte. Există un proiect Legacy, care a început în urmă cu cinci ani (din 2017 - ND). La început am început cu MySQL 5.5. Există și proiecte moderne în care încercăm să implementăm versiuni mai moderne de MySQL, de exemplu 5.7 sau mai veche (în 2017 - nota editorului)
Oricine lucrează cu MySQL știe că aceste biblioteci au dependențe. Este destul de problematic să rulezi 2 baze de date împreună. Cel puțin, este problematic să conectați clienții vechi la noua bază de date. Aceasta, la rândul său, dă naștere la mai multe probleme.
Următoarea problemă este când un dezvoltator lucrează pe o mașină locală, el folosește resurse locale, fișiere locale, RAM locală. Toată interacțiunea la momentul dezvoltării unei soluții la probleme se realizează în cadrul faptului că funcționează pe o singură mașină. Un exemplu ar fi atunci când avem servere backend în Production 3, iar dezvoltatorul salvează fișierele în directorul rădăcină și de acolo nginx preia fișierele pentru a răspunde la cerere. Când un astfel de cod intră în producție, se dovedește că fișierul este prezent pe unul dintre cele 3 servere.
Direcția de microservicii se dezvoltă în prezent. Când împărțim aplicațiile noastre mari în câteva componente mici care interacționează între ele. Acest lucru vă permite să selectați tehnologii pentru un anumit grup de sarcini. Acest lucru vă permite, de asemenea, să împărțiți munca și zona de responsabilitate între dezvoltatori.
Un dezvoltator de front-end, care se dezvoltă în JS, nu are practic nicio influență asupra backend-ului. Dezvoltatorul backend, la rândul său, dezvoltă, în cazul nostru, Ruby on Rails și nu interferează cu Frondend. Interacțiunea se realizează folosind API-ul.
Ca bonus, folosind Docker am putut recicla resursele pe Staging. Fiecare proiect, datorită specificului său, necesita anumite setări. Din punct de vedere fizic, a fost necesar fie alocarea unui server virtual și configurarea acestora separat, fie împărțirea unor medii variabile, iar proiectele se puteau influența reciproc, în funcție de versiunea bibliotecilor.
Instrumente. Ce folosim?
- Docker în sine. Un Dockerfile descrie dependențele unei singure aplicații.
- Docker-compose este un pachet care reunește mai multe dintre aplicațiile noastre Docker.
- Folosim GitLab pentru a stoca codul sursă.
- Folosim GitLab-CI pentru integrarea sistemului.
Raportul constă din două părți.
Prima parte vă va spune cum să rulați Docker pe mașinile dezvoltatorilor.
Cea de-a doua parte va vorbi despre cum să interacționăm cu GitLab, despre cum rulăm teste și despre cum vom implementa în Staging.
Docker este o tehnologie care permite (folosind o abordare declarativă) să descrie componentele necesare. Acesta este un exemplu Dockerfile. Aici declarăm că moștenim din imaginea oficială Docker a lui Ruby:2.3.0. Conține versiunea Ruby 2.3 instalată. Instalăm bibliotecile de asamblare necesare și NodeJS. Descriem că creăm un director /app. Atribuim directorul aplicației ca director de lucru. În acest director plasăm minimul necesar Gemfile și Gemfile.lock. Apoi construim proiecte care instalează această imagine de dependență. Indicăm că containerul va fi gata să asculte pe portul extern 3000. Ultima comandă este comanda care lansează direct aplicația noastră. Dacă executăm comanda de rulare a proiectului, aplicația va încerca să ruleze și să ruleze comanda specificată.
Acesta este un exemplu minim de fișier docker-compose. În acest caz, arătăm că există o legătură între două containere. Acesta este direct în serviciul de bază de date și serviciul web. Aplicațiile noastre web necesită în majoritatea cazurilor un fel de bază de date ca backend pentru stocarea datelor. Deoarece folosim MySQL, exemplul este cu MySQL - dar nimic nu ne împiedică să folosim o altă bază de date (PostgreSQL, Redis).
Luăm imaginea MySQL 5.7.14 fără modificări din sursa oficială din hub-ul Docker. Colectăm imaginea care este responsabilă pentru aplicația noastră web din directorul curent. În timpul primei lansări, el adună o imagine pentru noi. Apoi rulează comanda pe care o executăm aici. Dacă ne întoarcem, vom vedea că comanda de lansare a fost definită prin Puma. Puma este un serviciu scris în Ruby. În al doilea caz, trecem peste. Această comandă poate fi arbitrară în funcție de nevoile sau sarcinile noastre.
De asemenea, descriem că trebuie să redirecționăm portul pe mașina noastră gazdă dezvoltator de la 3000 la 3000 porturi de containere. Acest lucru se face automat folosind iptables și propriul său mecanism, care este încorporat direct în Docker.
Dezvoltatorul poate, ca și înainte, să acceseze orice adresă IP disponibilă, de exemplu, 127.0.0.1 adresa IP locală sau externă a mașinii.
Ultima linie spune că containerul web depinde de containerul db. Când apelăm containerul web pentru lansare, docker-compose va lansa mai întâi baza de date pentru noi. Deja la pornirea bazei de date (de fapt, după lansarea containerului! Acest lucru nu garantează pregătirea bazei de date) va lansa aplicația noastră, backend-ul nostru.
Acest lucru ne permite să evităm erorile atunci când baza de date nu este activă și ne permite să economisim resurse atunci când oprim containerul bazei de date, eliberând astfel resurse pentru alte proiecte.
Ce ne oferă utilizarea dockerizării bazei de date într-un proiect? Înregistrăm versiunea MySQL pentru toți dezvoltatorii. Acest lucru vă permite să evitați unele erori care pot apărea atunci când versiunile diferă, când se schimbă sintaxa, configurația și setările implicite. Acest lucru vă permite să specificați un nume de gazdă comun pentru baza de date, autentificare, parolă. Ne îndepărtăm de grădina zoologică a numelor și a conflictelor în fișierele de configurare care existau înainte.
Avem posibilitatea de a folosi o configurație mai optimă pentru mediul de dezvoltare, care va diferi de cea implicită. MySQL este configurat implicit pentru mașinile slabe, iar performanța sa din cutie este foarte scăzută.
Docker vă permite să utilizați interpretul Python, Ruby, NodeJS, PHP al versiunii dorite. Scăpăm de necesitatea de a folosi un fel de manager de versiuni. Anterior, pentru Ruby era folosit un pachet rpm, care permitea să schimbi versiunea în funcție de proiect. Datorită containerului Docker, acest lucru vă permite, de asemenea, să migrați fără probleme codul și să îl versați împreună cu dependențele. Nu avem nicio problemă să înțelegem versiunea atât a interpretului, cât și a codului. Pentru a actualiza versiunea, trebuie să coborâți vechiul container și să ridicați noul container. Dacă ceva nu merge bine, putem coborî noul container, putem ridica containerul vechi.
După construirea imaginii, containerele atât în dezvoltare, cât și în producție vor fi aceleași. Acest lucru este valabil mai ales pentru instalațiile mari.
Pe Frontend folosim JavaScipt și NodeJS.
Acum avem ultimul nostru proiect pe ReacJS. Dezvoltatorul a lansat totul în container și a dezvoltat folosind reîncărcarea la cald.
În continuare, este lansată sarcina de a asambla JavaScipt și codul asamblat static este trimis prin nginx, economisind resurse.
Aici am oferit o diagramă a celui mai recent proiect al nostru.
Ce probleme ai rezolvat? Aveam nevoie să construim un sistem cu care dispozitivele mobile interacționează. Ei primesc date. Una dintre posibilități este să trimiți notificări push către acest dispozitiv.
Ce am făcut pentru asta?
Am împărțit aplicația în următoarele componente: o parte admin în JS, un backend care funcționează printr-o interfață REST sub Ruby on Rails. Backend-ul interacționează cu baza de date. Rezultatul care este generat este dat clientului. Panoul de administrare interacționează cu backend-ul și baza de date printr-o interfață REST.
De asemenea, am avut nevoie să trimitem notificări Push. Înainte de aceasta, am avut un proiect în care a fost implementat un mecanism care era responsabil cu livrarea notificărilor către platformele mobile.
Am dezvoltat următoarea schemă: operatorul din browser interacționează cu panoul de administrare, panoul de administrare interacționează cu backend-ul, sarcina este să trimită notificări Push.
Notificările push interacționează cu o altă componentă care este implementată în NodeJS.
Cozile sunt construite și notificările sunt trimise conform propriului mecanism.
Două baze de date sunt desenate aici. În prezent, folosind Docker, folosim 2 baze de date independente care nu sunt în niciun fel conectate între ele. Pe lângă faptul că au o rețea virtuală comună, iar datele fizice sunt stocate în directoare diferite pe mașina dezvoltatorului.
Același lucru, dar în cifre. Reutilizarea codului este importantă aici.
Dacă mai devreme am vorbit despre reutilizarea codului sub formă de biblioteci, atunci în acest exemplu serviciul nostru, care răspunde la notificările Push, este reutilizat ca un server complet. Oferă un API. Și noua noastră dezvoltare interacționează cu ea.
La acea vreme folosim versiunea 4 a NodeJS. Acum (în 2017 - nota editorului) în cele mai recente evoluții, folosim versiunea 7 a NodeJS. Nu există nicio problemă în componentele noi pentru a implica versiuni noi de biblioteci.
Dacă este necesar, puteți refactoriza și ridica versiunea NodeJS a serviciului de notificare Push.
Și dacă putem menține compatibilitatea API, atunci va fi posibil să o înlocuim cu alte proiecte care au fost folosite anterior.
De ce aveți nevoie pentru a adăuga Docker? Adăugăm un Dockerfile în depozitul nostru, care descrie dependențele necesare. În acest exemplu, componentele sunt împărțite logic. Acesta este kitul minim pentru un dezvoltator backend.
Când creăm un nou proiect, creăm un Dockerfile și descriem ecosistemul necesar (Python, Ruby, NodeJS). În docker-compose, descrie dependența necesară - baza de date. Descriem că avem nevoie de o bază de date cu o astfel de versiune, pentru a stoca date acolo și acolo.
Folosim un al treilea container separat cu nginx pentru a servi conținut static. Este posibil să încărcați poze. Backend-ul le pune într-un volum pregătit în prealabil, care este, de asemenea, montat într-un container cu nginx, care oferă date statice.
Pentru a stoca configurația nginx și mysql, am adăugat un folder Docker în care stocăm configurațiile necesare. Când un dezvoltator face o clonă git a unui depozit pe mașina sa, el are deja un proiect pregătit pentru dezvoltare locală. Nu există nicio întrebare despre ce port sau ce setări să aplici.
În continuare avem mai multe componente: admin, info-API, notificări push.
Pentru a lansa toate acestea, am creat un alt depozit numit dockerized-app. În prezent, folosim mai multe depozite pentru fiecare componentă. Sunt pur și simplu diferite din punct de vedere logic - în GitLab arată ca un folder, dar pe computerul dezvoltatorului arată ca un folder pentru un anumit proiect. Un nivel mai jos sunt componentele care vor fi combinate.
Acesta este un exemplu de conținut al aplicației dockerized. De asemenea, plasăm aici un director Docker, în care completăm configurațiile necesare pentru interacțiunile tuturor componentelor. Există un README.md care descrie pe scurt modul de lansare a proiectului.
Aici am aplicat două fișiere docker-compose. Acest lucru se face pentru a putea lansa în etape. Când un dezvoltator lucrează cu nucleul, nu are nevoie de notificări Push, pur și simplu lansează fișierul docker-compose și, în consecință, resursele sunt salvate.
Dacă este nevoie de integrare cu notificările Push, atunci sunt lansate docker-compose.yaml și docker-compose-push.yaml.
Deoarece docker-compose.yaml și docker-compose-push.yaml se află în folder, o singură rețea virtuală este creată automat.
Descrierea componentelor. Acesta este un fișier mai avansat care este responsabil pentru colectarea componentelor. Ce este remarcabil aici? Aici introducem componenta de echilibrare.
Aceasta este o imagine Docker gata făcută care rulează nginx și o aplicație care ascultă socket-ul Docker. Dinamic, pe măsură ce containerele sunt pornite și oprite, configurația nginx este regenerată. Distribuim manipularea componentelor folosind nume de domenii de nivel al treilea.
Pentru mediul de dezvoltare folosim domeniul .dev - api.informer.dev. Aplicațiile cu un domeniu .dev sunt disponibile pe computerul local al dezvoltatorului.
Apoi, configurațiile sunt transferate la fiecare proiect și toate proiectele sunt lansate împreună în același timp.
Dacă îl înfățișăm grafic, se dovedește că clientul este browserul nostru sau un fel de instrument cu care facem solicitări către echilibrant.
Echilibratorul determină ce container trebuie accesat pe baza numelui de domeniu.
Acesta ar putea fi nginx, care oferă JS panoului de administrare. Acest lucru poate fi realizat de nginx, care furnizează API-ul, sau fișiere statice, care sunt furnizate de nginx sub formă de încărcare a imaginilor.
Diagrama arată că containerele sunt conectate la o rețea virtuală și ascunse în spatele unui proxy.
Pe mașina dezvoltatorului, puteți accesa containerul știind IP-ul, dar în principiu nu folosim acest lucru. Practic nu este nevoie de contact direct.
Ce exemplu ar trebui să mă uit pentru a dockeriza aplicația mea? După părerea mea, un exemplu bun este imaginea oficială docker pentru MySQL.
Este destul de complicat. Sunt multe versiuni. Dar funcționalitatea sa vă permite să acoperiți multe nevoi care pot apărea în procesul de dezvoltare ulterioară. Dacă îți iei timp și înțelegi cum interacționează totul, atunci cred că nu vei avea nicio problemă să-l implementezi singur.
Hub.docker.com conține de obicei link-uri către github.com, unde sunt furnizate date brute direct din care puteți construi singur o imagine.
Mai departe, în acest depozit există un script docker-endpoint.sh, care este responsabil pentru inițializarea inițială și procesarea ulterioară a lansării aplicației.
Tot in acest exemplu exista posibilitatea configurarii folosind variabile de mediu. Prin definirea unei variabile de mediu atunci când rulăm un singur container sau prin docker-compose, putem spune că trebuie să setăm o parolă goală pentru docker pentru root pe MySQL sau orice vrem.
Există o opțiune pentru a crea o parolă aleatorie. Spunem că avem nevoie de un utilizator, trebuie să setăm o parolă pentru utilizator și trebuie să creăm o bază de date.
În proiectele noastre, am unificat ușor Dockerfile, care este responsabil pentru inițializare. Acolo l-am ajustat la nevoile noastre pentru a extinde pur și simplu drepturile de utilizator pe care le folosește aplicația. Acest lucru a făcut posibilă crearea unei baze de date din consola aplicației în viitor. Aplicațiile Ruby au comenzi pentru crearea, modificarea și ștergerea bazelor de date.
Acesta este un exemplu despre cum arată o anumită versiune de MySQL pe github.com. Puteți deschide fișierul Docker și vedeți cum are loc instalarea acolo.
Scriptul docker-endpoint.sh responsabil pentru punctul de intrare. În timpul inițializării inițiale, sunt necesare unele acțiuni de pregătire și toate aceste acțiuni sunt incluse în scriptul de inițializare.
Să trecem la partea a doua.
Am trecut la gitlab pentru a stoca codurile sursă. Acesta este un sistem destul de puternic, care are o interfață vizuală.
Una dintre componentele Gitlab este Gitlab CI. Vă permite să descrieți o serie de comenzi care vor fi utilizate ulterior pentru a organiza un sistem de livrare a codului sau pentru a rula testarea automată.
Raport despre Gitlab CI 2 — raportul de la clubul Ruby Russia este destul de detaliat și poate fi de interes pentru tine.
Acum ne vom uita la ceea ce este necesar pentru a activa Gitlab CI. Pentru a lansa Gitlab CI, trebuie doar să punem fișierul .gitlab-ci.yml în rădăcina proiectului.
Aici descriem că dorim să realizăm o secvență de stări precum test, implementare.
Executăm scripturi care apelează direct versiunea docker-compose a aplicației noastre. Acesta este un exemplu de backend.
În continuare spunem că este necesar să rulăm migrații pentru a schimba baza de date și a rula teste.
Dacă scripturile sunt executate corect și nu returnează un cod de eroare, atunci sistemul trece la a doua etapă de implementare.
Etapa de implementare este în prezent implementată pentru staging. Nu am organizat o repornire fără întreruperi.
Stingem forțat toate containerele și apoi ridicăm din nou toate containerele, colectate în prima etapă în timpul testării.
Să rulăm migrațiile bazei de date care au fost scrise de dezvoltatori pentru mediul variabil curent.
Există o notă că acest lucru ar trebui aplicat numai ramurii principale.
Nu funcționează la schimbarea altor ramuri.
Este posibil să se organizeze lansări de-a lungul ramurilor.
Pentru a organiza acest lucru în continuare, trebuie să instalăm Gitlab Runner.
Acest utilitar este scris în Golang. Este un singur fișier, așa cum este obișnuit în lumea Golang, care nu necesită dependențe.
La pornire, înregistrăm Gitlab Runner.
Primim cheia în interfața web Gitlab.
Apoi apelăm comanda de inițializare pe linia de comandă.
Configurarea Gitlab Runner în modul de dialog (Shell, Docker, VirtualBox, SSH)
Codul de pe Gitlab Runner se va executa la fiecare commit, în funcție de setarea .gitlab-ci.yml.
Cum arată vizual în Gitlab în interfața web. După conectarea GItlab CI, avem un steag care arată în ce stare se află construcția în acest moment.
Vedem că acum 4 minute s-a făcut un commit care a trecut toate testele și nu a creat probleme.
Putem privi versiunile mai detaliat. Aici vedem că două state au trecut deja. Starea de testare și starea de implementare la staging.
Dacă facem clic pe o anumită versiune, va apărea consolă comenzile care au fost lansate în proces conform .gitlab-ci.yml.
Așa arată povestea produsului nostru. Vedem că au fost încercări reușite. Când testele sunt depuse, acestea nu trec la pasul următor și codul de staging nu este actualizat.
Ce probleme am rezolvat în staging când am implementat docker? Sistemul nostru este format din componente și a trebuit să repornim doar câteva dintre componentele care au fost actualizate în depozit, și nu întregul sistem.
Pentru a face acest lucru, a trebuit să separăm totul în foldere separate.
După ce am făcut asta, am avut o problemă cu faptul că Docker-compose își creează propriul spațiu de rețea pentru fiecare folder și nu vede componentele vecinului său.
Pentru a deplasa, am creat rețeaua manual în Docker. În Docker-compose a fost scris că ar trebui să utilizați o astfel de rețea pentru acest proiect.
Astfel, fiecare componentă care începe cu această plasă vede componente în alte părți ale sistemului.
Următoarea problemă este împărțirea montajului între mai multe proiecte.
Deoarece pentru ca toate acestea să arate frumos și cât mai aproape de producție, este bine să folosiți portul 80 sau 443, care este folosit peste tot în WEB.
Cum am rezolvat asta? Am atribuit un Gitlab Runner tuturor proiectelor mari.
Gitlab vă permite să lansați mai multe Gitlab Runners distribuite, care pur și simplu vor prelua toate sarcinile una câte una într-o ordine haotică și le vor rula.
Pentru a evita problemele casei, am limitat grupul proiectelor noastre la un singur Gitlab Runner, care se descurcă fără probleme cu volumele noastre.
Am mutat nginx-proxy într-un script de lansare separat și am scris grilele tuturor proiectelor din acesta.
Proiectul nostru are o singură grilă, iar echilibrerul are mai multe grile bazate pe numele proiectelor. Poate proxy în continuare prin nume de domenii.
Solicitările noastre vin prin domeniul de pe portul 80 și sunt rezolvate la un grup de containere care deservește acest domeniu.
Ce alte probleme au mai fost? Acesta este ceea ce toate containerele rulează implicit ca root. Aceasta este gazda rădăcină inegală a sistemului.
Cu toate acestea, dacă introduceți containerul, acesta va fi root și fișierul pe care îl creăm în acest container primește drepturi de root.
Dacă un dezvoltator a intrat în container și a făcut acolo niște comenzi care au generat fișiere, apoi a părăsit containerul, atunci în directorul său de lucru are un fișier la care nu are acces.
Cum poate fi rezolvat acest lucru? Puteți adăuga utilizatori care vor fi în container.
Ce probleme au apărut când am adăugat utilizatorul?
La crearea unui utilizator, ID-ul grupului (UID) și ID-ul utilizatorului (GID) adesea nu se potrivesc.
Pentru a rezolva această problemă în container folosim utilizatori cu ID 1000.
În cazul nostru, acest lucru a coincis cu faptul că aproape toți dezvoltatorii folosesc Ubuntu OS. Și în sistemul de operare Ubuntu, primul utilizator are ID 1000.
Avem planuri?
Recitiți documentația Docker. Proiectul se dezvoltă activ, documentația se schimbă. Datele care au fost obținute în urmă cu două sau trei luni devin treptat depășite.
Este posibil ca unele dintre problemele pe care le-am rezolvat să fi fost deja rezolvate prin mijloace standard.
Îmi doresc foarte mult să merg mai departe și să trec direct la orchestrație.
Un exemplu este mecanismul încorporat al lui Docker numit Docker Swarm, care iese din cutie. Aș dori să lansez ceva în producție bazat pe tehnologia Docker Swarm.
Containerele de depunere a icrelor fac lucrul cu bușteni incomod. Acum buștenii sunt izolați. Sunt împrăștiate în recipiente. Una dintre sarcini este de a face acces comod la jurnalele printr-o interfață web.
Sursa: www.habr.com