Show page

Differences

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

--- rl:labs:11 [2019/12/09 14:55]
marius.calapod [Arhitectura Monolită vs. Arhitectura bazată pe microservicii]
+++ rl:labs:11 [2024/01/09 08:27] (current)
cosmin.prunaru [Pregătire infrastructură de laborator]
@@ Line 1: / Line 1: @@
 ~~NOTOC~~
-====== Laborator 11. Virtualizare în Docker ======
+====== Laborator 11. Google Cloud Platform (GCP) ======
+  * [[ https://curs.upb.ro/2023/mod/feedbackadm/view.php?id=9386 | Feedback CA]]
+  * [[ https://curs.upb.ro/2023/mod/feedbackadm/view.php?id=9388 | Feedback CB]]
+  * [[ https://curs.upb.ro/2023/mod/feedbackadm/view.php?id=9390 | Feedback CC]]
+  * [[ https://curs.upb.ro/2023/mod/feedbackadm/view.php?id=9392 | Feedback CD]]
 ===== Cunoștințe și abilități ce vor fi dobândite =====
-  * Intoducere în Docker CLI
+  * Administrarea resurselor cloud folosind consola grafică.
-  * Docker Container vs Docker Image
+  * Securitate în cloud.
-  * Dockerfile și construcția de Imagini
+  * Configurarea rutării în cloud.
-  * Union File System: Overlay2 - image layers
+  * Accesarea serviciilor de transfer de fișiere (FTP).
-  * 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 =====
-<note warning>
+  * Vom crea o infrastructură de rețea în cloud-ul Google.
+  * Fiecare student va folosi contul propriu de pe [[https://console.cloud.google.com/|GCP]]. Pentru a putea crea infrastructura necesară veți primi un număr de credite pentru GCP.
-**Creați 2 mașini virtuale.**
+<note warning>Fiecare student își va denumi resursele astfel //student<X>//-[nume_resursa]. De exemplu //student1-//vpc. GCP acceptă în numele de obiecte doar litere mici, cifre și cratimă.
-Folosiți imaginea **Ubuntu 16.04 Xenial** cu flavor **m1.medium** pe [[https://cloud-controller.grid.pub.ro/dashboard|Openstack]].
+Vă puteți afla ID-ul accesând linkul **"https://rl.vladn.st/get/<email>"** </note>
-Atenție ! Utilizatorul **NU** este **student**, ci **ubuntu**.
+===== Introducere =====
-<code bash>
+Servicii de cloud existente:
-ubuntu@hostname:~# sudo apt-get update
+  * Google Cloud Platform
-ubuntu@hostname:~# sudo apt-get install docker
+  * Microsoft Azure
-ubuntu@hostname:~# sudo apt-get install docker.io
+  * Amazon Web Services.
-ubuntu@hostname:~# cat /etc/hostname
-$MY_HOSTNAME
-ubuntu@hostname:~# cat /etc/hosts   # Adăugați linia următoare în fișierul /etc/hosts
-.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
+Vom discuta mai departe despre **Google Cloud Platform** (GCP). Serviciile pe care le vom folosi în cadrul laboratorului:
-</code>
+  * Google Compute Engine
-</note>
+  * Networking: VPC, Cloud NAT
-<note important>
+Alte servicii în cloud-ul GCP:
-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]
-  * [1] https://docs.docker.com/install/linux/docker-ce/ubuntu/
+  * Cloud Storage
-  * [2] https://docs.docker.com/install/linux/linux-postinstall/
+  * Databases: AlloyDB, Cloud SQL, Cloud Bigtable
-</note>
+  * Networking: Cloud DNS, Cloud CDN
+  * Cloud Monitoring
-===== Introducere =====
+O listă completă a tuturor serviciilor oferite de Google poate fi consultată aici :
+[[https://cloud.google.com/terms/services| GCP Services]]
-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.
-Î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.
+**(Google) Compute Engine** 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.
-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:vpc-overview-example.png?500 |}}
-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.
+**Virtual Private Cloud (VPC) Network** te ajută să pornești resursele GCP î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. Fiecare VPC creat este izolat logic de oricare alt VPC din cloud.
-Modelele prezentate pot fi puncte de plecare importante pentru parcurgerea unor interviuri de Site Reliability Engineer, Cloud Engineer sau DevOps Engineer.
+Două sau mai multe VPC-uri pot comunica folosind **VPC Network Peering**. Rețelele VPC conectate folosind VPC Network Peering pot fi în același proiect sau proiecte diferite. \\
+\\
+Pot fi create două tipuri de rețele tip VPC:
+  * auto-mode - unde un subnet din fiecare regiune este automat alocat, subnet-ul fiind creat sub blocul de adrese 10.128.0.0/9 .
+  * custom-mode - nu sunt create subnet-uri automat și utilizatorul poate avea control complet asupra clasei de IP-uri private utilizate pentru crearea VPC-ului.
-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.
+Având în vedere considerentele de mai sus, nu se pot conecta două rețele VPC create în auto-mode, dar se pot conecta două rețele, una creată auto-mode, cealaltă custom-mode cât timp nu folosesc adrese IP din aceeași clasă.
-**Ben Treynor** //VP of Engineers @ Google// și inventatorul termenului **Site Reliability Engineer** încercând să definească conceptul:
+tipuri de adrese IP:
-//"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ă.
+  * 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 pe cont până în momentul în care alegi să renunți la ele.\\
-===== 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:
+//Care este diferența între adrese IP private și adresele IP publice?//
-  * 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:
-^    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)  |
-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.
+**Subnet** - interval de adrese IP într-un VPC. Poți să lansezi resursele GCP într-un subnet fie ales automat (auto-mode) fie creat la alegere (custom-mode).
+În GCP avem două tipuri de **IP-uri**:
+  * **Publice** (atunci când resursele trebuie să aibă acces direct în Internet, de exemplu serverele web). O adresă IP publică poate fi configurată pe interfața unei mașini virtuale create în GCP. Pot fi aplicate ulterior reguli de firewall pentru a putea controla accesul către acea mașină virtuală.
+  * **Private** (atunci când resursele nu trebuie să fie accesibile din Internet, de exemplu bazele de date)
+<note important>
+În fiecare subnet, există 4 IP-uri rezervate în intervalul primar :
+  * Prima este adresă de rețea
+  * A doua este rezervată ca adresă pentru default gateway.
+  * Penultima adresă este rezervată de către GCP pentru viitoare utilizări.
+  * Ultima este adresa de broadcast
+</note>
+**Cloud NAT**. Cloud NAT este o componentă a GCP care permite comunicarea între instanțele din VPC care nu folosesc adrese IP publice și Internet.\\
+Cloud NAT oferă conectivitate în Internet pentru următoarele tipuri de resurse:
+  * Mașini virtuale din Compute Engine fără adrese IP publice/externe asociate
+  * Clustere de Google Kubernetes Engine (GKE)
+  * Instanțe de Cloud Run (aplicații containerizate), Cloud Functions (code in the cloud/FaaS), App Engine
+**Tabela de rutare**. Fiecare subnet dintr-un VPC trebuie să aibă asociată o tabelă de rutare, definită în cadrul VPC network.
+Google Cloud folosește mai multe tipuri de rute:
+  * Generate de sistem
+      * Rute default ( 0.0.0.0/0 pentru IPv4 sau ::/0 pentru IPv6)
+      * Rute pentru subrețea (create automat pentru fiecare subrețea)
+  * Rute personalizate (custom)
+      * Statice (către diverse destinații)
+      * Dinamice (sesiuni BGP către un Cloud Router)
+  * Rute peering
+  * Rute policy-based (către un Network Load Balancer din GCP).
+Un **VPC firewall** acționează ca un firewall virtual care controlează traficul pentru una sau mai multe instanțe. Putem adăuga reguli pentru fiecare firewall care să permită traficul către/de la instanțele asociate.
+Prestabilit, fiecare firewall permite tot traficul de ieșire și blochează traficul de intrare.
+Acțiunile pentru o regulă din firewall pot fi ori "allow" ori "deny", nu ambele.
+<note tip>Pentru mai multe detalii despre funcționarea VPC-urilor și resursele GCP, urmăriți [[https://www.youtube.com/watch?v=vACTtmLWiQY|tutorialul]].
+Documentație GCP:
+[[https://cloud.google.com/curated-resources/compute-engine?hl=en|Compute Engine]]\\
+[[https://cloud.google.com/vpc/docs/overview?hl=en|VPC and Subnets]]\\
+[[https://cloud.google.com/network-connectivity/docs/router/concepts/overview?hl=en|Cloud Router]]\\
+</note>
+===== Topologie =====
+{{ :rl:labs:12:gcp_infrastructure.png |}}
 ===== Navigare =====
@@ Line 108: / Line 140: @@
 ===== Exerciții =====
-{{namespace>:rl:labs:11:contents&nofooter&noeditbutton}}
+Acest laborator își propune configurarea unei rețele asemănătoare topoligiei de mai sus.
+Vom avea nevoie de crearea **unui VPC** cu **4 subnets**, unul în care va fi creată stația **Host**, iar apoi **câte un subnet** separat pentru **Red**, **Green** și **Blue**.
+Stația **Host** va fi folosită drept **Bastion**, o mașină virtuală folosită doar pentru a ne conecta prin Internet la celelalte mașini, **Red**, **Green** și **Blue**.
-===== Cunoștințe acumulate =====
+Această va avea configurată o adresa IP publică, celelalte vor avea configurate doar adresa IP private, comunicând pe Internet cu ajutorul serviciului de **Cloud NAT**.
-  * Intoducere în Docker CLI
-  * Docker Container vs Docker Image
-  * Dockerfile și construcția de Imagini
+Următoarele exerciții constituie pașii de parcurgere pentru ca la final să putem folosi rețeaua.
-  * CMD vs ENDPOINT
-  * Union File System: Overlay2 - image layers
-  * Docker Volumes
+{{namespace>:rl:labs:11:contents&nofooter&noeditbutton}}
-  * Mount binding vs volumes
-  * Docker Networking: bridge & overlay (VXLAN)
-  * Docker SWARM
-  * Introducere în arhitecturi pe microservicii
-  * Arhitecturi pe microservicii vs Arhitecturi monolite

Laborator

Laboratorul 11

Curs

Informații generale RL

Cursuri

Laboratoare

Teme

rl/labs/11.1575896158.txt.gz · Last modified: 2019/12/09 14:55 by marius.calapod

Show page Old revisions

Media Manager Back to top