Differences

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

Link to this comparison view

rl:labs:06 [2020/10/09 10:37]
florin.stancu test
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 Test ======+====== 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 va folosi [[https://rl-aws.root.sx|aplicația laboratorului]]. Pentru a vă loga, veți primi parola laboratorului din partea asistentului și veți avea astfel acces la credențialele pentru cloud.+
  
-<note warning>​ +===== Pregătire infrastructură de laborator =====
-Fiecare student își va denumi resursele astfel //​student<​X>//​_[nume_resursa]. De exemplu //​student1_//​VPC. +
-</​note>​+
  
-{{ :​rl:​labs:​nume_resurse.png?​400 |}}+<​hidden><​note warning>
  
-<​hidden>​https://​docs.google.com/​document/​d/​1Gz-u4l68eCdQ0fKbZJB0Z3G4l0cGn-QYx6RT7PnRe2o/​edit</​hidden>​ +**Creați 2 mașini virtuale.**
-===== Prezentare concepte =====+
  
-Servicii de cloud existente: Amazon Web Services, Google Cloud Platform șMicrosoft Azure.+Folosițimaginea **Ubuntu 16.04 Xenial** cu flavor **m1.medium** pe [[https://​cloud-controller.grid.pub.ro/​dashboard|Openstack]].
  
-Mai departe discutăm despre AWS; serviciile pe care le vom folosi în cadrul laboratorului:​ +Atenție ! Utilizatorul ​**NU** este **student**,​ ci **ubuntu**.
-  ​Compute: EC2 +
-  ​Networking and Content Delivery: VPC+
  
-Alte servicii în cloud-ul Amazon+<code bash> 
-  * Storage ​Amazon Simple Storage Service (Amazon S3) +ubuntu@hostname:​~#​ sudo apt-get update 
-  * Database +ubuntu@hostname:~# sudo apt-get install docker 
-  * Machine Learning +ubuntu@hostname:​~#​ sudo apt-get install docker.io 
-  * Analytics +ubuntu@hostname:​~#​ cat /​etc/​hostname 
-  * AR&VR +$MY_HOSTNAME 
-  * Mobile+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
  
-**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ție:​ servere virtuale, configurarea securității șnetworking, ajustarea spațiului de stocare.+$FEP_USER@fep.grid.pub.ro:​~$ ssh -i ~/.ssh/id_rsa ubuntu@$VM_IP_ADDRESS # LOGIN
  
-{{:​rl:​labs:​virtual_private_cloud.png?​200 | }} \\   +</code>
- +
-**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. +
- +
-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ă. +
-  * adrese IP publice statice sunt adrese IP publice care rămân asociate contului tău Amazon până în momentul în care alegi să renunți la ele. +
- +
-<note tip> +
-Care este diferența între adrese IP private și adresele IP publice?+
 </​note>​ </​note>​
- +</​hidden>​
-**Subnet** - interval de adrese IP într-un VPC. Poți să lansezi resursele Amazon într-un subnet pe care îl creezi, la alegere. +
- +
-În Amazon avem două tipuri de **subnets**:​ +
-  * **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. +
-  * **Private** (atunci când resursele nu trebuie să aibă acces direct în Internet, de exemplu bazele de date)+
  
 <note important>​ <note important>​
-În fiecare subnet, primele 4 adrese IP și ultima adresă IP nu pot fi folosite de utilizatori: +Î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 și Jonathan Leibiusky și sponsorizată de Docker Inc. Pentru uz personal recomandam insa instalarea Docker pe calculator sau folosirea unei mașini virtuale.
-  * 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>​+
  
-**Internet Gateway**. IGW este o componentă a VPC-ului care permite comunicarea între instanțele din VPC șInternetPentru a comunica cu o instanță din subnet-ul publiceste necesar ca instanța să aibă alocată o adresă IP publică statică. \\ +Pentru instalarea Docker pe Ubuntu urmăriți procedura de aici [1]Suplimentar față de pașii descriși anteriorrulați comanda: 
 +''​sudo usermod -aG docker $USER''​ 
 + ​desprinsă din documentația [2]
  
-<note warning> +  * [1] https://​docs.docker.com/​install/​linux/​docker-ce/​ubuntu/​ 
-Poți crea un singur obiect IGW per VPC.+  * [2] https://​docs.docker.com/​install/​linux/​linux-postinstall/​
 </​note>​ </​note>​
  
-**Tabela de rutare**. Fiecare subnet dintr-un VPC trebuie să aibă asociată o tabelă de rutare. Un subnet poate fi asociat numai cu o singură tabelă de rutare la un moment dat, dar o tabelă de rutare poate fi asociată cu mai multe subnet-uri.+===== Introducere =====
  
-{{:​rl:​labs:​nat_device.png?200 |}}+<​hidden>​ 
 +Iată că ne regăsim la sfârșitul semestrului I din anul 3, după o lungă și dificilă călătorie prin tainele ingineriei Calculatoarelor,​ traseu ce a adus în planul de studiu și materia Rețele locale 
 +</​hidden>​
  
-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). +Î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 o 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. ​
-(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.+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
  
-{{:​rl:​labs:​security_group.png?100 |}}+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
  
-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.+Modelele prezentate pot fi puncte de plecare importante ​pentru ​parcurgerea unor interviuri ​de Site Reliability Engineer, Cloud Engineer sau DevOps Engineer
  
-Prestabilitfiecare Security Groups permite tot traficul de ieșire. Regulile unui Security Group sunt întotdeauna permisive (nu putem adăuga regulă de „deny”);​ Un Security Group este stateful (dacă o instanță face o cerere, ​spunsul va ajunge la instanță indiferent de regulile ​de intrare din Security Group). +Mai multlaboratorul deservește, în egală măsură, ​introducere în Docker, Docker Networking & Docker Orchestration,​ facilitând implementarea graduală a unui serviciu web, de la concept până într-formă care ar putea spunde unor cerințe reale de producțieLaboratorul 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.
-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. ​+**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"//​
  
 +Î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 o unealtă importantă.
  
-<note tip>​Pentru mai multe detalii despre funcționarea VPC-urilor și resursele AWS, urmăriți [[https://www.youtube.com/​watch?v=fpxDGU2KdkA|tutorialul]]+===== Arhitectura Monolită vs. Arhitectura bazată pe microservicii ===== 
 + {{:rl:​labs:​fullstack-single-system.png?350|}} {{ :​rl:​labs:​fullstack-distributed-system.png?​350|}} ​
  
-Documentație AWS:+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 componenteFrontend - 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).
  
-[[https://​docs.aws.amazon.com/​vpc/​latest/​userguide/​VPC_Networking.html|VPC Networking Components]] \\  +<note tip> 
-[[https://docs.aws.amazon.com/vpc/latest/​userguide/​VPC_Subnets.html|VPC and Subnets]] \\  +Mai multe referințe despre microservicii
-[[https://docs.aws.amazon.com/vpc/​latest/​userguide/​vpc-eips.html|Elastic IP Addresses]] \\  +  ​* ​https://martinfowler.com/articles/microservices.html 
-[[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/​concepts.html|Amazon EC2]]+  ​* ​https://microservices.io
 +  ​* ​https://nigelpoulton.com/blog/f/demystifying-docker-overlay-networking
 </​note>​ </​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 116: 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}}
  
-<note important>​ 
-Deși fiecare student primește câte un username separat, organizația AWS folosită (sponsorizată de către Bitdefender) este numai una, iar aceasta definește namespace-ul tuturor resurselor. De aici rezultă **principala limitare**, faptul că **o să puteți vedea și interacționa cu TOATE obiectele create de către fiecare student** (i.e., resursele sunt partajate între utilizatori). 
  
-Mai mult, veți putea vedea și niște resurse prefixate cu ''​admin_''​. Acestea sunt folosite pentru găzduirea aplicației de gestiune a conturilor, încercați să nu vă atingeți de ele (deși am implementat restricții de acces, dacă cineva reușește să șteargă / facă aplicația nefuncțională well... o să ne mai vedem și la toamnă / anul :P).+===== Cunoștințe acumulate ===== 
 +  * Intoducere în Docker CLI 
 +  * Docker Container vs Docker Image 
 +  * Dockerfile ​și construcția de Imagini 
 +  * CMD vs ENDPOINT 
 +  * Union File SystemOverlay2 - 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
  
-Permisiuni atribuite utilizatorilor student: doar de creare resurse, modificat unde este necesar, taguit doar cu prefixul ''​student<​X>​_'',​ fără drept de ștergere și alte acțiuni ne-necesare laboratorului. 
-</​note>​ 
  
-{{namespace>:​rl:​labs:​06:​contents&​nofooter&​noeditbutton}} 
rl/labs/06.1602229031.txt.gz · Last modified: 2020/10/09 10:37 by florin.stancu
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