UNIVERSITATEA POLITEHNICA DIN BUCURES, TI

FACULTATEA DE AUTOMATICĂ S, I CALCULATOARE

DEPARTAMENTUL DE CALCULATOARE
Computer Science - Logo
HBFX

Computer Science
& Engineering
Department

Computer Science
& Engineering
Department

PROIECT DE DIPLOMĂ

Proiectarea s, i Implementarea unui Serviciu de Tip DNS

Iulia-Adriana Călătoaie

Coordonator s, tiint, ific:

S.L. Dr. Ing. Alexandru Corneliu Olteanu

BUCURES, TI
2021
 UNIVERSITY POLITEHNICA OF BUCHAREST
FACULTY OF AUTOMATIC CONTROL AND COMPUTERS
COMPUTER SCIENCE AND ENGINEERING DEPARTMENT
Computer Science - Logo
HBFX

Computer Science
& Engineering
Department

Computer Science
& Engineering
Department

DIPLOMA PROJECT

The Design and Implementation of a DNS as a Service

Iulia-Adriana Călătoaie

Thesis advisor:
Lect Alexandru Corneliu Olteanu, Ph.D.

BUCHAREST
2021
CUPRINS

1 Introducere 1

1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Obiective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Structura lucrării . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Analiza Cerint, elor 3

2.1 Cerint, e funct, ionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Cerint, e non-funct, ionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Abordări existente 6

3.1 Designate, o solut, ie DNSaaS pentru OpenStack . . . . . . . . . . . . . . . 6

3.2 Amazon Route 53 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Cloud DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4 Solut, ia Propusă 8

4.1 Arhitectura aplicat, iei s, i fluxul de date . . . . . . . . . . . . . . . . . . . . . 8

4.2 Dezvoltarea aplicat, iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

5 Detalii de implementare 11

5.1 Infrastructura aplicat, iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

5.1.1 Imaginile Docker folosite ı̂n cadrul unui Docker Registry privat . . . . 11

5.1.2 Infrastructura aplicat, iei ı̂n cadrul Kubernetes . . . . . . . . . . . . . 12

5.2 Proxy utilizând Kong API Gateway . . . . . . . . . . . . . . . . . . . . . . 13

5.3 Împachetarea aplicat, iei pentru instalare folosind Helm Charts . . . . . . . . 14

5.4 Componenta de PowerDNS . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.5 Monitorizarea aplicat, iei . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

1
 5.5.1 Servirea informat, iilor din bazele de date . . . . . . . . . . . . . . . . 16

5.5.2 Monitorizarea folosind Prometheus . . . . . . . . . . . . . . . . . . 17

5.5.3 Expunerea informat, iilor de monitorizare ı̂n interfat, a de Grafana . . . 17

5.6 Componenta de Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.6.1 Implementarea folosind Spring Boot Framework . . . . . . . . . . . 18

5.6.2 Construirea JAR-ului folosind Maven . . . . . . . . . . . . . . . . . 20

5.6.3 Implementarea componentei folosind Java . . . . . . . . . . . . . . . 22

5.7 Stocarea datelor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

6 Evaluarea cerint, elor 24

7 Concluzii 27

7.1 Contribut, ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

7.2 Dezvoltări viitoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

SINOPSIS
Implementarea s, i Dezvoltarea unui Serviciu de Tip DNS reprezintă un prototip cu rolul de a
contura o idee despre cum ar putea arăta, ce ar putea fi ı̂mbunătăt, it s, i ce ar putea fi extins
ca un produs de tipul SaaS (Software as a Service) să poată fi construit. Acest proiect a fost
dezvoltat s, i testat ı̂n cadrul unui serviciu de cloud, cu sprijinul furnizorului de servicii 1&1
Ionos. Componentele sale fac parte din acelas, i cluster s, i pot comunica atât ı̂ntre ele, cât s, i
cu exteriorul. Aplicat, ia este disponibilă oriunde ı̂n lume, cu un timp de răspuns mediu de
până ı̂n 2s. Aceasta are două mari componente principale: logica s, i monitorizarea. Logica
aplicat, iei se ocupă de rezolvarea cererilor de tip REST. Acestea sunt operat, ii pe domenii, la
nivel de resurse de tip DNS. În această etapă modificările nu rezolvă ı̂n Internet, fiind necesară
o arhitectură mai complexă. Monitorizarea se ocupă de colectarea datelor s, i expunerea lor
ı̂ntr-o interfat, ă prietenoasă cu utilizatorul s, i us, or de modelat.

ABSTRACT
The Design and Implementation of a DNS as a Service is a prototype with the role of outlining
an idea of what it might look like, what could be used and what could be extended so that a
SaaS (Software as a Service) product could be built. This project was developed and tested
within a cloud service, with the support of 1&1 Ionos service provider. Its components are
part of the same cluster. They can communicate inside the cluster, with each other, as well
as outside the cluster, when resolving requests. The application is available anywhere around
the world, with an average response time up to 2s. It has two main components: business
logic and monitoring unit. The business logic component is resolving REST requests. These
requests are made on DNS Resource Records. The changes are not available in the Internet,
being necessary a more complex architecture. Monitoring is in charge of data collection and
exposure in a user-friendly and easy-to-model interface.
MULT, UMIRI
Doresc să le mult, umesc colegilor din echipa de DNS a companiei 1&1 Ionos, ı̂n special domnu-
lui Daniel Cristian Miu, ı̂n calitate de manager al echipei, cât s, i domnului profesor Alexandru
Corneliu Olteanu, ı̂n calitatea de coordonator s, tiint, ific, pentru ı̂ndrumarea oferită ı̂n realizarea
acestei lucrări s, i a proiectului aferent.
1 INTRODUCERE
1.1 Context

Proiectul ı̂s, i propune să aducă o componentă-prototip de tipul SaaS (Software as a Service)
pentru un viitor proiect mai amplu. Acesta a fost construit cu ajutorul tehnologiilor s, i serviciilor
puse la dispozit, ie de firma de găzduire 1&1 Ionos, ı̂n cadrul căruia a fost realizat, dar s, i cu
tehnologii complementare, open source (spre exemplu Kubernetes, Docker, Grafana).

S-a observat pe piat, ă, ı̂n ultimii ani, o ı̂ndreptare spre direct, ia SaaS, pornind de la marii
dezvoltatori, ca Amazon sau Google, ce oferă astfel de servicii atât client, ilor de tip persoană
fizică, cât s, i celor de tip companie. 1&1 Ionos este o companie ce oferă servicii de găzduire
web, cloud, domenii, servicii de e-mail, certificate SSL, pachete pentru construirea de site-uri
web, precum s, i servere virtuale private s, i servere dedicate. Printre actualele sale proiecte se
numără s, i această trecere a serviciilor ı̂n sfera de aaS.

1.2 Problema

Rezolvarea DNS, respectiv rezolvarea unui nume de domeniu ı̂n Internet, este un serviciu
oferit ı̂n cadrul găzduirii unui domeniu. Numele de domeniu trebuie să fie unic ı̂n Internet,
iar, pentru a avea sens, adresa IP este de obicei mapată la un spat, iu web oferit de un furnizor
de servicii, unde clientul ı̂s, i poate atas, a cont, inutul pe care ı̂l dores, te la accesarea numelui de
domeniu (spre exemplu, ı̂n cazul unui site web cont, inutul ar putea fi o serie de pagini de tip
HTML).

Componentele utilizate ı̂n cadrul fiecărei firme nu sunt de sine stătătoare, de obicei, ci co-
munică ı̂ntre ele s, i pot fi adeseori conectate cu componente externe ecosistemului de servicii
oferite, pentru a putea da nas, tere unor pachete. Ideea de SaaS pledează pentru o copie a unui
astfel de pachet care poate fi rulată pe un server. De aceea, pentru un astfel de produs, pot
apărea probleme la nivel de infrastructură s, i comunicare ı̂ntre componente, accesul la resurse
sau chiar mentenant, ă.

În această ordine de idei, scopul prezentei lucrări este acela de a putea contura o imagine
despre cum ar putea fi rezolvate, ı̂n primă fază, complicat, iile ce ar putea apărea având ı̂n
vedere faptul că această componentă de DNS este, de cele mai multe ori, o componentă a
unui pachet oferit unui client, s, i nu un serviciu de sine stătător, din punct de vedere logistic.
Spre exemplu, unui client ı̂i va fi mai greu să aibă unul sau mai multe domenii găzduite de o
firmă la nivel de spat, iu web sau servere de nume ce ı̂i expun ı̂n Internet domeniul, iar de la o

1
firmă diferită să ı̂s, i administreze ı̂nregistrările de resurse de tip DNS (DNS Resource Record).

1.3 Obiective

Prezenta lucrare ı̂s, i propune să ofere o primă imagine asupra unei componente DNS as a
Service (DNSaaS). Pe baza acestui rezultat va avea loc un proces iterativ de reanalizare a
cerint, elor, rezolvare a neajunsurilor, ı̂mbunătăt, ire a arhitecturii s, i incorporare ı̂n cadrul unui
pachet complet.

Cum această lucrare va fi prezentată ı̂ntr-o formă singulară, ca proiect de finalizare a studiilor,
va fi tratată ca o componentă de sine stătătoare. Astfel, trebuie să cont, ină un set de cerint, e
minimale de funct, ionare: adăugarea, prelucrarea s, i s, tergerea de informat, ie utilă la nivelul unui
utilizator, un strat de securitate a acestor date, la nivel de autentificare de tip BasicAuth, s, i
monitorizarea componentelor s, i informat, iilor.

1.4 Structura lucrării

În cele ce urmează vor fi prezentate următoarele idei:

• Analiza cerint, elor - Va fi prezentat conceptul de SaaS (Software as a Service), pentru

a putea motiva alegerea cerint, elor funct, ionale cât s, i non-funct, ionale, ce vor fi descrise
ı̂n continuarea sa.
• Abordări existente - Vor fi aduse ı̂n prim-plan alternative ale produsului prezentat sub
diferite forme s, i incorporat ı̂n diferite pachete.
• Solut, ia propusă - Cititorul va putea fi familiarizat cu arhitectura s, i fluxul aplicat, iei,
fiind explicată interact, iunea dintre componente la nivel de ı̂nt, elegere a traseului pe care
datele ı̂l vor urma la primirea unei cereri. De asemenea, vor fi descrise interact, iunea cu
utilizatorul s, i procesul de iterare până la forma prezentă a aplicat, iei.
• Detalii de implementare - Vor fi prezentate tehnologiile folosite, interact, iunea dintre ele
s, i detalii cu privire la procesul de construire al aplicat, iei.
• Evaluarea cerint, elor - Vor fi analizate s, i supuse măsurătorilor (acolo unde este cazul)
cerint, ele specificateı̂n Analiza cerint, elor”. Este de ment, ionat că o paralelă cu abordările
”
deja existente pe piat, ă, la nivel de măsurători, este aproape imposibilă, deoarece nu este
ı̂n discut, ie analiza unui produs complet, ci a unui subset de funct, ionalităt, i.
• Concluzii - Vor fi prezentate concluziile acestei teze, contribut, iile s, i variantele deı̂mbunătăt, ire
a prototipului.

2
2 ANALIZA CERINT, ELOR
Prezenta lucrare a fost realizată ı̂n parteneriat cu echipa de DNS a companiei 1&1 Ionos.
S-a observat ı̂n ultimii ani, pe partea de găzduire, o direct, ie ce ı̂nclină spre SaaS (Software
as a Service) s, i PaaS (Platform as a Service). În cele ce urmează vom discuta doar despre
conceptul de SaaS, deoarece face subiectul acestei lucrări.

SaaS este o modalitate de livrare a unui produs software. În acest model clientul are po-
sibilitatea de a accesa o copie a unei aplicat, ii pe care furnizorul o pune la dispozit, ie. [9]
Această copie are nevoie de un administrator ce se ocupă de actualizări de sistem. Copiile
pot fi t, inute s, i utilizate la nivel de cloud, după cum vom putea observa s, i analizând prototipul
ce face scopul lucrării. O copie poate fi utilizată de unul sau mai mult, i client, i, ı̂n funct, ie de
specificat, ii. Actualizările de sistem sunt automate s, i nu influent, ează disponibilitatea sistemu-
lui. Cum ceea ce accesează utilizatorul se află ı̂n cloud, disponibilitatea serviciilor depinde
exclusiv de disponibilitatea serviciului de cloud. La rândul ei aceasta depinde de furnizorul de
cloud.

În urma s, edint, elor din cadrul companiei s, i consultării cu client, ii, s-a decis crearea unui prototip,
pentru a testa cerint, ele ce vor fi prezentate mai jos. Pe baza acestei experient, e, se va decide
modelarea produsului ı̂ntr-un stadiu mai avansat, respectiv o componentă de DNS as a Service
ce va fi inclusă ı̂ntr-un pachet cu servicii complementare, necesare găzduirii unui domeniu ı̂ntr-
un format mai us, or deı̂nt, eles, care săı̂i ocupe un spat, iu cât mai mic utilizatorului (spre exemplu
serverele de DNS de tipul PowerDNS ar putea fi accesate dintr-un spat, iu de cloud separat
sau ar putea fi adăugate mai multe tipuri de servere, cum vom putea observa la solut, iile deja
existente din capitolul 3).

2.1 Cerint, e funct, ionale

Potent, ialii utilizatori ai prototipului aplicat, iei sunt cei cu cunos, tint, e minimale privind lucrul ı̂n
linie de comandă (pentru a putea instala aplicat, ia ı̂n mediul local) sau care au un serviciu de
cloud, mai exact de Managed Kubernetes. De asemenea, cunos, tint, ele de bază despre DNS
sunt necesare oricărui utilizator. Consumatorii pot avea un domeniu, dar mai avantajat, i vor
fi cei cu un plural de domenii.

Aplicat, ia va avea nevoie de un ansamblu de utilitare preinstalate pentru a putea rula cu

succes. Acestea se vor găsi ı̂n instruct, iunile de folosire, alături de toate informat, iile necesare
interact, iunii cu acest API. Utilizatorul va avea acces la un executabil ce realizează instalarea
componentelor aplicat, iei. Mai departe, utilizatorul va putea trimite cereri folosind un utilitar

3
la alegere (spre exemplu Postman) pentru a adăuga s, i modifica propriile domenii la nivel de
ı̂nregistrări de resurse. El va beneficia de un nume de utilizator s, i o parolă, necesare pentru
accesarea serviciilor/componentelor interne aplicat, iei. De asemenea, utilizând un punct de
acces specific, local, va putea să-s, i monitorizeze starea componentelor s, i resursele consumate,
după dorint, ă.

Un lucru important ce trebuie specificat este că această componentă se va putea ocupa de
domenii doar la nivel de ı̂nregistrări de resurse valide. În acest stadiu de prelucrare, domeniul
trebuie să existe deja ı̂n Internet s, i să fie valid din punct de vedere al ı̂nregistrărilor de resurse.

Cu această abordare utilizatorii nu vor fi nevoit, i să intre ı̂ntr-un anumit ecosistem sau să
utilizeze o suită de servicii complementare dacă nu vor dori acest lucru, ci vor putea avea
local sau ı̂n cloud propriul server minimal de DNS, ce le va oferi transparent, ă ı̂n modificarea
domeniilor det, inute la nivel de ı̂nregistrări de resurse de tip DNS. Într-o etapă finală vor putea
să utilizeze serviciul s, i ı̂mpreună cu componentele complementare lui, ce le vor fi puse la
dispozit, ie sub forma unui produs complet, de găzduire de domeniu.

Un astfel de pachet ar putea veni ı̂n ajutorul utilizatorilor ce doresc mai multă transparent, ă
pentru serviciile achizit, ionate s, i ar putea rezolva probleme ce s-ar putea găsi la nivel de
configurare a interfet, ei web cu care sunt obis, nuit, i (spre exemplu la o lansare de versiune, nu
se propagă corect toate modificările la nivel de interfat, ă cu utilizatorul).

2.2 Cerint, e non-funct, ionale

• disponibilitate
– După instalare, aplicat, ia va fi disponibilă din t, ări diferite din lume. La nivel de
informat, ii (spre exemplu cont, inutul bazelor de date sau informat, iile de monitorizare
preluate de instant, a de Prometheus) vor fi persistente la nivel de restartare a
Pod-ului de Kubernetes, acestea incluzând funct, ionalitatea de volum persistent
(Kubernetes Persistent Volume).
• implementare
– Două comenzi (câte una pentru logica aplicat, iei s, i monitorizare) de tipul install”
”
vor fi necesare pentru instalarea aplicat, iei pe mediul de lucru. Pentru dezinstalare
va fi acelas, i caz. Aceste comenzi simple sunt facilitate de ı̂mpachetarea aplicat, iei
folosind Helm Charts.
• documentat, ie
– Pentru accesarea serviciilor s, i monitorizarea componentelor sale se vor consulta
instruct, iunile de utilizare care vor veni odată cu produsul s, i suportul oferit acestora.
De asemenea, utilizatorul va putea să-s, i modifice atât datele de autentificare pentru
folosirea API-ului, cât s, i cele de Grafana după specificat, iile din documentat, ie.

4
• extensibilitate
– Acesta fiind un prototip, scopul lui este să contureze o idee despre fiabilitatea
acestei solut, ii s, i să fie dezvoltat mai departe ı̂ntr-un produs final ce va putea
lucra cu altele, complementare lui. Se vor putea adăuga ulterior servicii noi de tip
DNS (spre exemplu DNSSEC). Componentele vor urma principiile SOLID pentru
a facilita extinderea. De asemenea, se vor putea ı̂nlocui, după nevoie s, i fiabilitate,
componente actuale ı̂n servicii SaaS.
• timp de răspuns
– Timpul de răspuns va fi influent, at, pentru acest prototip, de situarea geografică
a utilizatorului ı̂n funct, ie de name serverele furnizorului de domeniu ce se ocupă
cu rezolvarea, dar această ı̂ntârziere va depinde s, i de alte metrici, nu numai de
implementare, după cum va fi dezvoltat ı̂n sect, iunea de evaluare a rezultatelor.

5
3 ABORDĂRI EXISTENTE
În capitolul ce urmează, vor fi prezentate pe scurt serviciile oferite de abordări existente ale
produsului incorporat, după cum se va putea observa, ı̂ntr-un pachet complet.

3.1 Designate, o solut, ie DNSaaS pentru OpenStack

Designate oferă o solut, ie utilizatorilor de infrastructură DNS prezentată prin intermediul unui
API REST potrivită pentru OpenStack. [2]

OpenStack este un proiect opensource ce pune la dispozit, ie un ecosistem de servicii, infras-

tructuri s, i platforme găzduite ı̂n mediul cloud 1 .

Designate permite utilizatorului să aleagă serverul DNS preferat dintr-un set pus la dispozit, ie
s, i să ı̂s, i controleze domeniile la nivel de ı̂nregistrări de resurse DNS, nume s, i zone. Printre
ele se numără PowerDNS. Pentru partea de autentificare s, i gestionare a utilizatorilor foloses, te
Openstack Identity Service (Keystone). Se instalează din linia de comandă folosind utilitarul
pip, din colect, ia de python package manager. Poate fi folosit prin intermediul OpenStack
Dashboard, o interfat, ă prietenoasă cu utilizatorul, conform documentat, iei ce se poate găsi la
[2].

3.2 Amazon Route 53

Amazon Route 53 este un serviciu web de tip DNS.[7]

Pentru a-l putea accesa, utilizatorul trebuie să intre sau să fie deja ı̂nregistrat ı̂n acest eco-
sistem pus la dispozit, ie de Amazon. Produsul este menit să fie utilizat ı̂mpreună cu produse
complementare de la acelas, i furnizor, după cum ment, ionează prezentarea produsului 2 . Cli-
entul trebuie să se logheze cu un cont AWS. De asemenea, pentru a beneficia de securitate,
integrează serviciul AWS Identity.

Pe lângă operat, iile standard de lucru cu ı̂nregistrări de resurse DNS (s, tergere s, i inserare de
zonă, actualizare), Amazon Route 53 oferă s, i serviciul de Domain Name Registration, adică
oferă verificarea disponibilităt, ii unui nume de domeniu s, i opt, iunea de ı̂nregistrare. La crearea
de zonă cu informat, ii DNS, ı̂i va fi oferit utilizatorului patru name servere ce vor rezolva
1
https : //dl.acm.org/doi/abs/10.1145/2628194.2628195 (15.06.2021)
2
http : //cabibbo.dia.uniroma3.it/asw − 2014 − 2015/altrui/AW SO verview.pdf (15.06.2021)

6
zonele ı̂n Internet. Această interact, iune cu utilizatorul este posibilă prin intermediul AWS
Management Console sau chemând API-ul, conform documentat, iei [7].

Utilizatorul ı̂s, i poate configura verificări de stare. Acestea vor monitoriza situat, ia aplicat, iei s, i
a punctelor de acces ale acesteia.

3.3 Cloud DNS

Cloud DNS este o solut, ie oferită de Google atât pentru interogare DNS cât s, i pentru găzduire.

Rulează pe aceeas, i infrastructură ca s, i serviciul Google.”[1]

”
Serviciul promite un număr forte mare de ı̂nregistrări de resurse DNS ce vor putea fi alipite
unui domeniu s, i name servere rapide, cu disponibilitate de 100%. Oferta vorbes, te despre
milioane de zone s, i ı̂nregistrări de resurse DNS. Acesta pune la dispozit, ie s, i serviciul de creare
s, i găzduire de zone private, ce vor putea fi integrate ı̂n proiecte s, i organizate după nevoile
utilizatorului.

Cloud DNS oferă o arhitectură hibridă pentru serviciul lor găzduire. Acesta beneficiază de trei
variante, toate bazându-se pe tunelări VPN (Virtual Private Network) s, i VPC (Virtual Private
Cloud). Pentru beneficierea de acest serviciu virtual s, i privat de cloud, conform documentat, iei
ce se găses, te la [1], zona trebuie creată ı̂ntr-o componentă de găzduire s, i apoi poate fi adăugat
serviciul ment, ionat anterior, ı̂n varianta partajată.

Pentru disponibilitate oriunde ı̂n lume s, i timp de răspuns scurt, sunt puse la dispozit, ie anycast
name servers.

7
4 SOLUT, IA PROPUSĂ
4.1 Arhitectura aplicat, iei s, i fluxul de date

În următoarea figură poate fi observată arhitectura aplicat, iei:

Figura 1: Arhitectura aplicat, iei

După cum se poate remarca ı̂n Figura 2, utilizatorul va putea trimite cereri ce t, in de adăugarea,
modificarea, s, tergerea s, i observarea domeniilor pe care le det, ine, la nivel de ı̂nregistrări de
resurse DNS. Aceste cereri vor fi filtrate s, i rutate de o instant, ă de Kubernetes Ingress din
cadrul cluster-ului. Aceasta va folosi Kong Api Gateway pentru a expune utilizatorului o
adresă IP externă, prin care poate utiliza serviciile interne ale clusterului. API-ul de Kong
foloses, te un serviciu de proxy pentru a servi către exterior serviciile la care va avea acces
utilizatorul.

Dacă utilizatorul dores, te să facă o operat, ie pe domeniile sale, atunci cererea sa va fi re-
directată mai departe către componenta de Gateway, care se va ocupa de autentificare s, i
redirectare către componentele din Logic. Acestea vor stoca datele necesare ı̂n bazele de date
PostgreSQL, unde se vor stoca informat, ii ce t, in domeniul ı̂n sine, s, i MySQL, unde se vor stoca
informat, iile referitoare la ı̂nregistrările de resurse DNS. Componenta de MySQL va accepta
conexiunea de la o instant, ă de PowerDNS care va servi informat, iile ı̂n Internet. Acest lucru
se va putea verifica prin interogarea acestei instant, e la rularea utilitarelor de interogare DNS

8
(spre exemplu dig [3]).

Dacă utilizatorul dores, te să primească informat, ii de monitorizare a sistemului, atunci cererea
lui va fi redirectată către instant, a de:

• PostgreSQL Exporter, dacă dores, te să obt, ină informat, ii despre metrici
• Prometheus, dacă dores, te să obt, ină informat, ii despre Pod-uri
• Grafana, dacă dores, te să vadă informat, ii despre Pod-uri s, i despre numărul de zone
ı̂ntr-un format mai prietenos cu utilizatorul decât Prometheus sau dores, te să obt, ină
informat, ii personalizate

Pentru instant, a de PowerDNS se va folosi o bază de date standard, ce va expune informat, ii

despre ı̂nregistrările de resurse DNS. Spre acesta instant, a va putea face interogări ı̂n funct, ie
de tipul acestor ı̂nregistrări. Din această cauză nu se vor putea face interogări de tipul ANY
[3], respectiv pentru colectarea tuturor tipurilor de ı̂nregistrări de resurse DNS.

4.2 Dezvoltarea aplicat, iei

Structura solut, iei a fost conturată init, ial ca un ansamblu de componente nucleu: partea de
logică a aplicat, iei cu volumele pentru păstrarea datelor (bazele de date), o componentă de
autentificare, o componentă de monitorizare s, i o instant, ă de PowerDNS, ca server, pentru a
servi zonele.

Componenta centrală de logică t, ine de structura internă a componentelor dezvoltate ı̂n cadrul
companiei, fapt pentru care va fi tratată ca o cutie neagră. Scopul ei este tratarea cererilor s, i
facilitarea lucrului cu ı̂nregistrările de resurse de tip DNS. Astfel, ea are nevoie de conexiunea
cu bazele de date PostgreSQL s, i MySQL pentru a păstra informat, iile necesare implementării
funct, ionalităt, ilor.

Componenta de autentificare va funct, iona cu nume de utilizator s, i parolă implicite. Cu toate

acestea utilizatorul le poate modifica, după cum este explicat ı̂n documentat, ie. Aceasta va
face s, i redirect, ionarea cererilor Http către unitatea de logică.

Componenta de monitorizare poate extrage informat, ii din baza de date PostgreSQL, respectiv,
utilizatorul poate monitoriza numărul de zone pe care le are. S-a renunt, at ulterior la extragerea
de informat, ii despre zone sau la listarea zonelor pentru că acest lucru este deja posibil prin
cererile către componenta ce se ocupă de logică. Pentru accesul de monitorizare al datelor
s-a utilizat o instant, ă de PostgreSQL Exporter. Acesta comunică cu instant, a de Prometheus,
care, pe lângă această comunicare, va colecta informat, ii s, i despre Pod-urile de Kubernetes
(spre exemplu memoria folosită, timpul de disponibilitate de la pornirea aplicat, iei). Cum
interfat, a de Prometheus nu este foarte prietenoasă cu utilizatorul, s-a decis expunerea acestor
metrici ı̂ntr-o instant, ă de Grafana. Accesul la aceasta se face pe bază de nume de utilizator s, i
parolă. Utilizatorul ı̂s, i poate modifica parola s, i poate avea acces la metricile expuse mai sus,

9
instant, a de Prometheus deja fiind configurată ca sursă de date. Astfel utilizatorul va putea
să-s, i construiască propriile panouri de monitorizare.

10
5 DETALII DE IMPLEMENTARE
Pentru a putea ı̂nt, elege mai bine ce dificultăt, i ı̂s, i propune prototipul să rezolve, este nevoie
de o introspect, ie ı̂n tehnologiile folosite s, i modalitatea ı̂n care acestea conlucrează pentru a
da forma aplicat, iei finale.

5.1 Infrastructura aplicat, iei

5.1.1 Imaginile Docker folosite ı̂n cadrul unui Docker Registry privat

Docker este o platformă ce ajută la dezvoltarea aplicat, iilor. Aceasta facilitează separarea
infrastructurii aplicat, iei de platforma pe care aceasta rulează, constituind astfel o solut, ie ce
militează pentru portabilitate cât s, i simplitatea ı̂n dezvoltare. Docker foloses, te o arhitectură
de tip client-server. Clientul de Docker (utilizatorul), comunică prin setul de instruct, iuni cu
daemon-ul ce se ocupă cu organizarea s, i orchestrarea obiectelor (spre exemplu containere,
ret, ele). Un container este o instant, ă ı̂n rulare a unei imagini. O imagine Docker poate fi
văzut ca un s, ablon imutabil” 1 .
”
Docker registry este un serviciu ce găzduies, te imagini Docker. Utilizatorul ce construies, te un
astfel de serviciu este responsabil de mentenant, a sa s, i ı̂l poate face public sau privat, diferent, a
fiind nevoia de securitate.

Aplicat, ia ı̂n sine foloses, te imagini Docker ale instant, elor. Ele sunt ı̂ncărcate de un adminis-
trator s, i trase de Deployment-urile de Kubernetes. Acest proces are loc o singură dată, la
instalarea aplicat, iei.

Pentru partea de monitorizare (instant, ele de PostgreSQL Exporter, Prometheus s, i Grafana),

imaginile sunt cele oficiale, regăsite pe Docker Hub, s, i ajustate ı̂n funct, ie de necesitate. Pentru
partea de logică a aplicat, iei, PowerDNS s, i baze de date (instant, ele de PostgreSQL s, i MySQL)
sunt folosite imagini Docker personalizate.

Pe partea de administrator al aplicat, iei, imaginile vor fi construite, le vor fi atas, ate etichete spe-
cifice s, i vor putea fi ı̂ncărcate ı̂ntr-un Docker registry privat. Acesta este găzduit pe o mas, ină
virtuală, pusă la dispozit, ie ı̂n spat, iul de cloud de furnizorul 1&1 Ionos s, i rulează ı̂n permanent, ă.
Pentru o mai us, oară folosire i s-a atas, at domeniul privateregistry.test-dnsaas.com. Docker
registry-ul privat beneficiază de securitate la nivel de certificat TLS s, i autentificare pe bază
de nume de utilizator s, i parolă.
1
https : //www.inf oworld.com/article/3204171/what − is − docker − the − spark − f or − the −
container − revolution.html (14.06.2021)

11
5.1.2 Infrastructura aplicat, iei ı̂n cadrul Kubernetes

Kubernetes este un sistem open source de gestionare a containerelor Docker. Poate fi im-
”
plementat s, i gestionat direct pe hardware, pe un cluster care cont, ine mas, ini virtuale sau pe o
combinat, ie a ambelor, des, i această variantă nu este una uzuală.” 2

Sistemul poate orchestra clustere, respectiv o colect, ie de gazde numite noduri. Nodurile
sunt gestionate de un master Kubernetes. Nodul master este responsabil pentru programarea
Pod-urilor (la nivel global) s, i controlul evenimentelor din interiorul cluster-ului.

Un Pod este o unitate de lucru ı̂n Kubernetes s, i poate cont, ine unul sau mai multe containere.
Pod-urile din aceeas, i aplicat, ie sunt programate, de regulă, să funct, ioneze pe acelas, i nod.
Containerele din acelas, i nod au aceeas, i adresă IP s, i port, ce formează socket-ul Kubernetes.
Pod-urile partajează memoria regăsită pe nod.

Serviciile (Kubernetes Services) sunt utilizate pentru a expune funct, ionalităt, i utilizatorilor sau
altor componente. Acestea operează protocoale de nivel trei (TCP/UDP), fiind dezvăluite
folosind DNS sau variabile de mediu.

Kubernetes funct, ionează cu volume (Kubernetes Volumes/Persistent Volumes) pentru a asi-

gura transferul de date ı̂n interiorul Pod-ului s, i continuitatea datelor după moartea sau res-
tartarea Pod-ului.

Un Deployment este un obiect ce se ocupă de ciclul de viat, ă al componentei. Acesta descrie

reguli specifice pentru imaginea Docker folosită, numărul de replici pornite, incorporarea de
volume, variabile de mediu, proprietăt, i sau argumente adit, ionale cu care este pornită imaginea.
Un Deployment generează un Pod s, i un ReplicaSet s, i este recomandat ı̂n detrimentul utilizării
separate ale celor două servicii pe care le incorporează.

Un ReplicaSet este un obiect a cărui sarcină este stabilirea numărului de replici cu care va
porni un Pod s, i mentenant, a acestor replici pe parcursul rulării aplicat, iei. Scopul lui este de a
garanta utilizatorului că numărul de replici pe care ı̂l alege este numărul de replici pe care ı̂l
va putea observa ı̂n starea de Running după pornire.

Un lucru ce trebuie ment, ionat este că scalarea replicilor se poate face s, i dinamic, după pornirea
Pod-urilor, dar, ı̂n acest scenariu, ı̂n cazul acestui prototip, alterările de acest tip pot duce la
pierderea comunicării dintre componente. Spre exemplu, modificarea dinamică a numărului
de replici a instant, ei de baze de date, poate duce la probleme la nivel de comunicat, ie ı̂ntre
componentele ce se ocupă cu orchestrarea informat, iilor primite la nivel de cerere. Mai simplu,
comunicat, ia va fi pierdută s, i nu se va garanta restabilirea ei dacă nu se va reporni manual s, i
Deployment-ul acelei componente. În principiu, utilizatorul nu este sfătuit să facă modificări
asupra componentelor, ci este de dorit să trateze prototipul ca pe o cutie neagră.
2
https : //books.google.ro/books?hl = enlr = id = dnc5DwAAQBAJoi = f ndpg =
P P 1dq = Gigi + Sayf an, +M astering + Kubernetesots = i6sudqW cW tsig = yhq2EluoIgT 1P U −
72JnJ8f 4OP Qredire sc = yv = onepageq = Gigi%20Sayf an%2C%20M astering%20Kubernetesf =
f alse (20.06.2021)

12
La ı̂nceput, Kubernetes a fost construit pentru a lucra cu containere Docker, ale căror imagini
erau pornite ı̂n Pod-uri. Cu ajutorul acestei funct, ionalităt, i, s-a construit s, i acest prototip.
Imaginile preluate din Docker registry-ul privat vor fi incorporate ı̂n Pod-uri. Ele vor fi extrase
cu ajutorul unui Kubernetes Secret.

Un Secret stochează informat, ii sensibile, asemeni datelor de autentificare sau cheilor SSH.
Ment, inerea ı̂n acest format este mai flexibilă s, i mai intuitivă, din punct de vedere al logicii
s, i ı̂mbinării Kubernetes cu Helm Charts, decât explicitarea ı̂n cadrul Deployment-ului. În
acest punct, al dezvoltării de prototip ce realizează funct, ionalitatea de bază a unui server
minimal DNS, datele de autentificare pot fi aflate de utilizator. Riscul aici devine ca, ı̂n cazul
unui utilizator malit, ios, imaginile să poată fi alterate, iar acest comportament să influent, eze
utilizatorii noi. În cazul unui utilizator neatent, alterarea datelor de autentificare poate duce
la probleme de funct, ionalitate locală. Acest lucru este ment, inut ı̂n vedere pentru dezvoltări
ulterioare, după cum va fi ment, ionat ı̂n capitolul aferent viitoarelor ı̂mbunătăt, iri.

Pod-urile vor avea atas, ate servicii (Kubernetes Services) pentru a putea comunica ı̂ntre ele s, i,
la nevoie, cu exteriorul. Serviciile vor expune IP-uri externe pentru comunicarea cu exteriorul,
prin care utilizatorul va putea beneficia de funct, ionalitate exclusiv ı̂n aria serverului cel mai
apropiat, dacă nu dores, te instalarea Kong Api Gateway, serviciu ce va fi tratat ı̂n următorul
subcapitol.

Aplicat, ia lucrează cu versiunea de Kubernetes 18.8. O alternativă pentru această tehnologie

utilizată este Docker Swarm.

Docker Swarm este un utilitar de orchestrare a multiple containere Docker pe multiple sisteme
”
sau gazde.” 3

Acesta operează cu concepte similare Kubernetes, precum noduri, containere s, i replici ce pot
fi scalate. Spre deosebire de Kubernetes, comunitatea nu este la fel de dezvoltată. De ase-
menea, Kubernetes este un proiect open source ı̂n continuă dezvoltare. Pentru dezvoltare,
Kubernetes beneficiază de mai multe funct, ionalităt, i s, i o plajă mai largă de posibile persona-
lizări s, i extensii. Kubernetes oferă, ı̂n plus, serviciul de Kubernetes Ingress, care facilitează
comunicarea cu exteriorul, la nivel programatic. De asemenea, folosind Kubernetes, putem
utiliza complementar Helm, un utilitar dedicat pentru lucrul cu acest serviciu, subiect ce va fi
atins ı̂n cele ce urmează.

5.2 Proxy utilizând Kong API Gateway

Pentru a realiza decuplarea clientului de subsetul de microservicii, s-a decis utilizarea unui API
Gateway. Pe lângă această funct, ionalitate, pentru o mai bună securitate, Kong Api Gateway
pune la dispozit, ie un strat de autentificare. În viitor acesta ar putea fi utilizat, dar, pentru
3
https : //dzone.com/articles/docker − explained − an − introductory − guide − to − docker
(18.06.2021)

13
simplitate, s-a păstrat această funct, ionalitate la nivel de header BasicAuth, ı̂n componenta
de Gateway ce se ocupă s, i de redirectarea către piesele din interiorul componentei logice.

Kong Api Gateway, la nivel de instalare, este us, or de utilizat, acesta fiind, poate, cel mai mare
avantaj ı̂n comparat, ie cu alte aplicat, ii similare. Acesta este un proiect ce pune la dispozit, ie
caracteristicile de bază ale unui API Gateway open source. Comunitatea sa este ı̂n continuă
dezvoltare, beneficiind de platforma Kong Hub, unde se pot găsi o paletă diversă de plugin-uri.
[8]

Ceea ce a fost folosit, din suita de servicii pe care Kong o pune la dispozit, ie, a fost serviciul de
proxy, care este folosit de Kubernetes Ingress. Astfel, prin intermediul acestui API, utilizatorul
va putea să conecteze IP-ul public, servit de Kong API Gateway, la un domeniu, pentru ca
aplicat, ia să fie disponibilă oriunde ı̂n lume, ı̂ntr-un timp mult, umitor, după cum vom putea
observa ı̂n capitolul ce tratează evaluarea rezultatelor.

A fost ales Kong pentru acest prototip, tocmai pentru că s-a dorit o solut, ie simplă de instalat,
open source, cu o licent, ă permisivă s, i ce oferă posibilitatea adăugării de funct, ionalităt, i noi la
nevoie.

5.3 Împachetarea aplicat, iei pentru instalare folosind Helm Charts

Helm este un utilitar ce funct, ionează ı̂mpreună cu Kubernetes. Componenta numită Charts
este o solut, ie simplă ce ajută la definirea s, i instalarea aplicat, iilor Kubernetes sub forma unor
ierarhii de fis, iere de configurare. 4

Odată ce acestea au fost construite, este nevoie de o singură comandă (helm install) pentru
instalarea unei aplicat, ii complete s, i de o singură comandă (helm uninstall) pentru dezinstalarea
sa. Acesta este un utilitar ce vine ı̂n ajutorul dezvoltatorului care dores, te structurarea ı̂n fis, iere
separate a componentelor aplicat, iei sale, ce pot fi pornite fără comenzi multiple, ori ı̂ns, iruirea
tuturor fis, ierelor. De asemenea, Helm Charts impune o politică de Ingress, as, adar conceputul
de separare a spat, iului de cloud de exterior va fi tratat printr-un astfel de serviciu. Pentru
aceasta, s-a folosit Kong Api Gateway, ı̂n prototipul ce face scopul lucrării.

Pentru o mai bună ı̂mpărt, ire a logicii aplicat, iei, există două chart-uri ce vor fi puse la dispozit, ie:
unul de aplicat, ie ı̂n sine, iar cel de-al doilea pentru monitorizarea aplicat, iei.

Fiecare componentă va avea un fis, ier de configurare separat, ı̂n care se va găsi partea de
Kubernetes Service, ce se va ocupa de descoperirea serviciului, Deployment, ce va controla
ciclul de viat, ă al componentei. În cazul bazelor de date PostgreSQL s, i MySQL se vor găsi, ı̂n
plus, volume persistente (Kubernetes Persistem Volumes), ca, ı̂n cazul unei reporniri la nivel
de Pod, ce poate surveni din partea operatorului de cloud, datele să nu fie afectate.

Pentru componentele de monitorizare se va respecta aceeas, i regulă. Respectiv, instant, a de

4
https://arxiv.org/abs/1901.00644v1 (21.06.2021)

14
PostgreSQL Exporter va avea partea de Kubernetes Service s, i Deployment, iar instant, ele
de Prometheus s, i Grafana vor avea, ı̂n plus, volume persistente, pentru a nu se pierde
măsurătorile, ı̂n cazul Prometehus, s, i tablourile de monitorizare, ı̂n cazul Grafana.

O alternativă pentru Helm Charts este Kubernetes Operator. Optarea pentru varianta folosită
vine din satisfacerea nevoilor aplicat, iei ı̂ntr-un format mai simplu de dezvoltat. Cu alte cuvinte,
implică un mai mare efort ı̂n ceea ce prives, te informarea, ı̂nt, elegerea, dar s, i dezvoltarea ı̂n sine
a aplicat, iei. Desigur, Kubernetes Operator oferă funct, ionalităt, i s, i posibilităt, i de dezvoltare la
nivel ı̂nalt, ı̂n comparat, ie cu solut, ia simplă oferită de Helm Charts, dar aceste funct, ionalităt, i
nu sunt necesare.

Aplicat, ia lucrează cu Helm Charts ı̂n versiunea helm3.

5.4 Componenta de PowerDNS

PowerDNS (sau PDNS) este un server DNS open source, ce se poate conecta la majoritatea
bazelor de date existente. Acesta implementează protocolul DNS, oferă suport pentru toate
tipurile de ı̂nregistrări de resurse DNS comune s, i o listă a ı̂nregistrărilor mai put, in comune.
De asemenea, oferă suport pentru zonele de tip master/slave.

Acesta este, ı̂n aplicat, ia curentă, o componentă ı̂n sine. Se conectează la baza de date
MySQL, pentru a avea acces la informat, iile referitoare la zonele adăugate.

Imaginea acestei componente este preluată de pe Docker Hub, ı̂n cadrul căreia se va supras-
crie fis, ierul de configurare. Acest pas este necesar pentru a adăuga proprietăt, ile necesare
serviciului, facilitând conectarea la baza de date, s, i pentru a face interogările zonelor de tip
native.

O zonă DNS cont, ine informat, ii despre setări s, i ı̂nregistrări de resurse DNS din spat, iul de
nume din care face parte. Un domeniu (sau un nume de domeniu) este un s, ir de caractere ce
identifică unic un serviciul ı̂n Internet. [4]

O ı̂nregistrare de resursă (DNS Resource Record) este o descriere a unei resurse. [4] Aceasta
are următoarele câmpuri: nume, timp de expirare a cererii, clasă, tip s, i date.

• Numele reprezintă numele gazdei.

• Timpul de expirare al cererii este exprimat ı̂n secunde.
• Clasa descrie protocolul utilizat, de obicei fiind setată la IN (Internet protocol). [4]
• Tipul este o abreviere a resursei. Exemple de tipuri sunt: A/AAAA (timpul pentru
adresa ı̂n format IPv4/IPv6), MX (e-mail), NS (name serverul de unde vor fi servite
ı̂nregistrările de resurse ı̂n Internet).
• Datele diferă pentru fiecare tip deı̂nregistrare. Spre exemplu, datele pentru oı̂nregistrare
de resursă de tip A reprezintă adresa IPv4.

Diferent, a principală ı̂ntre zonele master s, i cele slave este proprietatea de a fi modificate. [4]

15
Zonele master pot fi citite s, i scrise, ı̂n timp ce zonele slave sunt doar citite. Majoritatea
zonelor slave sunt copii ale zonelor master.

Instant, a de PowerDNS va avea acces la zone de tipul native, pentru că pot fi modificate.

Diferent, a dintre tipul de zone native s, i master este doar din punct de vedere al PDNS s, i
al configurării sale interne. Zonele native sunt zone master pentru care nu se vor trimite
notificări către zone slave, copii ale zonelor master, din diferite motive, cel mai intuitiv fiind
că zonele slave nu există.

Instant, a va funct, iona ca un name server, ce va putea fi interogat cu ajutorul utilitarelor

specializate (spre exemplu dig [3]). Se vor trimite cererile folosind protocolul UDP, pe portul
53, după cum este standardul de funct, ionare a acestei instant, e, ı̂n mod implicit.

Un lucru de avut ı̂n vedere este faptul că, ı̂n cadrul acestor interogări, nu va fi funct, ională
cererea de tip ANY din cadrul utilitarului dig, pentru că instant, a actuală de PowerDNS va
interpreta tipul de ı̂nregistrare de resurse ca fiind ANY s, i nu va găsi niciun rezultat. Interogarea
instant, ei de PowerDNS se va face cu ajutorul IP-ului expus extern de Kubernetes. Acesta poate
fi găsit utilizând comanda kubectl get services”, urmărind valoare câmpului de EXTERNAL
”
IP ce corespunde serviciului numit pdns.

Un lucru important de ment, ionat este că instant, a de PowerDNS funct, ionează ca un name
server master ce va trebui configurat de client, ı̂n funct, ie de ceea ce dores, te să facă cu
produsul. De asemenea, ı̂n aceeas, i sferă de idei, fiind o implementare la stadiul de prototip,
name serverul nu poate rezolva ı̂n Internet, fapt pentru care interogarea trebuie realizată direct
către acesta.

5.5 Monitorizarea aplicat, iei

În cadrul monitorizării aplicat, iei, se vor ı̂ntâlni trei componente principale: PostgreSQL
Exporter, Prometheus s, i Grafana.

5.5.1 Servirea informat, iilor din bazele de date

Serviciul de tip exporter se ocupă cu preluarea datelor din tabelele dorite, ce apart, in de
PostgreSQL, s, i servirea lor către instant, a de Prometheus. Acest lucru este posibil cu ajutorul
modificării la nivel de configurare a cererilor de tip interogare (query). Pentru acest prototip
s-a ales exportarea numărului de zone din baza de date. Init, ial s-au exportat s, i numele zonelor
s, i o listă a ı̂nregistrărilor de resurse, dar s-a renunt, at la aceste metrici din cauza faptului că
utilizatorul poate vedea deja aceste informat, ii, prin intermediul punctelor de acces puse la
dispozit, ie de componentele ce se ocupă cu orchestrarea informat, iilor s, i rezolvarea cererilor.

Pentru această componentă s-a folosit o imagine open source, căreia i s-a adăugat conexiunea

16
cu baza de date s, i fis, ierul ce cont, ine interogări personalizate către baza de date, fat, ă de cele
deja puse la dispozit, ie.

Metricile expuse de PostgreSQL Exporter, ı̂n cazul prototipului s, i al experimentelor create cu

acesta, pot fi observate accesând http://metrics.test-dnsaas.com/metrics.

Imaginea de bază pentru PostgreSQL Exporter este wrouesnel/postgres exporter:v0.8.0.

5.5.2 Monitorizarea folosind Prometheus

Prometheus este un set de utilitare open source de monitorizări s, i alerte.” [10] Acesta poate
”
monitoriza, printre altele, baze de date, servere s, i containere. Pentru a realiza acest lucru,
Prometheus va trimite cereri Http printr-un punct de acces specific, definit ı̂n configurările
sale, s, i va as, tepta răspunsul, respectiv informat, iile dorite de utilizator.

Ca exemplu, ı̂ntr-un posibil scenariu, o aplicat, ie locală, care poate fi accesată de utilizator
s, i servicii la http://localhost:8080, va expune către Prometheus datele sub format text la
http://localhost:8080/metrics. [10] După un anumit interval configurat de dezvoltator (numit
s, i scrape time), Prometheus va interoga punctul de acces specific. Atât aplicat, ia cât s, i
Prometheus trebuie configurate pentru a putea fi posibil acest schimb de informat, ii.

Acesta comunică cu componenta de PostgreSQL Exporter, cât s, i cu componenta de Gateway.

Mai precis, la fiecare interval de treizeci de secunde, aceasta accesează punctul de acces de
/metrics, expus de ambele aplicat, ii, colectează datele s, i, mai departe, informat, iile vor putea
fi observate, ı̂n cazul prototipului s, i ı̂n experimentele create cu acesta, direct ı̂n Prometheus,
accesând http://metrics.test-dnsaas.com/prometheus.

Conexiunea cu PostgreSQL Exporter s, i instant, a Gateway esteı̂ntocmită la nivel de configurat, ie,

iar punctul de acces specific, /metrics, este setat la nivel programatic, ı̂n cea de-a doua com-
ponentă numită. De asemenea, la nivel de Deployment, acestea sunt setate să ı̂ntoarcă datele
către Prometheus, la cererile Http primite.

Deployment-ul de Prometheus cont, ine un volum persistent (Kubernetes Persistent Volume)

pentru stocarea măsurătorilor.

Imaginea docker de bază, folosită pentru Prometheus, este prom/prometheus:v2.1.0.

5.5.3 Expunerea informat, iilor de monitorizare ı̂n interfat, a de Grafana

Prometheus, subiect pe care l-am acoperit ı̂n paragraful anterior, este un utilitar nativ de
”
stocare a datelor ı̂n Grafana”[5]. Cea din urmă reprezintă o solut, ie prietenoasă cu utilizato-
rul s, i intuitivă pentru crearea de tabele vizuale, pentru observarea informat, iilor colectate de
Prometheus.

Grafana este o aplicat, ie interactivă de creare s, i vizualizare de panouri cu informat, ii referitoare

17
la starea sau performant, a unui sistem sau componente ale sistemului. Ea oferă diferite variante
de panouri de tip graf, diagramă, tabelă s, i alertă pentru sursele de date configurate, ce se
ocupă cu colectarea s, i persistent, a datelor. [5]

Cum punctul de acces de tip /graph cont, inut de Prometheus nu oferă o interfat, ă prietenoasă
cu utilizatorul, us, or de citit sau interpretat, s-a decis adăugarea unei instant, e de Grafana.

Instant, a, ı̂n cazul prototipului s, i ı̂n experimentele create cu acesta, poate fi accesată la
http://metrics.test-dnsaas.com/monitoring-grafana. Pagina de pornire va fi cea de login.
Numele de utilizator pentru autentificare este admin”, iar parola este dnsaas”. Utilizatorul
” ”
ı̂s, i poate schimba parola, modificând ı̂n fis, ierul de configurare, după instruct, iunile de utili-
zare din fis, ierul de tip README. După autentificare, utilizatorul va fi redirectat către panoul
Home, ı̂n care va putea să ı̂s, i construiască panourile de interes, după metricile pe care vrea
să le urmărească. Aceste panouri se realizează us, or, intuitiv, iar pentru suport suplimentar,
ı̂n fis, ierul de documentat, ie, au fost atas, ate link-uri utile.

Setarea componentei de Prometheus ca sursă de date pentru Grafana este realizată la nivel
de configurat, ie, iar acest fapt ı̂nseamnă că utilizatorul va avea toate setările pregătite atunci
când instant, ele vor rula, iar pericolul s, tergerii acestei surse de date este inexistent, deoarece
sursele adăugate la nivel de configurare sunt imutabile la nivel de interfat, ă de Grafana.

Deployment-ul de Grafana cont, ine un volum persistent (Kubernetes Persistent Volume) pentru
stocarea măsurătorilor.

Imaginea Docker de bază, folosită pentru Grafana, este grafana/grafana:6.3.0.

5.6 Componenta de Gateway

5.6.1 Implementarea folosind Spring Boot Framework

Java Spring Boot este o unealtă pentru construirea de aplicat, ii web s, i microservicii inde-
pendente cu ajutorul (Java) Spring Framework. Spring Framework este un framework open
source pentru crearea componentelor descrise anterior, ce pot rula pe un JVM (Java Virtual
Machine) s, i permite integrarea cu alte tehnologii Java existente. Acesta permite dezvoltato-
rului să creeze componente slab cuplate, independente s, i portabile. [11]

Aceste componente slab cuplate ı̂ntre ele s, i care pot fi testate s, i dezvoltate independent unele
fat, ă de celelalte se numesc microservicii. Fiecare microserviciu are ı̂n rulare propriul proces,
ceea ce ı̂l face simplu de scalat s, i dezvoltat, compatibil cu Docker sau solut, ii similare de rulare
ı̂n containere s, i, prin urmare, pot fi văzute efecte benefice ı̂n timpul de construire a unei astfel
de aplicat, ii.

Spring Boot oferă conceptul de injectare a dependint, elor. Acesta face referire la obiectele
cărora li se permite să ı̂s, i definească propriile dependint, e, pe care Spring Boot le va injecta la

18
crearea contextului.

Componenta de Gateway, cât s, i cele responsabile de orchestrarea s, i stocarea datelor sunt

construite cu ajutorul Spring Boot. Cum serviciile ce t, in de logică sunt componente interne,
care t, in de compania cu care s-a realizat prezenta lucrare, ı̂n acest subcapitol se va aduce ı̂n
prim-plan componenta de Gateway.

Spring Boot oferă configurarea us, oară s, i intuitivă printr-o serie de adnotări. Adnotarea @Ena-
bleAutoConfiguration este utilizată pentru ı̂ncărcarea automată a dependint, elor adăugate ı̂n
fis, ierul pom. Cum este ı̂n discut, ie un proiect scris ı̂n Java, există un punct de intrare al
aplicat, iei. Acestă metodă main trebuie adnotată cu @SpringBootApplication, pentru a fi re-
cunoscută astfel. De asemenea, o altă adnotat, ie standard este @ComponentScan ce se ocupă
cu scanarea componentelor, respectiv caută ı̂n proiect adnotări de tipul @Component, @Con-
figuration, @Service, @Controller, precum s, i altele, s, i, ı̂n contextul aplicat, iei, construies, te o
singură instant, ă (denumită s, i Bean) a fiecărui obiect de tipul clasei adnotate. De asemenea,
va căuta s, i adnotările de tipul @Bean care pot fi regăsite pe metode, având acelas, i efect. În
continuare, acestea sunt legate” ı̂n cadrul altor componente prin adnotat, ia @Autowired. [11]
”
Pe lângă regulile amintite anterior, componenta de Gateway defines, te o configurare de filtrare
a traficului, semnalată prin adnotarea @Configuration. Mai multe detalii despre această parte
vor fi acoperite ı̂n subcapitolul următor, ce abordează subiectul Maven.

Componenta de Gateway este cea care primes, te toate cererile Http ce se ocupă de orches-
trarea datelor. Aceasta, mai departe, stabiles, te după regulile de filtrare a traficului, după
numele de utilizator s, i parolă, s, i după regulile de redirectare definite ı̂n fis, ierul de configurare
application.yaml, unde trebuie să fie trimisă mai departe cererea.

Punctele de acces s, i posibilele răspunsuri sunt următoarele:

• POST /zones/zoneName - adăugarea zonei

– ı̂ntoarce corpul zonei create sau răspuns de eroare
– 200 Ok - Cererea a fost realizată cu succes
– 401 Unauthorized - Date de autentificare invalide
– 400 Bad Request - Câmpuri invalide
– 409 Conflict - Zona există deja
– 500 Internal Server Error - Eroare internă
• PUT /zones/zoneName - modificarea zonei la nivel de ı̂nregistrări de resurse DNS
– poate ı̂ntoarce răspuns de eroare
– 200 Ok - Cererea a fost realizată cu succes
– 401 Unauthorized - Date de autentificare invalide
– 400 Bad Request - Pentru câmpuri invalide
– 404 Not Found - Zona nu există
– 409 Conflict - Zone există deja
– 500 Internal Server Error - Eroare internă

19
 • GET /zones/zoneName - obt, inerea informat, iilor despre o zonă
– ı̂ntoarce zona găsită sau răspunsul de eroare
– 200 Ok - Cererea a fost realizată cu succes
– 401 Unauthorized - Date de autentificare invalide
– 404 Not Found - Zona nu există
– 500 Internal Server Error - Eroare internă
• GET /zones - obt, inerea o listă cu toate zonele
– ı̂ntoarce zonele găsite, o listă goală, ı̂n cazul ı̂n care acestea nu există, sau răspuns
de eroare
– 200 Ok - Cererea a fost realizată cu succes
– 401 Unauthorized - Date de autentificare invalide
– 500 Internal Server Error - Eroare internă
• DELETE /zones/zoneName - s, tergerea informat, iilor despre o zonă
– poate ı̂ntoarce răspuns de eroare
– 200 Ok - Cererea a fost realizată cu succes
– 401 Unauthorized - Date de autentificare invalide
– 404 Not Found - Zona nu există
– 500 Internal Server Error - Eroare internă

Metodele de POST s, i PUT necesită corp al cererii. Acesta, ı̂mpreună cu mai multe informat, ii
despre aceste cereri, sunt definite ı̂n fis, ierul de documentat, ie.

Motivul alegerii acestei tehnologii face referire la us, urint, a dezvoltării s, i testării microserviciilor
singulare, dar s, i ı̂n comuniune cu alte microservicii cu care comunică, pentru ı̂ndeplinirea
cererilor. De asemenea Spring Boot se integrează facil cu alte tehnologii, un exemplu fiind
Maven, subiect acoperit ı̂n cele ce urmează.

Versiunea de Spring Boot Framework folosită este 2.3.6.RELEASE.

5.6.2 Construirea JAR-ului folosind Maven

Maven este un instrument de automatizare a proiectelor Java. Spre deosebire de alte solut, ii
asemănătoare, Maven este mult mai versatil s, i us, or de utilizat. [6]

Acesta este un proiect stabil open source, care expune seturi de dependint, e, conectate la
depozite la distant, ă, s, i face posibilă instalarea lor, ı̂ntr-un mod automat, prin intermediul
comenzilor pe care le pune la dispozit, ie.

Fiecare proiect Maven are un fis, ier de tip POM (Project Object Model) ce funct, ionează
ca o ret, etă ı̂n construirea fis, ierului Java de tip JAR (Java ARchive). Acest fis, ier POM
cont, ine detaliile proiectului, precum numele, versiunea, dependint, ele sau plugin-uri folosite.
Minimul de informat, ii pe care ı̂l are este rădăcina proiectului (project), versiunea proiectului din

20
punct de vedere al dezvoltării (modelVersion), identificatorul grupului din care face proiectul
(groupId), identificatorul proiectului (artifactId), versiunea proiectului din punct de vedere al
identificatorului proiectului din cadrul grupului (version). Maven formează un identificator pe
baza câmpurilor groupId, artifactId s, i version. [6]

Fis, ierul Maven pune la dispozit, ie conceptul de mos, tenire, prin care se poate defini un părinte al
proiectului, din care se pot extrage definit, ii s, i atribute. Acesta este utilizat ı̂n cadrul proiectelor
de Spring Boot. Prin specificarea părintelui de tip spring-boot-starter-parent din grupul de
Spring Boot Framework (org.springframework.boot), va fi posibilă configurarea de plugin-uri
s, i dependint, e de bază pentru construirea proiectului.

În ceea ce prives, te dependint, ele, ı̂n cazul proiectelor mari, se preferă adăugarea celor de tip
starter, care ı̂nglobează o familie de dependint, e. Spre exemplu, spring-boot-starter-jpa se
foloses, te pentru conexiunea la bazele de date.

În componenta de Gateway, dependint, a de interes folosită este Spring Security Webflux, cu
o configurare a autentificării pe bază de nume de utilizator s, i parolă, ı̂n port, iunea de cod
ce a fost semnalată cu adnotarea @Configuration. De asemenea, este necesară specificarea
utilizării serviciilor de securitate puse la dispozit, ie de Spring Security Webflux. Acest lucru
este posibil prin adăugarea adnotării @EnableWebFluxSecurity alături de cea de configurare.

Această dependint, ă, cu ajutorul componentei de configurare pentru regulile de filtrarea a

traficului ce este primit de componentă, se ocupă de partea de redirectare s, i autentificare.

Regulile de redirectare se fac ı̂n funct, ie de calea primită, ı̂n fis, ierul de configurare a aplicat, iei
de Spring Boot. Dependint, ele, la fel ca plugin-urile, se găsesc ı̂n fis, ierul de tip POM. Un
exemplu de dependint, ă folosită este următorul:
<dependency >
<g r o u p I d >o r g . s p r i n g f r a m e w o r k . boot </g r o u p I d >
< a r t i f a c t I d >s p r i n g −boot−s t a r t e r −s e c u r i t y </ a r t i f a c t I d >
</dependency >

Aceasta ı̂nglobează funct, ionalităt, ile de securitate folosite, incluzând s, i Spring Security We-
bflux. S-a ales păstrarea acestei dependint, e, pentru viitoare modificări ı̂n această arie de
securitate de aplicat, iei.

Maven construies, te contextul proiectului ı̂n directorul numit target.

Utilitarul pune la dispozit, ie o serie de comenzi, pentru lucrul cu proiectele Java. Dintre acestea
vor fi amintite cele mai utilizate ı̂n cadrul construirii componentei de Gateway:

• clean - elimină cont, inutul directorului target

• test - rulează suita de teste din cadrul proiectului
• install - construies, te contextul s, i JAR-ul, descarcă dependint, ele ı̂n directorul de lucru

Astfel, s-a ales Maven pentru că este o solut, ie ce vine ı̂n ajutorul dezvoltatorului, fiind us, or

21
de utilizat, instalat s, i ment, inut. De asemenea, documentat, ia este vastă, dependint, ele s, i
plugin-urile puse la dispozit, ie sunt us, or de găsit s, i ı̂ncărcat ı̂n proiectul de Spring Boot.

Versiunea folosită a acestui utilitar este Apache Maven 3.6.0.

5.6.3 Implementarea componentei folosind Java

Java este un limbaj de programare orientat pe obiecte s, i bazat pe clase. Acesta dispune de un
sistem automat de organizare a memoriei. Este un limbaj concurent, portabil pe orice sistem
ce cont, ine mediul necesar, respectiv o mas, ină virtuală Java (JVM) instalată.

Motivul alegerii acestui limbaj de programare este simplitatea ı̂n modularizarea s, i scrierea co-
dului ı̂n clase ce respectă principiile SOLID. Acest aspect face adăugarea de noi funct, ionalităt, i
facilă, cu modificări minime ı̂n codul deja existent. Codul este robust s, i scalabil. De asemenea
Java este unul dintre cele mai populare limbaje de programare pentru că are beneficiază de
un număr ridicat de biblioteci compatibile, open source, ce facilitează lucrul cu logging-ul,
”
obiecte de tip JSON, fis, iere XML”5 s, i altele. Java dispune de o varietate de framework-uri,
printre care s, i Spring, subiect dezvoltat anterior. Sistemul de organizare automată a memoriei
ı̂l face un limbaj mai prietenos decât alte limbaje, spre exemplu C/C++, des, i sintaxa acestor
limbaje este asemănătoare.

Versiunea de Java folosită pentru scrierea componentei de Gateway este Java11.

5.7 Stocarea datelor

PostgreSQL s, i MSQL sunt două sisteme open source de gestiune a bazelor de date relat, ionale.
Acestea sunt folosite pentru stocarea datelor ı̂n cadrul aplicat, iei, comunicând cu cele două
entităt, i interne ce compun ı̂mpreună unitatea logică (ce va fi tratată ca o cutie neagră) s, i
rezolvă cererile.

PostgreSQL permite mai multor entităt, i să scrie s, i să citească din aceeas, i resursă. 6 Acesta
este un sistem us, or de utilizat, compatibil cu un număr mare de limbaje de programare.

Baza de date MySQL este necesară pentru a putea expune informat, iile despre ı̂nregistrările
de resurse DNS, prin intermediul componentei de PowerDNS. În esent, ă serverul de PDNS se
conectează la o instant, ă de MySQL, conform documentat, iei 7 .

Baza de date PostgreSQL comunică cu unitatea de găzduire, care este o componentă mai
complexă decât cea de procesare. Din acest motiv are nevoie de o flexibilitate mai mare ı̂n
ceea ce prives, te controlul datelor, motivând modalitatea de stocare a informat, iilor ment, ionată
anterior.
5
https : //scand.com/company/blog/why − use − java − f or − back − end − development (24.06.2021)
6
https : //www.simplilearn.com/tutorials/sql − tutorial/postgresql − vs − mysql (25.06.2021)
7
https : //doc.powerdns.com/authoritative/backends (20.06.2021)

22
Astfel, aceste două baze de date au fost alese ı̂n funct, ie de nevoile componentelor cu care
comunică, mergându-se pe principiul de simplitate, cum un microserviciu este o unitate logică
ce se ocupă de un singur lucru.

23
6 EVALUAREA CERINT, ELOR
În capitolul ce urmează, vor fi discutate detaliile de funct, ionalitate, surprinse pe baza cerint, elor
init, iale.

Disponibilitatea aplicat, iei depinde de mediul ı̂n care va fi instalată, respectiv un cluster de
Kubernetes (o instant, ă de Managed Kubernetes regăsită ı̂n componenta de cloud sau un
cluster local). Sistemul de monitorizare, afis, at prin interfat, a de Grafana, propune posibilitatea
de a lăsa utilizatorului capacitatea de a observa metrici despre componentele sale, printre
acestea fiind inclusă disponibilitatea Pod-urilor sau intervalul de răspuns, surprinse ı̂n timp
real.

Dacă disponibilitatea face referire, ı̂n sens mai restrâns, la informat, ii salvate, ı̂n cazul datelor
din bazele de date, colectate de instant, a de Prometheus sau observate ı̂n interfat, a de Gra-
fana, atunci acestea vor fi persistente la nivel de restartare a Pod-urilor de Kubernetes, fiind
asigurate de volume persistente (Kubernetes Persistent Volume) la nivelul nodului, conform
documentat, iei 1 .

Serviciile sunt disponibile oriunde ı̂n lume, ı̂n cazul ı̂n care clientul optează pentru a folosi
Kong Api Gateway s, i, prin urmare, a-i asigna un domeniu valid ı̂n Internet.

În varianta aceasta este propus s, i experimentul. S-a observat, cu ajutorul utilitarului gratuit de
verificare a disponibilităt, ii oferit de uptrends, ce poate fi accesat la https://www.uptrends.com,
că serviciul este disponibil ı̂n locat, ii din toată lumea, timpul de răspuns variind ı̂n funct, ie de
regiune. Printre alte circumstant, e, acesta depinde s, i de cât de ı̂ndepărtat este name serverul
cel mai apropiat, pus la dispozit, ie de furnizorul de servicii, ı̂n acest caz 1&1 Ionos.

Lista ı̂ntreagă a locat, iilor din care s-a testat, este disponibilă pe site, dar din ea vor fi amintite:

• Berlin, Haarlem cu un timp mai mic 0.1s

• Milan, Palermo, Tel Aviv cu un timp mai mic sau egal de 0.3s
• New York cu un timp de aproximativ 0.4s
• Montreal, San Diego, Tampa cu un timp cuprins ı̂ntre 0.5s s, i 0.6s
• Seattle, Jakarta cu un timp de aproximativ de 0.7s
• Tokyo, New Delhi, Honolulu cu un timp de aproximativ de 1.1s
• Los Angeles cu un timp aproximativ de 1.2s
• Singapore, Seoul cu cel mai mare timp de aproximativ de 1.4s
• Beijing cu cu cel mai mare timp de aproximativ de 1.6s

Din măsurători se poate observa un timp minim de până ı̂n 0.1s s, i un maxim de până ı̂n
1
https : //kubernetes.io/docs/concepts/storage/persistent − volumes (28.06.2021)

24
1.6s, ı̂n funct, ie de numărul de servere din zona respectivă s, i apropierea de punctul din care se
efectuează cererea ori chiar de aglomerarea numărului de cereri către acelas, i name server.

Valorile măsurătorilor exprimate ı̂n cifre sunt o medie a zece rulări ı̂n momente de timp diferite
ale zilei, eliminând rezultatele anormale. Rezultatele anormale pot surveni, printre alte motive,
din cauza numărului mare de cereri ce trec prin aceleas, i puncte, fiind afectat procesul de rutare,
corelat cu anumite momente ale zilei.

Odată cu cres, terea valorilor timpului de răspuns, timpul de descărcare reprezintă cea mai mare
parte, după cum poate fi observat ı̂n graficul următor:

Figura 2: Timpul de răspuns

De asemenea, ı̂n cazul Los Angeles, se poate remarca faptul că timpul de rezolvare este mai
mare fat, ă de tendint, ă. Acest fapt se poate datora distant, ei ı̂nsemnate fat, ă de name serverul
cel mai apropiat ori poate un număr ridicat de cereri ı̂n acea arie. Complementar, ı̂n Beijing,
Berlin, Haarlem, Milan, Palermo, timpul de rezolvare este aproape zero.

Pentru instalarea programelor de bază, informat, ii despre utilizarea API-ului s, i autentificarea pe

bază de nume de utilizator s, i parolă pentru instant, a de Grafana s, i aplicat, ie ı̂n sine, utilizatorul
va avea la dispozit, ie un document atas, at. I se va prezenta ce poate modifica ı̂n suita de fis, iere
de configurare puse la dispozit, ie pentru instalare, cum poate utiliza API-ul, ce răspunsuri poate
primi, cum poate interoga instant, a de PowerDNS, pentru verificări suplimentare, s, i interogări
ale instant, elor de monitorizare.

Executabilul este pus la dispozit, ia utilizatoruluiı̂n directorul părinte. În partea de documentat, ie
va fi specificat numele său, unde se găses, te s, i cum poate fi pornit. După nevoi, utilizatorul ı̂l

25
poate modifica, dacă, spre exemplu, dores, te să ı̂s, i instaleze cu ajutorul lui ı̂nainte de aplicat, ie,
serviciile necesare rulării acesteia. Executabilul se va ocupa de instalarea aplicat, iei pe mediul
de lucru.

26
7 CONCLUZII
Prezentul proiect ı̂s, i ı̂ndeplines, te menirea de prototip. Acesta oferă o posibilă solut, ie pentru
ı̂mpachetarea unui serviciu de tip DNS ı̂ntr-un mediu de cloud. Arhitectura descrisă ı̂mbină
tehnologiiı̂n continuă dezvoltare, ce pot fi cu us, urint, ă documentate s, i alăturate altor tehnologii
pe viitor, datorită versatilităt, ii lor, după cum au fost prezentate. De asemenea, prototipul
propune concepte s, i funct, ionalităt, i ce pot fi mai departe extinse la nivel de caracteristici DNS
(spre exemplu ar putea fi adăugate proprietăt, i de tipul DNSSEC, DNS Pro).

Aplicat, ia este disponibilă oriunde ı̂n lume, ı̂ntr-un timp de răspuns mediu de până ı̂n 2s. Datele
pe care le stochează sunt persistente. Documentat, ia pusă la dispozit, ie oferă explicat, ii despre
cum poate fi utilizată s, i modificat accesul la nivel de autentificare. Este us, or de instalat s, i
dezinstalat.

7.1 Contribut, ii

În lista de mai jos pot fi observate contribut, iile necesare ı̂ntocmirii rezultatului final:

• colectat cerint, e funct, ionale

• citit literatura din domeniu
• proiectat arhitectura
• ales tehnologii comparând nevoile cu solut, iile existente
• incorporat s, i modificat componentele de logică, interne companiei partenere
• ı̂mpachetat solut, ia pentru instalare us, oară
• implementat prototip ce respectă setul de cerint, e
• evaluat solut, ia
• descoperit probleme ce trebuie tratate ı̂n viitor

7.2 Dezvoltări viitoare

În viitor este de dorit ca stocarea datelor să nu se mai facă ı̂n cadrul clusterului, fiind com-
ponenta care ocupă cea mai multă memorie s, i, poate, cea mai importantă, ı̂n cazul pierderii
informat, iilor. De asemenea, trebuie regândit modul de extragere al imaginilor Docker utilizate
s, i expunerea datelor de autentificare, aspecte ce, ı̂n acest stadiu, au efecte asupra securităt, ii.
La nivel de accesibilitate, se poate lucra la o variantă ce va permite mai multor utilizatori să
beneficieze de aceeas, i aplicat, ie, după dorint, ă, dar fiecare să aibă acces doar la datele sale.

27
BIBLIOGRAFIE
[1] Google. Cloud dns.

[2] Designate OpenStack. Designate, a dnsaas component for openstack, 2014.

[3] Martin Pamatarov. Linux dig command, how to install it and use it, 05 1012.

[4] Martin Pamatarov. What is a dns zone? master and slave dns zone and how to create
it, 02 2020.

[5] Elvis Plesky. What is grafana? a look at its most important features for effective
monitoring, 11 2020.

[6] Scott Robinson. What is maven?, 06 2021.

[7] Amazon Web Services. Amazone route 53.

[8] API Strategy. How to choose the right api gateway for your platform, 03 2019.

[9] XiaoYing Bai Yu Huang WeiTek Tsai. Software-as-a-service (saas): perspectives and
challenges. 57, 2014.

[10] James Turnbull. Monitoring with Prometheus. Turnbull Press, 2018.

[11] Craig Walls. Spring Boot in action. Manning Publications, 2016.

28