Differences
This shows you the differences between two versions of the page.
|
rl:labs:06 [2019/11/03 19:07] florin.stancu [Pregătire infrastructură de laborator] add link app |
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 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> |
| - | ===== Prezentare concepte ===== | + | |
| - | Servicii de cloud existente: Amazon Web Services, Google Cloud Platform și Microsoft Azure. | + | **Creați 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 Delivery: VPC | + | |
| - | 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 cloud. De 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 ș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ă. | + | |
| - | * 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 ș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ă. \\ | + | Pentru instalarea Docker pe Ubuntu urmăriți procedura de aici [1]. Suplimentar față de pașii descriși anterior, rulaț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. |
| - | 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 o cerere, răspunsul va ajunge la instanță indiferent de regulile de intrare din Security Group). | + | 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. |
| - | 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 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). |
| - | [[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 114: | 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}} | ||
