Differences

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

Link to this comparison view

rl:labs:06 [2020/10/10 23:21]
octavian.grigorescu
rl:labs:06 [2023/11/10 17:11] (current)
laura.ruse [Pregătire infrastructură de laborator]
Line 1: Line 1:
 +~~SHOWSOLUTION~~
 ~~NOTOC~~ ~~NOTOC~~
  
-====== Laborator 6. Virtualizare ​în Docker ​======+====== Laborator 6. Adresare IP și rutare ​în Linux ======
  
 ===== Cunoștințe și abilități ce vor fi dobândite ===== ===== Cunoștințe și abilități ce vor fi dobândite =====
  
-  * Intoducere ​în Docker CLI +  * Configurare de adrese IP în Linux 
-  * Docker Container vs Docker Image +  * Configurarea rutării în Linux 
-  * Dockerfile și construcția de Imagini +  * Depanarea problemelor de configurare a rețelei în Linux
-  * 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+
  
 ===== Cheat sheet ===== ===== Cheat sheet =====
  
-  * {{:​rl:​rl_cheatsheet.pdf|Cheat Sheet}}.+  * {{:​rl:​rl_cheatsheet.pdf|Cheat Sheet}}
  
 ===== Pregătire infrastructură de laborator ===== ===== Pregătire infrastructură de laborator =====
  
-<note warning>+  * Avem nevoie de o mașină virtuală a laboratorului. Vă rugăm urmăriți [[:​rl:​info:​resurse:​vm-laborator|pagina aceasta pentru instrucțiuni]],​ apoi reveniți. 
 +  * **Atenție:​** puteți accesa mașina virtuală (din spațiul ''​10.9.0.0/​16''​) doar prin intermediul serverului fep!
  
-**Creați 2 mașini virtuale.**+  ​* **Sfat util pentru toate laboratoarele:​** pentru a vă autentifica pe ''​fep.grid.pub.ro''​ fără să vă ceară autentificare web și two-factor, se recomandă generatul și instalatul unei perechi de chei publice/​private după pașii de mai jos (pe un sistem Linux): <code bash> 
 +# pe sistemul gazdă (e.g., laptop / PC): 
 +ssh-keygen # fără argumente, folosim setările implicite 
 +# ne-a generat fișierele ~/​.ssh/​id_rsa și ~/​.ssh/​id_rsa.pub 
 +cat ~/​.ssh/​id_rsa.pub 
 +# copiem tot (inclusiv id-rsa ... până la final) în clipboard 
 +# ne autentificăm la fep, clasic (încă nu merge fără parolă că n-am terminat configurarea):​ 
 +ssh username@fep.grid.pub.ro 
 +# odată conectați pe fep: 
 +mkdir -p ~/.ssh 
 +vim ~/​.ssh/​authorized_keys ​ # sau nano, dacă nu vă place vim :(  
 +și dați paste la cheia voastră publică aici (dacă sunteți prin vim, nu uitați să intrați în INSERT) 
 +# ieșiți și apoi vă reconectați la fep, nu ar trebui să vă mai ceară parolă :D 
 +ssh username@fep.grid.pub.ro ​ # doamne-ajută! 
 +</​code>​
  
-Folosiți imaginea **Ubuntu 16.04 Xenial** cu flavor **m1.medium** pe [[https://cloud-controller.grid.pub.ro/dashboard|Openstack]].+<​note>​ 
 +Pentru utilizatorii de Windows, ar trebui să existe utilitarul ssh-keygen în consola clasică sau PowerShell. 
 +Dacă folosiți Putty, din păcate, pașii sunt mult mai laborioși (folosește alt format pentru chei publice și va trebui să faceți conversia), deci nu vom lista pașii necesari aici (hintuse Google sau folosiți ssh-ul nativ de pe Windows 10, e mai OK). 
 +</note>
  
-Atenție ! Utilizatorul **NU** este **student**, ​ci **ubuntu**.+  ​Pentru a pregăti configurația de laborator, pe mașina virtuală (stația ''​host''​) folosiți comenzile următoare din contul utilizatorului ''​root''​ de pe stația ''​host''​ (puteți da copy/paste la comenzi în terminal):<​code bash> 
 +# ATENȚIE: update_lab nu funcționează de pe root, folosiți ​student ​inițial 
 +student@host:​~#​ update_lab --force 
 +student@host:​~#​ start_lab ip 
 +</​code>​ 
 +  ​Deschideți trei noi tab-uri în terminal (folosiți combinația de taste ''​Ctrl+Shift+t''​),​ și conectați-vă,​ din nou, la mașina virtuală folosind comanda ''​ssh''​ de mai sus. 
 +    ​De pe cele trei noi tab-uriconectați-vă la cele trei containere (''​red'',​ ''​green''​ și ''​blue''​). 
 +    ​Pentru o conectare mai ușoară puteți folosi aliasul ''​go''​ (ex''​go red''​)
  
-<code bash+<note
-ubuntu@hostname:​~#​ sudo apt-get update +Pentru a vedea cum accesați stațiile ''​red'',​ ''​green''​ și ''​blue''​ (containere Docker configurate peste mașina virtuală VMware ​stația ''​host''​) urmăriți indicațiile din [[:rl:info:resurse:vm-laborator#instructiuni_de_utilizare|pagina cu instrucțiuni de utilizare a mașinii virtuale]].
-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 +
- +
-$FEP_USER@fep.grid.pub.ro:​~$ ssh -i ~/​.ssh/​id_rsa ubuntu@$VM_IP_ADDRESS # LOGIN +
- +
-</​code>​+
 </​note>​ </​note>​
  
-<​note ​important+<​note>​ 
-Pentru instalarea Docker pe Ubuntu urmăriți procedura ​de aici [1]. Suplimentar față de pașii descriși anterior, rulați comanda: +Conturile ​de acces la mașina virtuală (stația ''​host''​) sunt (''​username:​parola''​):​ 
-''​sudo usermod -aG docker $USER''​ +  * ''​root:student''​ 
- ​desprinsă din documentația [2] +  * ''​student:student''​
- +
-  * [1] https://​docs.docker.com/​install/​linux/​docker-ce/​ubuntu/​ +
-  * [2] https://​docs.docker.com/​install/​linux/​linux-postinstall/​+
 </​note>​ </​note>​
  
-===== Introducere ===== +<​note>​ 
- +În mod implicit folosițcontul ''​root''​ pentru conectare ​pe toate stațiileAveți nevoie ​de drepturi privilegiate ​pentru ​configurareFolosiți contul ''​student''​ doar unde vi se cere explicit.
-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.  +
- +
-Î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țiiAspecte 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.  +
- +
-Standardele ș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.  +
- +
-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.  +
- +
-Modelele prezentate pot fi puncte ​de plecare importante ​pentru ​parcurgerea unor interviuri de Site Reliability Engineer, Cloud Engineer sau DevOps Engineer +
- +
-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 șoamenilor care se orientează spre poziții operaționale. +
- +
-**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ă. +
- +
-===== 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>​ </​note>​
 +===== Topologie =====
  
-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: +{{ :rl:topologie.png |}}
- +
-^    Arhitecturi Monolite ​     ^     ​Arhitecturi bazate pe Microservicii ​      ^ +
-|  Modulele unei aplicații sunt Tightly Coupled (exComunicare 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) ​ | +
- +
-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. +
  
 ===== Navigare ===== ===== Navigare =====
  
-**[[:​rl:​labs:​11|Laboratorul ​11]]** +**[[:​rl:​labs:​06|Laboratorul ​6]]** 
-{{page>:​rl:​labs:​11:​meta:​nav&​nofooter&​noeditbutton}}+{{page>:​rl:​labs:​06:​meta:​nav&​nofooter&​noeditbutton}}
  
 ===== Exerciții ===== ===== Exerciții =====
  
-{{namespace>​:rl:labs:11:​contents&​nofooter&​noeditbutton}} +În cadrul exercițiilor din laboratoarele de Linux vom folosi [[:rl:labs:06#​topologie|topologia ​de mai sus]].
- +
- +
-===== 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.1602361280.txt.gz · Last modified: 2020/10/10 23:21 by octavian.grigorescu
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