Vă invit să consultați transcrierea raportului lui Alexander Sigachev de la Inventos „Procesul de dezvoltare și testare cu Docker + Gitlab CI”
Cei care încep să implementeze procesul de dezvoltare și testare bazat pe Docker + Gitlab CI adesea pun întrebări de bază. Cu ce să încep? Cum să organizăm? Cum să testăm?
Acest raport este valoros deoarece explică structurat procesul de dezvoltare și testare folosind Docker și Gitlab CI. Raportul este din 2017. Cred că din acest raport se pot extrage fundamentele, metodologia, ideea, experiența utilizării.
Cine este interesat, vă rog să citiți mai departe.
Numele meu este Alexander Sigachev. Lucrez la compania Inventos. Voi împărtăși experiența mea cu Docker și modul în care îl implementăm treptat în proiectele companiei.
Tema raportului: Procesul de dezvoltare cu utilizarea Docker și Gitlab CI.
Acesta este al doilea meu raport despre Docker. La momentul primului raport, foloseam Docker doar în dezvoltare pe mașinile dezvoltatorilor. Numărul angajaților care foloseau Docker era de aproximativ 2-3 persoane. Treptat, am acumulat experiență și am avansat puțin mai departe. Linkul către raportul nostru .
Ce va conține acest raport? Vom împărtăși experiența noastră despre obstacolele întâmpinate, ce probleme am rezolvat și cum. Nu a fost întotdeauna ușor, dar ne-a permis să avansăm.
Deviza noastră: dockerizează tot ce poate ajunge în mâinile noastre.
Ce probleme rezolvăm?
Când în companie sunt mai multe echipe, programatorul devine o resursă comună. Există etape în care programatorii sunt deturnați dintr-un proiect și alocați pe o vreme în alt proiect.
Pentru ca programatorul să se integreze rapid, este necesar să descarce codul sursă al proiectului și să pornească mediul cât mai repede, ceea ce îi va permite să continue să rezolve sarcinile acestui proiect.
De obicei, dacă începi de la zero, există puțină documentație în proiect. Informațiile despre cum să configurezi, sunt doar la cei experimentați. Angajații își configurează locul de muncă de obicei în una sau două zile. Pentru a accelera acest proces, am aplicat Docker.
Următoarea problemă este standardizarea setărilor în Development. Din experiența mea, dezvoltatorii manifestă întotdeauna inițiativă. În fiecare a cincea situație, se introduce un domeniu personalizat, de exemplu vasya.dev. În apropiere se află vecinul Petya, care are domeniul petya.dev. Ei dezvoltă un site sau un component al sistemului folosind acest nume de domeniu.
Când sistemul crește și aceste nume de domeniu încep să apară în configurații, apare un conflict al mediilor de Development și se rescrie calea site-ului.
Același lucru se întâmplă și cu setările bazei de date. Cineva nu se îngrijorează de securitate și lucrează cu parola root goală. La cineva, în timpul instalării, MySQL a cerut o parolă și aceasta a fost 123. Se întâmplă adesea ca configurarea bazei de date să fie constant modificată în funcție de commit-ul dezvoltatorului. Cineva a corectat, cineva nu a corectat configurația. Au fost metode ingenioase când am mutat o configurație de test în .gitignore și fiecare dezvoltator trebuia să instaleze baza de date. Aceasta complica procesul de început. Pe lângă toate acestea, trebuie să ne amintim și de baza de date. Baza de date trebuie inițializată, trebuie să specificăm parola, trebuie să specificăm utilizatorul, să creăm tabela și așa mai departe.
Încă una dintre probleme este versiunile diferite ale bibliotecilor. Adesea, dezvoltatorul lucrează cu proiecte diferite. Există un proiect Legacy, care a început acum cinci ani (din 2017 – nota editorului). La început, a fost început cu MySQL 5.5. Există și proiecte moderne, unde încercăm să implementăm deja versiuni mai moderne de MySQL, de exemplu 5.7 sau mai mari (în 2017 – nota editorului)
Cine lucrează cu MySQL știe că aceste biblioteci aduc cu ele dependențe. Este destul de problematic să rulați două baze împreună. Cel puțin, conectarea clienților vechi la o nouă bază de date este problematică. Acest lucru generează, la rândul său, mai multe probleme.
Următoarea problemă este atunci când dezvoltatorul lucrează pe o mașină locală, utilizând resurse locale, fișiere locale, memorie RAM locală. Toate interacțiunile în timpul dezvoltării soluțiilor sunt realizate în contextul în care funcționează pe o singură mașină. Un exemplu ar fi atunci când avem 3 servere backend în producție, iar dezvoltatorul salvează fișiere în directorul rădăcină, de unde nginx își ia fișierele pentru a răspunde la cereri. Când acest cod ajunge în producție, se constată că fișierul este prezent pe unul dintre cele 3 servere.
Acum se dezvoltă direcția microserviciilor. Când împărțim aplicațiile noastre mari în componente mici, care interacționează între ele. Aceasta permite alegerea tehnologiilor specifice pentru stiva de sarcini. De asemenea, permite împărțirea muncii și a responsabilităților între dezvoltatori.
Dezvoltatorul frontend, dezvoltând pe JS, nu influențează aproape deloc backend-ul. Dezvoltatorul backend, în cazul nostru, dezvoltă Ruby on Rails și nu interferează cu frontend-ul. Interacțiunea se realizează prin intermediul API-ului.
Ca bonus, cu ajutorul Docker am reușit să utilizăm resursele pe Staging. Fiecare proiect, datorită specificului său, necesita anumite setări. Fizic, era necesar să alocăm fie un server virtual pentru fiecare și să le configurăm separat, fie să împărțim un mediu variabil, iar proiectele puteau influența unul pe altul în funcție de versiunile bibliotecilor.
Instrumente. Ce folosim?
- Direct Docker. În Dockerfile sunt descrise dependențele unei aplicații.
- Docker-compose este legătura care reunește câteva dintre aplicațiile noastre Docker.
- Folosim GitLab pentru stocarea codului sursă.
- Folosim GitLab-CI pentru integrarea sistemică.
Prezentarea constă în două părți.
Prima parte va vorbi despre cum am pornit Docker pe mașinile dezvoltatorilor.
Partea a doua va discuta despre cum interacționăm cu GitLab, cum rulăm testele și cum facem implementarea pe Staging.
Docker este o tehnologie care permite (folosind o abordare declarativă) descrierea componentelor necesare. Acesta este un exemplu de Dockerfile. Aici declarăm că ne derivăm din imaginea oficială Docker Ruby:2.3.0. Aceasta conține Ruby versiunea 2.3. Instalăm bibliotecile necesare pentru compilare și NodeJS. Declarăm că creăm un director. /appStabilim directorul app ca director de lucru. În acest director plasăm Gemfile și Gemfile.lock necesare. Apoi, executăm construcția proiectelor care instalează această imagine a dependențelor. Indică că containerul va fi pregătit să asculte pe portul extern 3000. Ultima comandă este cea care pornește efectiv aplicația noastră. Dacă executăm comanda de lansare a proiectului, aplicația va încerca să se execute și va porni comanda specificată.
Acesta este un exemplu minim al unui fișier docker-compose. În acest caz, arătăm cum se realizează conexiunea între două containere. Acesta este serviciul de bază de date și serviciul web. Aplicațiile noastre web necesită, în cele mai multe cazuri, un backend pentru stocarea datelor, adică o bază de date. Deoarece utilizăm MySQL, exemplul este cu MySQL - dar nimic nu ne împiedică să folosim o altă bază de date (PostgreSQL, Redis).
Luăm de la sursa oficială de pe Docker Hub imaginea MySQL 5.7.14 fără modificări. Imaginea care răspunde de aplicația noastră web o construim din directorul curent. La prima execuție, construiește imaginea pentru noi. Apoi, pornește comanda pe care o executăm aici. Dacă ne întoarcem, vom vedea că a fost definită o comandă de lansare prin Puma. Puma este un serviciu scris în Ruby. În al doilea caz, o redefinim. Această comandă poate fi orice, în funcție de nevoile sau sarcinile noastre.
De asemenea, descriem că trebuie să redirecționăm portul de pe mașina gazdă a dezvoltatorului de la 3000 la portul 3000 al containerului. Aceasta se realizează automat cu ajutorul iptables și al mecanismului său, care este integrat direct în Docker.
Dezvoltatorul poate, de asemenea, ca și înainte, să se conecteze la orice adresă IP disponibilă, de exemplu, 127.0.0.1 (local) sau adresa IP externă a mașinii.
Ultima linie spune că containerul web depinde de containerul db. Când apelăm lansarea containerului web, docker-compose va porni mai întâi baza de date. La lansarea bazei de date (de fapt - după startul containerului! Nu garantează disponibilitatea Bazei de Date), ne va porni aplicația, backend-ul nostru.
Acest lucru permite evitarea erorilor atunci când baza de date nu este activată și ajută la economisirea resurselor atunci când oprim containerul bazei de date, eliberând resursele pentru alte proiecte.
Ce ne oferă utilizarea containerizării bazei de date în proiect? La toți dezvoltatorii fixăm versiunea MySQL. Aceasta permite evitarea unor erori care pot apărea din cauza discrepanțelor între versiuni, când se schimbă sintaxa, configurația sau setările implicite. Permite specificarea unor hostname-uri comune pentru baza de date, login, parolă. Ne îndepărtăm de haosul numelui și conflictele din fișierele de configurare anterioare.
Avem posibilitatea de a folosi un config mai optim pentru mediu de dezvoltare, care va diferi de cel implicit. MySQL este configurat din oficiu pentru mașini slabe, iar performanța sa din cutie este foarte scăzută.
Docker permite utilizarea interpretatoarelor Python, Ruby, NodeJS, PHP de versiune necesară. Ne eliberăm de necesitatea unui manager de versiuni. În trecut, pentru Ruby foloseam un pachet rpm care ne permitea să schimbăm versiunea în funcție de proiect. De asemenea, aceasta permite, datorită containerului Docker, să migrăm codul și să-l versiunez împreună cu dependențele sale. Nu avem probleme în a identifica versiunea atât a interpretatorului, cât și a codului. Pentru a actualiza versiunea, trebuie să reducem containerul vechi și să ridicăm un nou container. Dacă ceva nu merge bine, putem reduce noul container și să ridicăm containerul vechi.
După construirea imaginii, containerele atât în mediu de dezvoltare, cât și în producție vor fi identice. Acest lucru este deosebit de relevant pentru instalările mari.
Pe frontend folosim JavaScript și NodeJS.
Acum, ultimul nostru proiect este pe ReactJS. Dezvoltatorul a lansat toate containerele și a dezvoltat folosind hot-reload.
Apoi se lansează o sarcină de construire JavaScript, iar codul compilat în statics este livrat prin nginx, economisind resurse.
Aici am prezentat schema ultimului nostru proiect.
Ce probleme am rezolvat? A existat necesitatea de a construi un sistem care interacționează cu dispozitive mobile. Acestea primesc date. Una dintre posibilitățile este de a trimite notificări push către acest dispozitiv.
Ce am făcut pentru asta?
Am împărțit aplicația în următoarele componente: partea de admin pe JS, backend-ul care funcționează printr-un API REST sub Ruby on Rails. Backend-ul interacționează cu baza de date. Rezultatul generat este livrat clientului. Admin panel-ul interacționează cu backend-ul și baza de date prin intermediul API-ului REST.
De asemenea, am avut nevoie să trimitem notificări Push. Până acum, am avut un proiect în care a fost implementat un mecanism care se ocupă de livrarea notificărilor pe platformele mobile.
Am dezvoltat un astfel de sistem: operatorul din browser interacționează cu panoul de administrare, iar panoul de administrare interacționează cu backend-ul, stabilind sarcina de a trimite notificările Push.
Notificările Push interacționează cu un alt component, care este implementat pe NodeJS.
Se construiesc cozi și apoi se continuă cu mecanismul propriu de trimitere a notificărilor.
Aici sunt reprezentate două baze de date. În prezent, folosim 2 baze de date independente, care nu sunt legate între ele, cu ajutorul Docker. Singura lor conexiune este rețeaua virtuală comună, iar datele fizice sunt stocate în directoare diferite pe mașina dezvoltatorului.
Același lucru, dar în cifre. Aici este importantă reutilizarea codului.
Dacă anterior discutam despre reutilizarea codului sub formă de biblioteci, în acest exemplu, serviciul nostru care se ocupă de notificările Push este reutilizat ca un server complet. Oferă un API, iar noua noastră dezvoltare interacționează cu acesta.
Pe atunci, foloseam versiunea 4 de NodeJS. Acum (în 2017 — n. red.) în dezvoltările recente, folosim versiunea 7 de NodeJS. Nu avem probleme în a aduce noi versiuni de biblioteci în noile componente.
Dacă este necesar, se poate realiza un refactoring și actualizară versiunea NodeJS a serviciului de notificări Push.
Dacă putem menține compatibilitatea API-ului, atunci este posibil să îl înlocuim în alte proiecte care au fost utilizate anterior.
Ce este necesar pentru a adăuga Docker? Adăugăm în depozitul nostru un Dockerfile, care descrie dependențele necesare. În acest exemplu, componentele sunt împărțite logic. Acesta este minimul necesar pentru un dezvoltator backend.
Când creăm un nou proiect, creăm un Dockerfile, descriem ecosistemul necesar (Python, Ruby, NodeJS). În docker-compose descriem dependența necesară — baza de date. Specificăm că este nevoie de o bază de date de o anumită versiune, pentru a stoca datele într-un anumit loc.
Folosim un container separat cu nginx pentru livrarea fișierelor statice. Este prevăzută posibilitatea de a încărca imagini. Backend-ul le plasează într-un volum pregătit în prealabil, care este montat și în containerul cu nginx, care servește fișierele statice.
Pentru a stoca configurația nginx, mysql, am adăugat un folder Docker în care păstrăm configurațiile necesare. Când dezvoltatorul face git clone al repository-ului pe mașina sa, obține un proiect deja pregătit pentru dezvoltarea locală. Nu există întrebări despre ce port sau ce setări trebuie aplicate.
Apoi avem câteva componente: admin, inform-API, notificări push.
Pentru a lansa tot acest lucru, am creat un alt repository numit dockerized-app. În prezent, folosim mai multe repository-uri pentru fiecare componentă. Acestea sunt doar diferite logic - în GitLab arată ca un folder, iar pe mașina dezvoltatorului, un folder pentru proiectul specific. La un nivel inferior se află componentele care vor fi unite.
Acesta este un exemplu exact al conținutului dockerized-app. De asemenea, scoatem aici catalogul Docker, în care umplem configurațiile necesare pentru interacțiunile tuturor componentelor. Există README.md, în care este descris succint cum se lansează proiectul.
Aici am aplicat două fișiere docker-compose. Acest lucru a fost realizat pentru a putea lansa aplicațiile în etape. Când dezvoltatorul lucrează cu nucleul, nu are nevoie de notificări push, așa că pornește pur și simplu fișierul docker-compose și, în consecință, resursele sunt economisite.
Dacă este necesară integrarea cu notificările push, atunci se lansează docker-compose.yaml și docker-compose-push.yaml.
Deoarece docker-compose.yaml și docker-compose-push.yaml se află în folder, se creează automat o rețea virtuală unificată.
Descrierea componentelor. Acesta este un fișier mai extins, care este responsabil pentru compilarea componentelor. Ce este notabil aici? Introducem componenta load balancer.
Acesta este un container Docker gata, în care rulează nginx și aplicația care ascultă socket-ul Docker. Configurația nginx este regenerată dinamic, pe măsură ce containerele sunt pornite și oprite. Interacțiunile cu componentele sunt dispersate prin numele de domeniu de nivel trei.
Pentru mediul de dezvoltare, folosim domeniul .dev — api.informer.dev. Aplicațiile cu domeniul .dev sunt disponibile pe mașina locală a dezvoltatorului.
Apoi, configurațiile sunt transferate pentru fiecare proiect și toate proiectele sunt lansate simultan.
Dacă ar fi să reprezentăm grafic, clientul ar fi browserul nostru sau un instrument cu care facem cereri către load balancer.
Load balancer-ul determină, prin numele de domeniu, la care container trebuie să se adreseze.
Acesta poate fi nginx care oferă JS pentru interfața de administrare. Poate fi nginx care oferă API-ul sau fișiere statice care sunt livrate de nginx sub formă de încărcare a imaginilor.
În diagramă se vede că containerele sunt unite într-o rețea virtuală și ascunse în spatele unui proxy.
Pe mașina dezvoltatorului, se poate accesa containerul știind IP-ul, dar practic nu aplicăm asta. Necesitatea de a accesa direct este aproape inexistentă.
Ce exemplu să consult pentru a dockeriza aplicația mea? Părerea mea este că un exemplu bun este imaginea oficială docker pentru MySQL.
Este destul de complex. Există multe versiuni. Dar funcționalitatea sa permite acoperirea multor nevoi care pot apărea în timpul dezvoltării ulterioare. Dacă îți vei petrece timpul și vei înțelege cum interacționează toate acestea, cred că nu vei avea probleme în implementarea independentă.
Pe hub.docker.com există de obicei linkuri către github.com, unde sunt prezentate datele brute, din care poți crea tu însuți imaginea.
Mai departe, în acest depozit se află scriptul docker-endpoint.sh, care răspunde de inițializarea inițială și de procesarea ulterioară a lansării aplicației.
De asemenea, în acest exemplu există posibilitatea de configurare folosind variabile de mediu. Definind variabilele de mediu la lansarea unui singur container sau prin docker-compose, putem specifica că trebuie să setăm o parolă goală pentru docker pentru root pe MySQL sau una pe care o dorim.
Există opțiunea de a crea o parolă randomizată. Spunem că avem nevoie de un utilizator, este necesar să setăm o parolă pentru utilizator și trebuie să creăm o bază de date.
În proiectele noastre, am unificat puțin Dockerfile-ul, care răspunde de inițializare. L-am modificat pentru nevoile noastre pentru a extinde pur și simplu drepturile utilizatorului pe care îl folosește aplicația. Acest lucru a permis ulterior crearea simplă a unei baze de date din consola aplicației. În aplicațiile Ruby există comenzi pentru a crea, modifica și șterge baze de date.
Acesta este un exemplu despre cum arată o versiune specifică de MySQL pe github.com. Dockerfile-ul poate fi deschis și poți vedea cum se desfășoară instalarea.
docker-endpoint.sh este un script care răspunde pentru punctul de intrare. La inițializarea inițială, sunt necesare anumite acțiuni de pregătire, iar toate aceste acțiuni sunt incluse în scriptul de inițializare.
Trecem la a doua parte.
Pentru stocarea codului sursă, am trecut la GitLab. Este un sistem destul de puternic, care are o interfață vizuală.
Unul dintre componentele GitLab este GitLab CI. Acesta permite descrierea unei secvențe de comenzi, care vor fi folosite ulterior pentru a organiza livrarea codului sau pentru a rula teste automate.
Prezentare despre GitLab CI 2 — o prezentare de la Ruby Russia club — destul de detaliată și poate că va fi de interes pentru tine.
Acum vom discuta despre ce este necesar pentru a activa GitLab CI. Pentru a porni GitLab CI, trebuie doar să plasăm fișierul .gitlab-ci.yml în rădăcina proiectului.
Aici descriem ce dorim să executăm ca o secvență de stări de tip testare, livrare.
Executăm scripturile, care apelază direct compilarea aplicației noastre cu docker-compose. Acesta este un exemplu de backend.
Apoi, menționăm că trebuie să rulăm migrațiile pentru modificarea bazei de date și să executăm testele.
Dacă scripturile sunt executate corect și nu returnează un cod de eroare, atunci sistemul trece la a doua etapă a livrării.
Etapa de livrare este în prezent implementată pentru staging. Nu am organizat o repornire fără întrerupere.
Forțăm oprirea tuturor containerelor și apoi ridicăm din nou toate containerele, construite în prima etapă în timpul testării.
Rulăm migrațiile bazei de date pentru mediu variabil actual, care au fost scrise de dezvoltatori.
Există o notă că acest lucru ar trebui aplicat doar pentru ramura master.
Schimbările în alte ramuri nu sunt executate.
Există posibilitatea de a organiza livrări pe ramuri.
Pentru a organiza mai departe acest lucru, trebuie să instalăm GitLab Runner.
Aceasta este o unealtă scrisă în Golang. Este un singur fișier, așa cum este obișnuit în lumea Golang, care nu necesită alte dependențe.
La pornire, înregistrăm GitLab Runner.
Obținem în interfața web GitLab cheia.
Apoi apelăm comanda de inițializare în linia de comandă.
Configurăm GitLab Runner în modul de dialog (Shell, Docker, VirtualBox, SSH).
Codul pe GitLab Runner va fi executat la fiecare commit în funcție de configurarea .gitlab-ci.yml.
Cum arată vizual în Gitlab în interfața web. După ce am conectat Gitlab CI, ne apare un indicator care arată în ce stadiu se află buildul în acest moment.
Vedem că acum 4 minute a fost făcut un commit care a trecut toate testele și nu a cauzat probleme.
Putem să ne uităm mai detaliat la builduri. Aici vedem că au fost deja trecute două stări. Starea de testare și starea de deploy pe staging.
Dacă facem clic pe un build specific, acolo va fi ieșirea de consolă a comenzilor care au fost rulate în proces conform .gitlab-ci.yml.
Așa arată istoricul produsului nostru. Vedem încercări reușite. Când testele eșuează, următorul pas nu se finalizează și codul pe staging nu se actualizează.
Ce probleme am rezolvat pe staging când am implementat docker? Sistemul nostru este compus din componente și a apărut necesitatea de a repornit doar părțile componente care au fost actualizate în repository, nu întregul sistem.
Pentru aceasta a trebuit să le împărțim pe fiecare în foldere separate.
După ce am făcut asta, am avut o problemă cu faptul că Docker-compose creează pentru fiecare folder un spațiu de rețea propriu și nu vede componentele vecine.
Pentru a o ocoli, am creat manual o rețea în Docker. În Docker-compose am specificat să folosească această rețea pentru acest proiect.
Astfel, fiecare componentă care pornește cu această rețea vede componentele din alte părți ale sistemului.
Problema următoare este separarea staging-ului între mai multe proiecte.
Pentru ca totul să arate bine și să fie cât mai asemănător cu producția, este bine să folosim portul 80 sau 443, care este folosit în mod obișnuit în WEB.
Cum am rezolvat asta? Am desemnat un Gitlab Runner pentru toate proiectele mari.
Gitlab permite pornirea mai multor Gitlab Runne-uri distribuite, care vor lua pur și simplu toate sarcinile în ordine aleatorie.
Pentru a nu se crea haos, am limitat grupul proiectelor noastre la un singur Gitlab Runner, care se descurcă fără probleme cu volumul nostru.
Am mutat nginx-proxy într-un script de pornire separat și în acesta am specificat rețelele tuturor proiectelor.
Proiectul nostru are o rețea, iar balancer-ul are mai multe rețele după numele proiectelor. Poate proxyia mai departe după numele de domeniu.
La noi, solicitările vin pe domeniu pe portul 80 și sunt gestionate într-un grup de containere care deservește acest domeniu.
Ce alte probleme au fost? Este faptul că, implicit, toate containerele rulează sub utilizatorul root. Acest root nu este același cu root-ul sistemului.
Cu toate acestea, dacă intri în container, acesta va fi root și fișierul pe care îl creăm în acest container primește permisiuni root.
Dacă dezvoltatorul a intrat în container și a efectuat acolo câteva comenzi care generează fișiere, apoi a ieșit din container, atunci în directorul său de lucru va avea un fișier la care nu are acces.
Cum putem rezolva aceasta? Putem adăuga utilizatori care vor fi în container.
Ce probleme au apărut când am adăugat un utilizator?
Atunci când creăm un utilizator, adesea nu coincid ID-ul grupului (UID) și ID-ul utilizatorului (GID).
Pentru a rezolva această problemă, în container folosim utilizatori cu ID 1000.
În cazul nostru, aceasta a coincis cu faptul că practic toți dezvoltatorii folosesc sistemul de operare Ubuntu. Iar în Ubuntu, primul utilizator are ID 1000.
Ce planuri avem?
Să citim documentația despre Docker. Proiectul se dezvoltă activ, documentația se schimbă. Informațiile care au fost obținute acum două-trei luni devin treptat învechite.
Unele probleme pe care le-am rezolvat sunt probabil deja rezolvate prin mijloace standard.
Cu siguranță, ne dorim să mergem mai departe direct către orchestrare.
Un exemplu este mecanismul încorporat în Docker, numit Docker Swarm, care vine din cutie. Ne dorim să lansăm ceva în producție pe baza tehnologiei Docker Swarm.
Generarea containerelor face ca lucrul cu jurnalele să fie incomod. Acum, jurnalele sunt izolate. Ele sunt împrăștiate printre containere. Una dintre sarcini este de a facilita accesul la jurnale printr-un interfață web.
Sursa: habr.com
