SISTEM DE MICROSERVICII EXPLOATATE ÎN DOCKER Coordonator științific Prof. Conf. Dr. Kevorchian Cristian Absolvent Pîrjoleanu -Grama And… [623973]

UNIVERSITATEA BUCUREȘTI
FACULTATEA DE MATEMATICǍ ȘI INFORMATICǍ
SPECIALIZAREA INFORMATICĂ

Lucrare de licență
SISTEM DE MICROSERVICII EXPLOATATE ÎN
DOCKER

Coordonator științific

Prof. Conf. Dr. Kevorchian Cristian Absolvent: [anonimizat], iar cele
tradiționale rămân în timp numai dacă dau dovadă de eficiență, stabilitate și utilitate. În
contrast, rapiditatea cu care se mișcă med iile de afaceri ne obligă să oferim soluții cât mai
flexibile și agile, fără a face rabat de la calitate sau simplitate.
Lucrare a de față prezintă o soluție eficientă de a îmbin a toate aceste aspecte sub forma un ei
arhitecturi de Sisteme de Mi croservicii , folosind conceptul de cont ainer oferit de Docker ,
nefiind nevoie de a compromite viitorul aplicației dezvoltate. În sprijinul ace stui concept vin e
și folos irea unor tehnologii noi cu potențial ridicat de a schimba pe viitor tot ce știm în
momentul de față despre întreg procesul de dezvoltare, de la programare a componentelor
până la livrarea produsului.
Obiectivul final este acela de a demonstra posibilitate a de a extinde o aplicație atât la un nivel
ridicat, cât și într -un ritm rapid, folosind un model arhitectural evolutiv , împr eună cu
tehnologiile potrivite.

iii
Cuprins
CUPRINS ………………………….. ………………………….. ………………………….. ………………………….. …………………….. III
LISTA DE FIGURI ………………………….. ………………………….. ………………………….. ………………………….. …………… V
LISTA DE TABELE ………………………….. ………………………….. ………………………….. ………………………….. ………….. VI
I INTRODUCERE ………………………….. ………………………….. ………………………….. ………………………….. ……………. 1
I.1. DEFINIR EA PROBLEMEI ………………………….. ………………………….. ………………………….. ………………………….. . 2
I.2. DEFINIREA SOLUȚIEI AL ESE ………………………….. ………………………….. ………………………….. ………………………. 2
I.2.1 Sistem de microservicii ………………………….. ………………………….. ………………………….. …………………. 2
I.2.2 Container de software ………………………….. ………………………….. ………………………….. ………………….. 3
II TEHNOLOGII FOLOSI TE ………………………….. ………………………….. ………………………….. ………………………….. .. 5
II.1. CONSUL ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 5
II.1.1 Descriere ………………………….. ………………………….. ………………………….. ………………………….. ………… 5
II.1.2 Definiții în cadrul tehnologiei ………………………….. ………………………….. ………………………….. ………… 6
II.1.3 Instalare ………………………….. ………………………….. ………………………….. ………………………….. ………… 7
II.2. FABIO ………………………….. ………………………….. ………………………….. ………………………….. ………………….. 7
II.2.1 Descriere ………………………….. ………………………….. ………………………….. ………………………….. ………… 7
II.2.2 Instalare ………………………….. ………………………….. ………………………….. ………………………….. ………… 9
II.3. DOCKER ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 9
II.3.1 Descriere ………………………….. ………………………….. ………………………….. ………………………….. ………… 9
II.3.2 Definiții în cadrul tehnologiei ………………………….. ………………………….. ………………………….. ………. 10
II.3.3 Cazuri de utilizare ………………………….. ………………………….. ………………………….. ………………………. 10
II.3.4 Instalare ………………………….. ………………………….. ………………………….. ………………………….. ………. 11
II.3.5 Configurarea și rularea unui container ………………………….. ………………………….. ……………………… 12
II.4. REGISTRATOR ………………………….. ………………………….. ………………………….. ………………………….. ………. 14
II.4.1 Descriere ………………………….. ………………………….. ………………………….. ………………………….. ………. 14
II.4.2 Instalare ………………………….. ………………………….. ………………………….. ………………………….. ………. 14
III ARHITECTURA APLI CAȚIEI ………………………….. ………………………….. ………………………….. ……………………… 15
III.1. COMUNICAREA ȘI INFRAS TRUCTURA ÎN CADRUL SIST EMULUI ………………………….. ………………………….. ………….. 15
III.1.1 Fluxul de informații ………………………….. ………………………….. ………………………….. ………………… 15
III.1.2 Infrastructura de noduri și centre de date ………………………….. ………………………….. ……………… 16
III.2. ARHITECTURA INTERNĂ ………………………….. ………………………….. ………………………….. ………………………… 18
III.2.1 Containerele și relația cu sistemele de operare ………………………….. ………………………….. ………. 18
IV IMPLEMENTAREA APL ICAȚIEI ………………………….. ………………………….. ………………………….. ………………… 19
IV.1. CREAREA IMAGINILOR ȘI A CONTAINERELOR DOCKER ………………………….. ………………………….. …………………… 19
IV.1.1 Consul ………………………….. ………………………….. ………………………….. ………………………….. ………. 19
IV.1.2 Fabio ………………………….. ………………………….. ………………………….. ………………………….. ……….. 20
IV.1.3 Registrator ………………………….. ………………………….. ………………………….. ………………………….. .. 20
IV.1.4 Microserviciu PHP ………………………….. ………………………….. ………………………….. ………………….. 21
IV.1.5 Microserviciu Java ………………………….. ………………………….. ………………………….. ………………….. 21

iv
IV.2. RULAREA APLICAȚIEI ………………………….. ………………………….. ………………………….. ………………………….. .. 22
IV.2.1 Rularea containerelor ………………………….. ………………………….. ………………………….. …………….. 22
IV.2.2 Interfața de configurare Consul ………………………….. ………………………….. ………………………….. .. 23
IV.2.3 Interfața de configurare Fabio ………………………….. ………………………….. ………………………….. …. 25
IV.2.4 Interfața aplicației ………………………….. ………………………….. ………………………….. …………………. 26
V CONCLUZII ȘI DEZVO LTĂR I ULTERIOARE ………………………….. ………………………….. ………………………….. …… 27
BIBLIOGRAFIE ………………………….. ………………………….. ………………………….. ………………………….. …………….. 30

v
Lista de figuri
FIGURA 1 – EXEMPLU DE ARHITECTUR Ă DE MICROSERVICII ………………………….. ………………………….. ………………………….. …. 3
FIGURA 2 – O PRIV IRE DE ANSAMBLU ASUP RA ARHITECTURII CONSUL ………………………….. ………………………….. …………………. 6
FIGURA 3 – ARHITECTURA UN UI CONTAINER DE TIP DOCKER ………………………….. ………………………….. ………………………….. 10
FIGURA 4 – EXEMPLU DE FIȘIER DOCKERFILE ………………………….. ………………………….. ………………………….. ……………….. 12
FIGURA 5 – EXEMPLU DE COMAN DĂ „DOCKER BUILD ”………………………….. ………………………….. ………………………….. …….. 12
FIGURA 6 – EXEMPLU DE COMANDĂ „DOCKER IMAGES ” ………………………….. ………………………….. ………………………….. ….. 13
FIGURA 7 – EXEMPLU DE COMANDĂ „DOCKER RUN ” ………………………….. ………………………….. ………………………….. ………. 13
FIGURA 8 – EXEMPLU DE ACCESARE A UNUI CONTAINER DIN B ROWSER -UL WEB ………………………….. ………………………….. ……. 13
FIGURA 9 – TRAGEREA IMAGINII REGISTRATOR DE PE DOCKER HUB ………………………….. ………………………….. …………………. 14
FIGURA 10 – RULAREA IMAGINII DE REGISTRATOR SI INIȚIA LIZAREA CONTAINERULU I ………………………….. ………………………….. 14
FIGURA 11 – FLUXUL DE INFORMAȚII ÎN SISTEMUL DE MICROSERVICII ………………………….. ………………………….. ………………. 15
FIGURA 12 – INFRASTRUCTURA DE NOD URI ȘI CENTRE DE DAT E ………………………….. ………………………….. ………………………. 17
FIGURA 13 – CONSUL DOCKERFILE – SIMPLU ………………………….. ………………………….. ………………………….. ……………….. 19
FIGURA 14 – CONSUL DOCKERFILE – COMPLEX ………………………….. ………………………….. ………………………….. …………….. 20
FIGURA 15 – FABIO DOCKERFILE ………………………….. ………………………….. ………………………….. ………………………….. … 20
FIGURA 16 – REGISTRATOR DOCKERFILE ………………………….. ………………………….. ………………………….. ……………………. 20
FIGURA 17 – MICROSERVICIU PHP DOCKERFILE ………………………….. ………………………….. ………………………….. …………… 21
FIGURA 18 – MICROSERVICIU JAVA DOCKERFILE ………………………….. ………………………….. ………………………….. …………… 21
FIGURA 19 – CODUL PENTRU CREAREA SI RULAREA CONTAINER ELE ………………………….. ………………………….. ………………….. 22
FIGURA 20 – INTERFAȚA CONSUL – LISTAREA DE SERVICII ………………………….. ………………………….. ………………………….. … 23
FIGURA 21 – INTERFAȚA CONSUL – DETALIILE UNUI SERVI CIU ………………………….. ………………………….. ………………………… 24
FIGURA 22 – INTERFAȚA CONSUL – LISTAREA DE NODURI ………………………….. ………………………….. ………………………….. … 24
FIGURA 23 – INTERFAȚA CONSUL – VERIFICAREA STATUSUL UI ………………………….. ………………………….. ………………………… 24
FIGURA 24 – INTERFAȚA FABIO – SUPRASCRIERI DE RUTE ………………………….. ………………………….. ………………………….. …. 25
FIGURA 25 – INTERFAȚA FABIO – LISTAREA DE RUTE ………………………….. ………………………….. ………………………….. ………. 25
FIGURA 26 – INTERFAȚA APLICAȚIEI – EXEMPLUL 1 ………………………….. ………………………….. ………………………….. ………… 26
FIGURA 27 – INTERFAȚA APLICAȚIEI – EXEMPLUL 2 ………………………….. ………………………….. ………………………….. ………… 26

vi
Lista de tabele
TABELUL 1 – MATRICEA PLATFORMELOR SUPORTATE DE CONSUL ………………………….. ………………………….. ……………………… 7
TABELUL 2 – MATRICEA PLATFORMELOR SUPORTATE DE FABIO ………………………….. ………………………….. ………………………… 9
TABELUL 3 – MATRICEA PLATFORMELOR SUPORTATE DE CĂTRE DOCKER ………………………….. ………………………….. …………… 12

1
I
Introducere
Avem nevoie sa dezvoltăm o aplicație enterprise de tipul server -side.

Dintre nevoile tehnice de infrastructura ce pot apărea enumerăm următoarele: [1]
 realizarea conexiunilor la servicii externe
 realizarea conexiunilor la baze de date
 integrarea cu alte aplicații interne prin diverse protocoale
 suportarea multiplilor clienți , precum aplicații de telefon, aplicații de browser ,
interfe țe web
 împărțirea pe componente logice corespunzătoare ariilor func ționale ale aplicaț iei

Dintre principiile arhitecturale pe care trebuie sa le luăm în calcul enumerăm următoarele: [2]
 N+1 Design – să existe mereu cel puțin două instanțe (dintre care măcar una de
rezervă) pentru fiecare componentă de infrastructură (serviciu)
 Asynchronous Design – Design Asincron – folosirea comunicării asincrone între
componentele de infrastructură (servicii)
 Scale out, not up – Scalare orizo ntală și nu verticală – adăugarea mai multor instanțe
fizice în defavoarea alocării mai multor resurse ( RAM , CPU etc.)
 Build small, Release small, Fail fast – Dezvoltă puțin , livrează puțin, greșește rapid –
dezvoltarea componentelor în iterații mici și rapide ce pot permite creșterea aplicației
într-un mod agil

2
 Fault isolation – Izolarea eșecurilor – implementarea unor mecanisme de verificare a
erorilor, pentru a preveni propagarea acestora
I.1. Definirea p roblemei
Pentru a putea satisface nevoile și a respecta principiile arhitecturale enumerate mai sus,
trebuie să alegem un model arhitectural agil și scalabil.
De asemenea, întrucât implementarea propriu -zisă a soluției nu reprezintă un model
arhitectural , ci deciziile pe care suntem constrânși să le luăm în fu ncție de costuri, investiții
(atât în resursele tehnice cât și cele umane), competențe și alte aspecte relevante pentru
companie și aplicație [2], trebuie să ne asigurăm că avem flexibilitatea de a dezvolta și livra
componentel e aplicației rapid, indi ferent de numărul de schimbări.
I.2. Definirea soluției alese
I.2.1 Sistem de microservicii
Alegem o arhitectură care structurează aplicația ca un set de procese ( servicii ) independente,
slab cuplate ce colaborează unul cu celălalt, având urmă toarele caracteristici: [1]
 fiecare serviciu implementează un set de funcții înrudite ce satisface nevoile unei
anumite arii a aplicației
 comunicarea între servicii se realizează folosind fie protocoale sincrone, precum
HTTP/REST 1, fie protocoale asincrone, precum AMQP 2
 fiecare serviciu are propria sa bază de date pen tru a fi decuplat de celelalte servicii
 serviciile pot fi dezvoltate și livrate independent unul de celălalt
Un astfel de proces (serviciu) independent , coeziv ce interacționează cu ajutorul mesajelor se
numește microserviciu . [3]
O arhitectură sau un sistem de microservicii este o aplicație distribuită în care toate modulele
(componentele) sale sunt microservicii . [3] O astfel de arhitectură descompune modelele

1 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
2 http://d ocs.oasis -open.org/amqp/core/v1.0/amqp -core -complete -v1.0.pdf

3
domeniului de business în contexte mai mici, limitate și consistente. Mai mult, microserviciile
sunt implementate și întreținute de obicei de echipe mici cu îndeajuns de multă autonomie,
astfel încât fiecare echipă și context își poate schimba detaliile interne de implementare
(inclusiv înlocu irea completă a acestuia) cu impact minim în întreg sistemul. [4]

I.2.2 Container de software
Pentru a facilita atât implementarea cât și livrarea rapidă ș i autonomă a fiecărei componente
din sistemul de microservicii , vom folosi o metodă de virtualizare la nivel de sistem de operare ,
ce partajează resursele ( RAM , CPU, Kernel , spațiul de stocare etc.) cu instanțele „oaspete”. În
consecință, e mai puțin probabil ca un număr arbitrar de instanțe virtualizate la nivel de sistem
de ope rare să rămână fără resurse decât același număr de instanțe virtualizat e la nivel de
mașină. [5]
Aceste instanțe „oaspete” virtualizate la nivel de sistem de operare se mai numesc containere .
Nu există încă specificații standar d pentru a determina cum anume ar trebui sa fie
Figura 1 – Exemplu de arhitectură de microservicii

4
implementarea unui container , însă există o inițiativă a mai multor companii mari de a crea un
standard in industrie: Open Container Initiative 3.
Există mai mu lte proiecte dezvoltate pe ideea de containere sub sistemul de operare Linux,
printre care enumerăm:
 Google containers 4
 Vserver 5
 OpenVZ project 6
 LXC containers 7
 Docker 8

3 https://www.opencontainers.org/
4 https://github.com/google/lmctfy
5 http://linux -vserver.org/
6 https://openvz.org/
7 https://linuxcontainers.org/
8 https://www.docker.com/

5
II
Tehnologii folosite
II.1. Consul
II.1.1 Descriere
Consul este o tehnologie pentru configurarea și descoperirea serviciilor dintr -o infrast ructură
dată.
Consul oferă următoarele caracteristici: i
 Service Discovery – Descoperire de Servicii – anumiți clienți ai Consul pot oferi un
anumit serviciu, iar alți clienți pot folosi Consul pentru a -i descoperi pe cei care oferă
un serviciu dat, folosi nd DNS 9 sau HTTP 10
 Health Checking – Verificarea statusului – clienții Consul pot oferi un număr de
verificări asociate fie cu un anumit serviciu („serverul întoarce 200 OK”), fie cu un nod
local („memoria folosită este sub 90%”); informația respectivă poate fi folosită de
componentele de Descoperire de Servicii pentru a redirecționa traficul către instanțele
„sănătoase”, fără pr obleme
 KV Store – Registru cheie/valoare – aplicațiile se pot folosi de registrul ierarhic de
cheie/valoare pentru orice scop, inclusiv configurare dinamică, coordonare, alegere de
lider 11 etc.

9 https://www.ietf .org/rfc/rfc1035.txt
10 https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
11 http://web -ext.u -aizu.ac.jp/~z -cheng/edu/DisAlgo808/lecture2.pdf

6
 Multi Datacenter – Centre multiple de date – Consul suportă si steme distribuite și
centre multiple de date în regiuni geografice diferite
II.1.2 Definiții în cadrul tehnologiei
Un agent Consul este un daemon ce rulează pe fiecare membru din clusterul Consul . Agentul
poate rula fie in modul client , fie in modul server . Din moment ce toate nodurile trebuie sa
ruleze un agent , e mai simplu să ne referim la nod ca fiind fie un client , fie un server , însă
există și alte instanțe ale agentului . Toți agenții pot rula interfețele DNS sau HTTP și sunt
responsabili pentru rularea verificărilor și menținerea serviciilor sincronizate. ii
Fiecare nod ce oferă servicii rulează un agent Consul . Rularea unui agent nu este necesară
pentru descoperirea altor servicii sau pentru manipularea datelor cheie/valoare. Agentul este
responsabil pentru verificarea statusului serviciilor din nod, precum și a nodului în sine. iii
Figura 2 – O privire de ansamblu asupra arhitecturii Con sul

7
Agenții discută cu unul sau mai multe servere Cons ul. Serverele sunt locurile în care datele sunt
stocate și replicate. Serverele își aleg dintre ele un lider. Deși Consul poate funcționa cu un
singur server , un număr între 3 și 5 este recomandat, pentru a evita scenariile de eșec ce pot
duce la pierderea de date. iv
II.1.3 Instalare
La data prezentei lucrări, Consul este disponibil pentru următoarele platforme:
Platform Consul 32 -bit Consul 64 -bit Consul Arm Consul Arm64
Mac OS X

FreeBSD

Linux

Solaris

Windows

Tabelul 1 – Matricea platformelor s uportate de Consul
Pentru instalare a fișierelor binare se deschide pagina de descărcă ri12 și se urmează
instrucțiunile .
Pentru o instalare mai complexă, se pot urma instrucțiunile din documentația oficială13.
II.2. Fabio
II.2.1 Descriere
Fabio este un router rapid și modern ce distribuie traf icul HTTP(S) 14 și TCP 15 în mod echilibrat,
folosit pentru implementarea aplicațiilor administrate de Consul .
Printre caracteristicile pe care le oferă, l e enumerăm pe următoarele:

12 https://www.consul.io/downloads.html
13 https://www.consul.io/docs/install/index.html
14 https://tools.iet f.org/html/rfc2818
15 https://tools.ietf.org/html/rfc793

8
 Access Logging – Jurnal de acces – generarea unui jurnal de acces cu toate cererile
HTTP
 Certificate Stores – Registru de certificate – stocarea într -un loc central a certificatelor
 Compression – Comprimarea răspunsurilor – comp rimarea dinamică a răspunsurilor
atunci când este prezent header -ul HTTP „Accept -Encoding: gzip”
 Docker Support – Suport pentru Docker – rularea Fabio într-un container de Docker
 Dynamic Reloading – Reîncărcare dinamică – Fabio își reîncarcă toată configur ația la
fiecare schimbare în Consul , fără a întrerupe conexiunile active
 Graceful Shutdown – Închidere elegantă – Fabio suportă un timp de închidere pe
durata căruia cererile noi vor primi un cod HTTP „503 Service Unavailable”, iar cele
active sunt aștepta te să se termine
 HTTP Header Support – Suport pentru headere HTTP adiționale
 HTTPS Upstream Support – Suport pentru HTTPS la serverele aflate înainte de Fabio
 Metrics Support – Colectarea metricilor și integrarea cu alte tehnologii
 Path Stripping – Elidare a parțială a segmentelor din URL
 PROXY Protocol Support – Suport pentru protocolul PROXY 16
 SSE – Server -Sent Events – Detectarea conexiunilor SSE 17
 TCP Proxy Support – Suport pentru proxy TCP
 TCP + SNI Proxy Support – Suport pentru proxy TCP cu SNI 18
 Traffic Shaping – Controlul traficului
 Request Debugging – Depanarea cererilor
 Request Tracing – Urmărirea cererilor

16 http://www.haproxy.org/download/1.8/doc/proxy -protocol.txt
17 https://www.w3.org/TR/eventsource/
18 https://tools.ietf.org/html/rfc6066#section -3

9
 Websocket Support – Suport pentru protocolul WebSocket
 Web UI – Interfață web
II.2.2 Instalare
La data prezentei lucrări, Fabio este disponibil pentru următoarele platforme:
Platform Fabio 386 Fabio Amd64 Fabio Arm
Darwin

FreeBSD

Linux

NetBSD

OpenBSD
Windows

Tabelul 2 – Matricea platformelor suportate de Fabio
Pentru instalarea fișierelor binare se deschi de pagina de descărcări19 și se urmează
instrucțiunile.
Pentru o instalare mai complexă, se pot urma instrucțiunile din documentația oficială20.
II.3. Docker
II.3.1 Descriere
Docker este o tehnologie de virtualizare la nivel de sistem de operare.
În plus față de construcția de containere , Docker oferă de asemenea pentru dezvoltatori și alte
caracteristici, precum: [5]
 crearea unui mediu de implementare a aplicațiilor și partajarea acestuia colegilor de
echipă

19 https://github.com/fabiolb/fabio/releases
20 https:// github.com/fabiolb/fabio/wiki/Installation

10
 refolosirea componentelor ( imaginilor de bază, de pe urma cărora se pot crea
componente mai specializate)
 suportarea multiplelor versiuni ale unui container
 posibili tatea de a porta cu ușurință o implementare și în alte sisteme
II.3.2 Definiții în cadrul tehnologiei
O imagine este un pachet independent, executabil, ce include tot ce are nevoie pentru a rula
o componentă software, inclusiv codul, bibliotecile necesare, variab ilele de mediu, fișierele de
configurare și altele asemănătoare. v
Un container este o instanță de rulare a unei imagini – ceea ce devine imaginea in memorie
atunci când este executată. Rulează complet izolat de mediul mașinii gazdă, accesând doar
fișierel e gazdă și port -urile, în cazul în care este configurat astfel. vi
Containerele rulează nativ în kernelul mașinii gazdă și au performanțe mai bune decât mașinile
virtuale, fiecare rulând într -un proces discret, consumând nu mai multă memorie decât orice
alt executabil. vii

II.3.3 Cazuri de utilizare
Printre exemplele cele mai cunoscute de cazuri de utilizare ale tehnologiei Docker se numără:
 integrarea continuă ( Continuous Integration 21)

21 https://www.thoughtworks.com/continuous -integration
Figura 2 – Arhitectura unui container de tip Docker Figura 3 – Arhitectura unui container de tip Docke r

11
 implementarea continuă ( Continuous Deployment 22) ce se bazează pe livrarea
continuă ( Continuous Delivery 23)
Dezvoltatorii pot construi pe stațiile lor de lucru combinații de containere de Docker ce pot
replica un mediu de producție. Aplicația acestora poate rula pe acea combinație, după care se
poate migra cu ușurință și pe alte m așini.
În vreme ce o construcție de mașini virtuale poate dura și zece minute, o construcție de
containere durează câteva secunde. Cei de la IBM au făcut o cercetare în acest sens și au
precizat faptul că per tranzacție, în medie, un container este de apro ape 26 de ori mai rapid
decât o mașină virtuală. [6] [7]
II.3.4 Instalare
La data prezentei lucrări, sunt disponibile două ediții Docker : Community Edition (CE) și
Enterprise Edition (EE) , fiind suportate pe următoarele platforme:
Platform Docker CE x86_64 Docker CE ARM Docker EE
Ubuntu

Debian

Red Hat Enterprise Linux

CentOS

Fedora

Oracle Linux

SUSE Linux Enterprise Server

Microsoft Windows Server 2016

Microsoft Windows 10

macOS

Microsoft Azure

Amazon Web Services

22 https://martinfowler.com/bliki/ContinuousDelivery.html
23 https://www.thoughtworks.com/continuous -delivery

12
Tabelul 3 – Matricea platformelor suportate de către Docker
Pentru instalare se deschide p agina aferentă fiecărei platforme din tabelul de mai sus și se
urmează instrucțiunile.
II.3.5 Configurarea și rularea unui container
Pentru definirea unui container , se creează un fișier sub numele de Dockerfile . În el vom defini
ce se va întâmpla în mediul dinău ntrul containerului , precum accesul la interfețele rețelei și
fișierele stocate în mediul virtual izolat, corespondența porturilor, fișierele copiate din exterior
în interior etc. viii

Pasul următor este acela de a construi imaginea Docker ce va fi folo sită la rularea
containerului , cu ajutorul comenzii build . ix
Figura 4 – Exemplu de fișier Dockerfile
Figura 5 – Exemplu de comandă „docker build”

13
Pentru a lista imaginile construite, folosim comanda images . Pe ecran ne vor apărea atât
denumirile depozitelor ( repositories ), cât și identificatorul unic al imaginii și etichetele ( tags )
asocia te. x
În final, se execută comanda run pentru a rula containerul și a-l expune eventual către exterior,
pe un anumit port.
Pentru exemplul de mai sus, rezultatul se poate vedea accesând adresa locală pe portul 4000 ,
întrucât s -a creat o corespondență ( port mapping ) între portul accesat la exterior ( 4000 ) și cel
de care știe containerul în interior ( 80).

Figura 6 – Exemplu de comandă „docker images”
Figura 7 – Exemplu de comandă „docker run”
Figura 8 – Exemplu de accesare a unui container din browser -ul web

14
II.4. Registrator
II.4.1 Descriere
Registrator este un registru de servicii pentru Docker . Acesta examinează containerele Docker
care rulează, înregist rând în m od automat serviciile ( containerele ) noi create și ștergându -le
din evidență pe cele care se opresc.
Registrator suportă registre de servicii conectabili, precum Consul , etcd și SkyDNS 2.
II.4.2 Instalare
Instalarea Registrator se face via Docker , folosind imaginea 24 disponibilă d e pe Docker Hub25.

24 https://hub.docker.com/r/gliderlabs/registrator/
25 https://hub.docker.com/
Figura 9 – Tragerea imaginii Registrator de pe Docker Hub
Figura 10 – Rularea imaginii de Registrator si inițializarea containerului

15
III
Arhitectura aplicației
III.1. Comunicarea și infrastructura în cadrul sistemului
III.1.1 Fluxul de informații
În linii mar i, deși poate varia în funcție de gradul de scalare al aplicației, fluxul de informații
arată precum în Error! Reference source not found. .

Am ales un scenariu în care există un domeniu web ( exemplu.com ) care trimite spre o mașină
pe care este instalat și configurat Fabio . Această instanță Fabio este legată de un agent Consul ,
care are acces la întreg registrul de microservicii .
HTTP
Utilizator
Fabio
Fabio
Fabio
Consul
exemplu.com
Microserviciu
TCP
Registrator
Registrator
Registrator
Microserviciu
Microserviciu
TCP
TCP
TCP
TCP
Figura 11 – Fluxul de informații în Sistemul de Microservicii

16
Microserviciile sunt înregistrate în Consul cu ajutorul lui Registrator . Deși acesta din urmă
trimite informa țiile conform cărora un container rulează sau nu, Consul este cel care decide
dacă un microserviciu e activ și poate fi interogat, în baza criteriilor și verificărilor de status
(health check ).
Fabio primește de la Consul lista cu microserviciile active împreună cu detaliile fiecăruia
(variabile de mediu setate, prefixe de URL-uri etc.), o compară cu setările proprii pe care le are
pe rutele declarate și pe ponderea acestora, iar în cele din urmă trimite cererea HTTP către un
microserviciu ales conform crit eriilor îndeplinite.
III.1.2 Infrastructura de noduri și centre de date
Există numeroase posibilități de implementare a unui sistem de microservicii la nivel de
infrastructură. Se poate pleca de la un model simplu, în care atât instanțele de microservicii ,
cât și instanțele celorlalte tehnologii se află pe o singură mașină și implicit în același centru de
date. Pe măsură ce aplicația se dezvoltă, va apărea necesitatea separării acestora pe mașini
diferite, pe principiul scalării orizontale.
În primă fază, se pot se para instanțele de Consul și Fabio de cele de microservicii și Registrator ,
pentru a împărți aplicația pe două noduri. Pe urmă, avem posibilitatea de a împărți
microserviciile pe mașini separate . Este important ca fiecare mașină să aibă câte o instanță de
Registrator , indiferent de numărul de instanțe de microservicii , întrucât containerele Docker
care se pornesc sau se opresc sunt urmărite la nivel de fișiere socket de către Registrator .
Într-o fază ulterioară, în funcție de nivelul de creștere a aplicație i și de gradul dorit de
scalabilitate (trafic, resurse, timp de răspuns etc.), se pot separa microserviciile pe noduri și
mai multe, având posibilitatea de ridica și mai multe instanțe de Consul .
De asemenea, în funcție de specificațiile aplicației și de nevoi, în orice moment se poate face
distribuirea geografică a resurselor, prin crearea mai multor centre de date, indiferent de
numărul de noduri din fiecare. În acest caz, vom avea multiple instanțe de Consul împărțite
între centrele de date.
În cazul în care ne dorim, putem avea flexibilitate și la nivel de interfață de comunicare cu
exteriorul, prin ridicarea mai multor instanțe de Fabio , fiecare având rutele și nevoile sale,
împreună cu domeniile web ce vor face legătura către acestea. Legătura se va f ace în același

17
mod cu instanțele de Consul , având acces în continuare la același registru comun de
microservicii .
În Figura 12 putem observa un model mai complex de implementare de infrastructură, având
trei centre de date și numeroase noduri, dintre care patru de Consul și două de Fabio .

Registrator
Microserviciu
CENTRUL DE DATE #1
Registrator
Microserviciu
Consul
Consul
Registrator
Microserviciu
Registrator
Microserviciu
CENTRUL DE DATE #2
CENTR UL DE DATE #3
Registrator
Microserviciu
Registrator
Microserviciu
Registrator
Microserviciu
Registrator
Microserviciu
Consul
Consul
Fabio
Fabio
Figura 12 – Infrastructura de noduri și centre de date

18
III.2. Arhitectura internă
III.2.1 Containerele și relația cu sistemele de operare
La nivel intern, pentru fiecare tip de instanță ridicată ( Fabio , Consul , Registrator , microserviciu
de tip A, microserviciu de tip B) am ales crearea câte unei imagini Docker , pentru facilitarea
dezvoltării , a implementării și a replicării rapide.
Fiecare nod poate avea opțiunea proprie de a alege un sistem de operare, containerele pornite
având propria lor organ izare internă, folosindu -se la comun doar partajarea resurselor
sistemului de operare.
Mai mult decât atât, fiecare imagine Docker poate pleca la nivel intern de la orice imagine de
bază, ce va conține o distribuție aleasă de sistem de operare, în funcție de nevoile fiecăreia.
Într-un final, se pot porni oricât de multe containere și se pot alege oricât de multe sisteme de
operare diferite, iar funcționalitatea microserviciilor poate fi scrisă în orice limbaj de
programare, în funcție de complexitatea aplic ației, oferind atât flexibilitatea, cât și
scalabilitatea necesară unei astfel de nevoi.

19
IV
Implementarea aplicației
IV.1. Crearea imaginilor și a containerelor Docker
Pentru a păstra în continuare un mod de lucru agil și flexibil, în procesul de creare a imaginil or
Docker am folosit câteva imagini de bază deja existente, disponibil e pe Docker Hub26.
IV.1.1 Consul
Pentru rularea unui container ce conține o instalare Consul , am folosit ca bază imaginea
oficială27 creată de HashiCorp 28.
Există numeroase moduri de a configura Consul , toate depinzând de infrastructura aleasă și
de nevoi.
Am ales ca exemplu:
 o configurație simplă ce poate fi folos ită la rularea unei singure instanțe Consul
 configurație mai complexă, ce poate fi folosită la rularea mai multor instanțe Consul
într-un centru de date, pe scenariul alegerii de lider xi

26 https://hub.docker.com/
27 https://hub.docker.com/_/consul/
28 https://www.hashicorp.com/
Figura 13 – Consul Dockerfile – simplu

20

IV.1.2 Fabio
Pentru rularea unui container ce conține o instalare Fabio , am folosit ca bază imaginea 29
creată de cel care a dezvoltat și implementat Fabio .
Fișierul de configurare are minimum de linii, neavând nevoie deocamdată de adăugiri.

IV.1.3 Registrator
Pentru rularea unui container ce conține o instalare Registrator , am folosit ca bază imaginea
30 creată de cei care au dezvoltat și implementat Registrator .
Fișierul de configurare are minimum de linii, ne având nevoie deocamdată de adăugiri.

29 https://hub.docker.com/r/magiconair/fabio/
30 https://hub.docker.com/r/gliderlabs/registrator/
Figura 14 – Consul Dockerfile – complex
Figura 15 – Fabio Dockerfile
Figura 16 – Registrator Dockerfile

21

IV.1.4 Microserviciu PHP
Pentru rularea unui container ce conține o instalare a unui microserviciu, am folosit ca bază o
imaginea oficială 31 de PHP cu Apache , tag 5.6.28 .
În plus față de ce avea imaginea de bază, am ales să permit rescrierile de URL-uri, am instalat
managerul de dependențe Composer 32, am pus variabile de mediu pentru verificarea
statusului serviciului în Consul și am copia t codul -sursă înăuntrul instanței microserviciului .
IV.1.5 Microserviciu Java
Pentru rularea unui container ce conține o instalare a unui microserviciu, am folosit ca bază o
imagine33 de Java cu Apac he Tomcat 7 , JRE7 , luată aleatoriu, pentru a demonstra flexibilitatea
și agilitatea folosirii Docker .
În plus față de ce avea imaginea de bază, am pus variabile de mediu pentru verificarea
statusului serviciului în Consul.

31 https://hub.docker.com/_/php/
32 https://ge tcomposer.org/
33 https://hub.docker.com/r/milkyway/tomcat7 -jre7/
Figura 17 – Microserviciu PHP Dockerfile
Figura 18 – Microserviciu Java Dockerfile

22

IV.2. Rularea aplicației
IV.2.1 Rularea con tainerelor
În Figura 19 putem observa codul pentru crearea și rularea containerelor într-un caz simplu
de utilizare, în care toate instanțele se află pe aceeași mașină, adresele fiind locale.

# Builds:

# Consul
docker build –no-cache -t andrei/microsystem -consul ~/Docker/Microservices/consul
# Registrator
docker build –no-cache -t andrei/microsystem -registrator
~/Docker/Microservi ces/registrator
# Fabio
docker build –no-cache -t andrei/microsystem -fabio ~/Docker/Microservices/fabio
# PHP
docker build –no-cache -t andrei/microsystem -php ~/Docker/Microservices/php
# Java
docker build –no-cache -t andrei/microsyst em-java ~/Docker/Microservices/java

# Runs:

# Consul
docker run -d \
–name=Consul \
–net=host \
-h consul.docker.local \
andrei/microsystem -consul
# Registrator
docker run -d \
–name=Registrator \
–net=host \
-h registrator.docker.local \
–volume=/var/run/docker.sock:/tmp/docker.sock \
andrei/microsystem -registrator \
-ip localhost \
consul://localho st:8500
# Fabio
docker run -d \
–name=Fabio \
–net=host \
-h fabio.docker.local \
andrei/microsystem -fabio
# PHP
docker run -d \
-e "APP_NAME=MICRO_SERV_P HP_1" \
-l "SERVICE_TAGS=urlprefix -/" \
-p 8081:80 \
–name srv.php.main.1 \
andrei/microsystem -php
# Java
docker run -d \
-e "APP_NAME=MICRO_SERV_JAVA_1" \
-l "SERVICE_TAGS=urlprefix -/" \
-p 8082:8080 \
–name srv.java.main.1 \
andrei/microsystem -java Figura 19 – Codul pentru crearea si rularea containerele

23

IV.2.2 Interfața de conf igurare Consul
Odată ce aplicația rulează, putem intra î n interfața de configurare Consul la adresa setată,
unde avem următoarele opțiuni:
 vizualizarea listei de servicii
 vizualizarea detaliilor unui serviciu
 vizualizarea listei de noduri
 vizualizarea deta liilor unui nod
 vizualizarea tuturor variabilelor cheie/valoare
 vizualizarea drepturilor de acces
 vizualizarea centrelor de date precum și filtrarea informațiilor după unul din acestea
 setarea unui token de acces
Figura 20 – Interfața Consul – listarea de servicii

24

Figura 21 – Interfața Consul – detaliile unui serviciu
Figura 22 – Interfața Con sul – listarea de noduri
Figura 23 – Interfața Consul – verificarea statusului

25
IV.2.3 Interfața de configurare Fabio
Pentru a seta modul în care lucrează Fabio , putem intra în interfața sa de configurare la adresa
setată, unde avem următoarele opțiuni:
 vizualizarea tuturor rutelor serviciilor, precum și posibilitatea de filtrare a acestora
 schimbarea de rute și reechili brarea raportului de trafic între servicii, după diverse
criterii

Figura 25 – Interfața Fabio – listarea de rute
Figura 24 – Interfața Fabio – suprascrieri de rute

26
IV.2.4 Interfața aplicației
După configurarea aplicației și lansarea acesteia în producție, putem observa că la fiecare
accesare, Consul lucrează împreună cu Fabio pentru alegerea unui servi ciu care să rezolve
cererea HTTP : la două accesări succesive a aceleiași adresă, codul se execută pe microservicii
diferite.

Figura 26 – Interfața aplicației – exemplul 1
Figura 27 – Interfața aplicației – exemplul 2

27
V
Concluzii și dezvoltări ulterioare
Pentru a dezvolta și implementa o aplicație complexă ce are potențial de creștere (at ât din
punctul de vedere al dificultății caracteristicilor cerute de domeniu, cât și din punctul de
vedere al traficului, numărului de utilizatori, numărului de dezvoltatori, echipe etc.),
arhitectura bazată pe microservicii poate fi o alegere foarte bună în combinație cu tehnologiile
potrivite, oferind flexibilitatea , rapiditatea și agilitatea necesară într -un domeniu ce evoluează
rapid sau într -o piață imprevizibilă.
Dezavantajele acestei abordări pot fi:
 Complexitatea ridicată la nivel de infrastructură – pe măsură ce aplicația se dezvoltă,
pot apărea probleme cu grad ridicat de dificultate, precum consistența datelor ,
performanța execuției codului la volume mari sau costul ridicat de mentenanță
 Costuri mari la nivel de resurse – nivelul ridicat de cunoș tințe pe care trebuie să îl aibă
echipa, potențiala lipsa a personalului calificat (deși dezvoltarea în sine a unui
microserviciu devine o formalitate, este nevoie de expertiză la nivel de „pregătire a
terenului” – instalare și configurare), coordonarea di ficilă atât între echipe cât și la
nivel de integrare de servicii (rezolvarea unei probleme ce necesită schimbarea codului
în mai multe instanțe)
 Lipsa maturității tehnologiei – comparativ cu alte abordări tradiționale, atât conceptul
de microservicii cât și conceptul de container sunt încă la început, nebeneficiind de o
experiență mare

28
Cu toate acestea, un Sistem de Microservicii dezvoltat cu ajutorul Docker are o deschidere
mare către viitor. Folosind platformele și tehnologiile puse la dispoziț ie, (ex.: Amazon Web
Services 34), putem construi o arhitectură elastică, obținând caracteristici precum:
 Detecția creșterii rapide a traficului și ridicarea de noi instanțe la nevoie
 Detecția scăderii de performanță și creșt erea alocării de resurse
 Migrarea fără probleme de configurare către alte centre de date
 Monitorizarea erorilor și izolarea cauzei problemelor
 Specializarea serviciilor și a sistemelor pe diverse arii tehnice, precum procesarea
avansată de calcul , stocarea media etc.
 Scăderea latenței și a timpului de procesare, creșterea stabilității aplicației, prin
disponibilitate ridicată a serviciilor și distribuire geografică

34 https://aws.amazon.com/

29

30
Bibliografie

[1] C. Richardson, „Pattern: Microservice Architecture,” 20 15. [Interactiv]. Available:
http://microservices.io/patterns/microservices.html.
[2] M. L. Abbot și M. T. Fisher, The Art of Scalability: Scalable Web Architecture, Processes, and
Organizations for the Modern Enterprise (2nd Edition), Addison -Wesley, 20 15.
[3] N. Dragoni, S. Giallorenzo, A. L. Lafuente, M. Mazzara, F. Montesi, R. Mustafin și L. Safina,
„Microservices: yesterday, today, and tomorrow,” 20 April 2017. [Interactiv]. Available:
https://arxiv.org/pdf/1606.04036.pdf.
[4] C. Posta, Microser vices for Java Developers, O'Reilly, 2016.
[5] J. Fink, „Docker: a Software as a Service, Operating System -Level Virtualization Framework,”
code4lib, nr. 25, 21 July 2014.
[6] J. Turnbull, Interviewee, Docker. [Interviu]. 23 April 2015.
[7] W. Felt er, A. Ferreira, R. Rajamony și J. Rubio, „An Updated Performance Comparison of Virtual
Machines,” Austin, 2014.
[8] Docker, Inc., „Docker for the Virtualization Admin,” 2016.

i https://www.consul.io/intro/index.html
ii https://www.consul.io/docs/internals/architecture.html
iii https://www.consul .io/intro/index.html
iv https://www.consul.io/intro/index.html
v https://docs.docker.com/get -started/#prerequisites
vi https://docs.docker.com/get -started/#prerequisites
vii https://docs.docker.com/get -started/#prerequisites
viii https://docs.docker.com/get -start ed/part2/#define -a-container -with -a-dockerfile
ix https://docs.docker.com/get -started/part2/#build -the-app
x https://docs.docker.com/get -started/part2/#run -the-app
xi https://www.consul.io/docs/guides/leader -election.html