Differences

This shows you the differences between two versions of the page.

Link to this comparison view

rl:labs:06 [2019/10/08 15:16]
georgiana.trifu [Exerciții]
rl:labs:06 [2022/11/08 23:03] (current)
florin.stancu [Pregătire infrastructură de laborator]
Line 1: Line 1:
 ~~NOTOC~~ ~~NOTOC~~
  
-====== Laborator 6. Amazon Web Services ​======+====== Laborator 6. Virtualizare în Docker ​======
  
 ===== Cunoștințe și abilități ce vor fi dobândite ===== ===== Cunoștințe și abilități ce vor fi dobândite =====
  
-  * Administrarea resurselor cloud folosind consola grafică. +  * Cloud Privat / OpenStack 
-  * Securitate ​în cloud. +  * Intoducere ​în Docker CLI 
-  * Configurarea rutării în cloud. +  * Docker Container vs Docker Image 
-  * Accesarea serviciilor de transfer de fișiere (FTP).+  * Dockerfile ​și construcția de Imagini 
 +  * Union File System: Overlay2 - image layers 
 +  * Docker Volumes 
 +  * Docker Networking: bridge & overlay ​(VXLAN) 
 +  * Docker SWARM 
 +  * Introducere în arhitecturi pe microservicii 
 +  * Arhitecturi pe microservicii vs Arhitecturi monolite
  
-===== Pregătire infrastructură de laborator ​=====+===== Cheat sheet =====
  
-  * Vom crea o infrastructură de rețea ​ în cloud-ul Amazon. +  * {{:rl:​rl_cheatsheet.pdf|Cheat Sheet}}
-  * Fiecare student are creat un cont în [[https://​073736590675.signin.aws.amazon.com/​console?​region=eu-west-1 ​cloud-ul Amazon]]. Pentru a vă loga în contul asignat veți primi fiecare o parolă din partea asistentului de laborator. ​+
  
 +===== Pregătire infrastructură de laborator =====
  
-===== Prezentare concepte =====+<​hidden><​note warning>
  
-Servicii de cloud existente: Amazon Web Services, Google Cloud Platform șMicrosoft Azure.+**Creaț2 mașini virtuale.**
  
-Mai departe discutăm despre AWS; serviciile pe care le vom folosi în cadrul laboratorului:​ +Folosiți imaginea ​**Ubuntu 16.04 Xenial** cu flavor **m1.medium** pe [[https://​cloud-controller.grid.pub.ro/​dashboard|Openstack]].
-  ​Compute: EC2 +
-  ​Networking and Content DeliveryVPC+
  
-Alte servicii în cloud-ul Amazon: +Atenție ! Utilizatorul ​**NU** este **student**, ci **ubuntu**.
-  ​Storage - Amazon Simple Storage Service (Amazon S3) +
-  ​Database +
-  ​Machine Learning +
-  ​Analytics +
-  ​AR&VR +
-  ​Mobile+
  
-EC2 (Amazon Elastic Compute Cloud) oferă capacitate dinamică computațională în cloudDe asemenea, pentru a dezvolta și lansa aplicații nu mai ai nevoie să îți achiziționezi hardware-ul, acest serviciu punându-ți la dispozițieservere virtuale, configurarea securității și networking, ajustarea spațiului de stocare.+<code bash> 
 +ubuntu@hostname:​~#​ sudo apt-get update 
 +ubuntu@hostname:​~#​ sudo apt-get install docker 
 +ubuntu@hostname:​~#​ sudo apt-get install docker.io 
 +ubuntu@hostname:​~#​ cat /​etc/​hostname 
 +$MY_HOSTNAME 
 +ubuntu@hostname:​~#​ cat /​etc/​hosts ​  # Adăugați linia următoare în fișierul /​etc/​hosts 
 +127.0.0.1 $MY_HOSTNAME 
 +[...] 
 +ubuntu@hostname:​~#​ sudo usermod ​-aG docker $USER 
 +ubuntu@hostname:~# exit # LOGOUT
  
-{{:rl:labs:virtual_private_cloud.png?200 | }} \\  ​+$FEP_USER@fep.grid.pub.ro:~$ ssh -i ~/.ssh/id_rsa ubuntu@$VM_IP_ADDRESS # LOGIN
  
-Virtual Private Cloud te ajută să pornești resursele Amazon într-o rețea virtuală definită de tine. Această rețea seamănă cu o rețea tradițională unde poți configura spații de adrese, tabele de rutare, gateways și setări de securitate, dar are în plus beneficiile utilizării unui infrastructuri scalabile precum AWS. Fiecare VPC creat este izolat logic de oricare alt VPC din cloud. +</code>
- +
-Fiecare cont Amazon vine cu un VPC prestabilit pentru a putea să folosești resursele Amazon fără să îți construiești infrastructura de la zero. O diagrama simplă pentru un VPC avem în alăturată. +
- +
-Două sau mai multe VPC-uri pot comunica atâta timp cât se află în aceeași regiune. În plus VPC-urile ale căror blocuri de adrese IP se suprapun nu pot comunica. \\  \\   +
- +
-3 tipuri de adrese IP: +
-  * adrese IP private +
-  * adrese IP publice. O adresă publică ce a fost atribuită unei instanțe pe care am închis-o va reveni în pool-ul inițial de adrese. Când vom reporni instanța, aceasta va avea o altă adresă IP publică. +
-  * adresă IP publică statică este o adresă IP publică statică -  una sau mai multe adrese IP publice statice pot rămâne asociate contului tău Amazon până în momentul în care alegi să renunți la ele. +
- +
-<note tip> +
-Care era diferența între adrese IP private și adresele IP publice?+
 </​note>​ </​note>​
 +</​hidden>​
  
-Subnet ​interval de adrese IP într-un VPCPoți să lansezi resursele Amazon într-un subnet ​pe care îl creezi, la alegere.+<note important>​ 
 +În cadrul laboratorului vom utiliza [[:​rl:​info:​resurse:​vm-laborator|OpenStack-ul facultății]] SAU, dacă întâlnim probleme, [[https://​labs.play-with-docker.com/​|Play with Docker]] o platformă online pusă la dispoziție de Marcos Liljedhal șJonathan Leibiusky și sponsorizată de Docker Inc. Pentru uz personal recomandam insa instalarea Docker ​pe calculator sau folosirea unei mașini virtuale.
  
-În Amazon avem două tipuri ​de subnets: +Pentru instalarea Docker pe Ubuntu urmăriți procedura ​de aici [1]Suplimentar față de pașii descriși anterior, rulați comanda: 
-  * Publice (atunci când resursele trebuie să aibă acces direct în Internet, de exemplu serverele web)Un subnet este făcut public atunci când există o rută în tabela ​de rutare care trimite traficul în Internet printr-un Internet Gateway. +''​sudo usermod ​-aG docker $USER''​ 
-  * Private (atunci când resursele nu trebuie să aibă acces direct în Internet, de exemplu bazele de date)+ desprinsă din documentația [2]
  
-<note important>​ +  * [1] https://​docs.docker.com/​install/​linux/​docker-ce/ubuntu/ 
-În fiecare subnet, primele 4 adrese IP și ultima adresă IP nu pot fi folosite de utilizatori: +  * [2] https://​docs.docker.com/​install/​linux/​linux-postinstall/​
-  * Prima este adresă de rețea +
-  * A doua este rezervată pentru ruter-ul VPC-ului +
-  * A treia este rezervată de AWS pentru serverul DNS (în general adresa de rețea a subnet-ului plus doi) +
-  * A patra este rezervată de AWS pentru viitoare utilizări +
-  * Ultima este adresa de broadcast+
 </​note>​ </​note>​
  
-Internet Gateway. IGW este o componentă a VPC-ului care permite comunicarea între instanțele din VPC și Internet. Pentru a comunica cu o instanță din subnet-ul public, este necesar ca instanța să aibă alocată o adresă IP publică statică. \\ +===== Introducere =====
  
-<note warning+<hidden
-Poțcrea un singur obiect IGW per VPC+Iată că ne regăsim la sfârșitul semestrului I din anul 3, după o lungă șdificilă călătorie prin tainele ingineriei Calculatoarelor,​ traseu ce a adus în planul de studiu și materia Rețele locale.  
-</note>+</hidden>
  
-Tabela de rutare. Fiecare subnet dintr-un VPC trebuie să aibă asociată o tabelă de rutare. Un subnet poate fi asociat numai cu singură tabelă de rutare ​la un moment datdar o tabelă ​de rutare poate fi asociată cu mai multe subnet-uri.+Întrucât, preponderența claselor din anii anteriori a fost cu precădere orientată pe multe din aspectele complexe ale dezvoltării de software, în laboratorul de azi ne propunem să oferim ​altă perspectivă în conceperea unei aplicații sau a unei soluții. Aspecte precum **volumul de date de procesat**, **toleranța ​la defecte****portabilitatea** sau **scalabilitatea** sunt constrângeri esențiale care trebuie tratate în procesul ​de implementare a unei soluții sau aplicații
  
-{{:​rl:​labs:​nat_device.png?200 |}}+Standardele și cerințele dictate de industrie se focalizează din ce în ce mai mult pe adoptarea modelului de cloud, menit, de cele mai multe ori, să ofere un șablon/​pattern care să adreseze parțial sau integral constrângerile (sau oportunitățile) menționate anterior
  
-Pentru ca instanțele create într-un subnet privat să acceseze Internetul (dar să nu fie accesate din Internet) putem folosi un obiect AWS numit NAT Device (Network Address Translation Device). +Laboratorul curent își propune o introducere pragmatică ​în modele clasice ​de system design & architecture încercând ​să atingă gradual mici elemente ​de complexitate,​ care pot aduce un plus de valoare unei aplicații în contextul de cloud. ​
-(exemplu: web serverul este în subnet-ul public ​și baza de date în subnet-ul privat. Baza de date s-ar putea să aibă nevoie ​de conexiune la Internet)+
  
-NAT Gateway - serviciu AWS de management al traficului. Folosim un NAT Gateway ​pentru ​a permite instanțelor dintr-un subnet privat să aibă acces la Internet ​sau la alte servicii AWS și în același timp pentru a fi inițiate conexiuni din Internet către stațiile din acel subnet.+Modelele prezentate pot fi puncte ​de plecare importante ​pentru ​parcurgerea unor interviuri de Site Reliability Engineer, Cloud Engineer ​sau DevOps Engineer
  
-{{:​rl:​labs:​security_group.png?100 |}}+Mai mult, laboratorul deservește,​ în egală măsură, o introducere în Docker, Docker Networking & Docker Orchestration,​ facilitând implementarea graduală a unui serviciu web, de la concept până într-o formă care ar putea răspunde unor cerințe reale de producție. Laboratorul se adresează în egală măsură atât oamenilor cu înclinații către dezvoltare cât și oamenilor care se orientează spre poziții operaționale.
  
-Un Security Group acționează ca un firewall virtual care controlează traficul pentru una sau mai multe instanțe. Putem adăuga reguli pentru fiecare Security Group care să permită traficul către/de la instanțele asociate.+**Ben Treynor** //VP of Engineers @ Google// și inventatorul termenului **Site Reliability Engineer** încercând ​să definească conceptul:​ 
 +//"​Fundamentally,​ it’s what happens when you ask a software engineer to design an operations function"/​/
  
-Prestabilit,​ fiecare Security Groups permite tot traficul ​de ieșire. Regulile unui Security Group sunt întotdeauna permisive (nu putem adăuga o regulă de „deny”);​ Un Security Group este stateful (dacă o instanță face cerere, răspunsul va ajunge la instanță indiferent de regulile de intrare din Security Group). +Înainte ​de a pătrunde în tainele containerizarii cu Docker, vom încerca să definim un model arhitectural care să se încadreze în tipul de aplicație pentru care Docker devine ​unealtă importantă.
-Modificările făcute asupra regulilor dintr-un Security Group se aplică în timp real.+
  
-Un Network ACL (Access Control List) oferă un nivel opțional de securitate pentru VPC și acționează ca un firewall pentru controlul traficului de intrare și de ieșire pentru unul sau mai multe subnet-uri+===== Arhitectura Monolită vs. Arhitectura bazată pe microservicii ===== 
 + ​{{:​rl:​labs:​fullstack-single-system.png?​350|}} {{ :​rl:​labs:​fullstack-distributed-system.png?​350|}} ​
  
 +Este greșit să plecăm de la premisa că o abordare este mai bună decât cealaltă, fiecare fiind o opțiune optimă în contextul potrivit. O abordare monolită implică dezvoltarea întregului stack de aplicație pe un singur nod, un singur sistem, în timp ce, în cadrul modelului bazat pe microservicii,​ fiecare __unitate funcțională__ va avea propriul mediu izolat în care rulează. Gradul de rezoluție pentru definirea unității funcționale poate varia, de la viziunea macro, cu 2 componente: Frontend - Backend, până la nivelul de granularitate prin care putem avea fiecare __feature__ al aplicației dezvoltat ca un __microserviciu__ (ca un obiect rulând individual).
  
 +<note tip>
 +Mai multe referințe despre microservicii:​
 +  * https://​martinfowler.com/​articles/​microservices.html
 +  * https://​microservices.io/​
 +  * https://​nigelpoulton.com/​blog/​f/​demystifying-docker-overlay-networking
 +</​note>​
  
 +O comparație minimală între cele două modele arhitecturale,​ reliefând aspecte pozitive și problematice în ambele abordări, poate fi văzută în tabelul următor:
  
-===== Topologie =====+^    Arhitecturi Monolite ​     ^     ​Arhitecturi bazate pe Microservicii ​      ^ 
 +|  Modulele unei aplicații sunt Tightly Coupled (ex: Comunicare Inter Proces - IPC)    |  Serviciile unei aplicații sunt Loosely Coupled (ex: communicare peste rețea utilizând mesaje HTTP via REST API microservices) ​ | 
 +|  Fiecare funcționalitate nouă trebuie scrisă în același limbaj de programare. ​   |  Fiecare serviciu component al aplicației poate fi scris într-un limbaj diferit. ​   | 
 +|  Modificarea codului presupune recompilarea și reinstalarea (redeployment-ul) întregii aplicații. ​   |  Modificarea unui serviciu/​feature necesită reinstalarea acelui serviciu, celelalte rămânând intacte și operaționale. ​    | 
 +|  Simplu de dezvoltat. ​ |  Poate aduce un nivel de complexitate mult prea mare (ex: pentru fiecare serviciu trebuie construit un API care să faciliteze comunicația între microservicii) ​ | 
 +|  Scalarea aplicației se aplică întregului stack. ​ |  Procedurile de scalare pot fi aplicate pe servicii individuale (eg: multiplicarea serviciului de Frontend al unui magazin online în timpul reducerilor de Black Friday) ​ |
  
-{{ :rl:labs:topologie.png?600 |}}+Abordarea pe care vom merge în continuare este una bazată pe servicii, cu amendamentul că unitățile funcționale vor fi construite la un nivel de rezoluție macro**Frontend** și **Backend**,​ la care vom atașa și o **bază de date**.  
 +Să presupunem că avem o cerere din partea unui angajator de a dezvolta un site de stocare și partajare de imagini. Trebuie să ne asigurăm că acesta îndeplinește un set minimal de caracteristici,​ înainte de a fi lansat în producție: 
 +  * nivelul de utilizare va fi unul mediu 
 +  * va porni cu un set minimal de funcționalități,​ dar va fi extins în timp 
 +  * echipa de dezvoltatori este foarte dinamică din perspectiva migrării către alte proiecte, iar cunoștințele legate de anumite limbaje de programare sunt neuniforme  
 +  * se dorește ca serviciul să aibă o rată de availability care să tindă spre procentul de 99% (Maxim 7 ore 18 minute și 17.5 secunde downtime pe lună - https://​uptime.is/​ )  
 +  * se estimează că în perioada sărbătorilor vor exista spike-uri în utilizare, întrucât audiența va căuta activ poze cu mesaje motivaționale. 
 + 
 +Aplicația construită pentru laborator va aborda o arhitectură simplificată,​ bazată pe servicii, Vom încerca să utilizăm Docker pentru a ne asigura că îndeplinim cât mai multe din cerințele date. Înainte de a parcurge cerințele proiectului,​ ne vom familiariza cu tehnologia de containerizare.
  
  
Line 101: Line 115:
  
 **[[:​rl:​labs:​06|Laboratorul 6]]** **[[:​rl:​labs:​06|Laboratorul 6]]**
-{{page>:​rl:​labs:​06:​meta:​nav&​nofooter&​noeditbutton}}+{{page>:​rl:​labs:​11:​meta:​nav&​nofooter&​noeditbutton}}
  
 ===== Exerciții ===== ===== Exerciții =====
  
-Dorim să ne creăm propriul VPC și să obținem o rețea funcțională conform topologiei ​de mai sus. Următoarele exerciții constituie pașii de parcurgere pentru ca la final să putem folosi rețeaua.+{{namespace>:​rl:​labs:​11:​contents&​nofooter&​noeditbutton}} 
 + 
 + 
 +===== Cunoștințe acumulate ===== 
 +  * Intoducere în Docker CLI 
 +  * Docker Container vs Docker Image 
 +  * Dockerfile ​și construcția de Imagini 
 +  * CMD vs ENDPOINT 
 +  * Union File System: Overlay2 - image layers 
 +  * Docker Volumes 
 +  * Mount binding vs volumes 
 +  * Docker Networking: bridge & overlay (VXLAN) 
 +  * Docker SWARM 
 +  * Introducere în arhitecturi pe microservicii 
 +  * Arhitecturi pe microservicii vs Arhitecturi monolite 
  
-{{namespace>:​rl:​labs:​06:​contents&​nofooter&​noeditbutton}} 
rl/labs/06.1570537015.txt.gz · Last modified: 2019/10/08 15:16 by georgiana.trifu
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0