Differences
This shows you the differences between two versions of the page.
|
idp:laboratoare:06 [2021/04/22 09:40] radu.ciobanu |
idp:laboratoare:06 [2023/02/22 11:12] (current) radu.ciobanu |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Laboratorul 06 - Portainer și GitLab CI/CD ===== | ===== Laboratorul 06 - Portainer și GitLab CI/CD ===== | ||
| - | ==== Introducere ==== | ||
| - | În acest laborator, vom discuta despre utilizarea Portainer, care acționează ca un GUI pentru Docker Swarm. În plus, vom implementa procesul de CI/CD („continuous integration and continuous deployment”) utilizând GitLab CI/CD și Portainer. | ||
| - | |||
| - | Laboratorul se va desfășura pe local sau folosind Docker Machine, întrucât infrastructura de la Play With Docker nu permite rularea runner-ilor de GitLab. | ||
| - | |||
| - | ==== Portainer ==== | ||
| - | |||
| - | [[https://www.portainer.io|Portainer]] este o platformă Web care permite administrarea unui cluster Docker Swarm. | ||
| - | |||
| - | {{:cc:laboratoare:portainer.png?800|}} | ||
| - | |||
| - | Portainer poate rula ca un container separat sau ca serviciu de Swarm. **Vă recomandăm să îl rulați ca serviciu de Swarm**. | ||
| - | |||
| - | <note tip>În cazul în care rulează ca serviciu de Swarm, Portainer are două componente: aplicația Web propriu-zisă, și un agent care rulează în mod global (pe toate nodurile).</note> | ||
| - | |||
| - | Un exemplu de fișier Docker Compose de stivă de servicii pentru Portainer poate fi observat mai jos. | ||
| - | |||
| - | <code yaml> | ||
| - | version: '3.2' | ||
| - | |||
| - | services: | ||
| - | agent: | ||
| - | image: portainer/agent | ||
| - | volumes: | ||
| - | - /var/run/docker.sock:/var/run/docker.sock | ||
| - | - /var/lib/docker/volumes:/var/lib/docker/volumes | ||
| - | networks: | ||
| - | - agent_network | ||
| - | deploy: | ||
| - | mode: global | ||
| - | placement: | ||
| - | constraints: [node.platform.os == linux] | ||
| - | |||
| - | portainer: | ||
| - | image: portainer/portainer-ce | ||
| - | command: -H tcp://tasks.agent:9001 --tlsskipverify | ||
| - | ports: | ||
| - | - "9000:9000" | ||
| - | - "8000:8000" | ||
| - | volumes: | ||
| - | - portainer_data:/data | ||
| - | networks: | ||
| - | - agent_network | ||
| - | deploy: | ||
| - | mode: replicated | ||
| - | replicas: 1 | ||
| - | placement: | ||
| - | constraints: [node.role == manager] | ||
| - | |||
| - | networks: | ||
| - | agent_network: | ||
| - | driver: overlay | ||
| - | attachable: true | ||
| - | |||
| - | volumes: | ||
| - | portainer_data: | ||
| - | |||
| - | </code> | ||
| - | |||
| - | Pe lângă utilitatea oferită de posibilitatea gestiunii cluster-ului prin interfața vizuală, Portainer oferă **//webhook-uri//** de CI/CD. Un webhook este un endpoint care, atunci când este accesat, execută o acțiune. În cazul Portainer, webhook-urile vor actualiza serviciile de Docker. Pentru a genera un webhook, se intră pe pagina serviciului și se face toggle pe „Service Webhook”, așa cum se observă în imaginea de mai jos. | ||
| - | |||
| - | {{:cc:laboratoare:portainer_webhook.png?800|}} | ||
| - | |||
| - | <note important> | ||
| - | Pentru a crea un webhook, trebuie mai întâi ca serviciul să ruleze în cadrul Docker Swarm. | ||
| - | </note> | ||
| - | |||
| - | ==== Gitlab CI/CD ==== | ||
| - | |||
| - | Conceptul de **//CI/CD//** se referă la: | ||
| - | * continuous integration - integrarea automată în sistem a modificărilor de cod | ||
| - | * continuous deployment - plasarea automată a codului modificat în testare/producție. | ||
| - | |||
| - | Acest concept se mulează natural pe filozofia microserviciilor, unde o aplicație este „spartă” în mai multe **//module separate și independente//**. Pe măsură ce codul unui modul este actualizat, acesta este integrat automat în sistem, fără să perturbe execuția celorlalte module. | ||
| - | |||
| - | În acest laborator, se exemplifică procesul de CI/CD folosind GitLab. Gitlab CI/CD se bazează pe două componente: | ||
| - | |||
| - | * [[https://docs.gitlab.com/runner/|Gitlab Runners]] - procese care executa pipeline-uri | ||
| - | * //**.gitlab-ci.yml**// - fișier YAML de configurații declarative, care descrie ce face fiecare etapă dintr-un pipeline. | ||
| - | |||
| - | <note tip> | ||
| - | Un runner execută un pipeline. Un pipeline este format din etape. Fiecare etapă este descrisă în fișierul de configurație **//.gitlab-ci.yml//**.</note> | ||
| - | |||
| - | ==== Structura codului sursă ==== | ||
| - | |||
| - | Pentru a putea folosi conceptul de CI/CD cu GitLab cat mai eficient, se recomandă ca fiecare microserviciu să se afle în propriul său **//repository//**, iar toate repository-urile să fie grupate într-un **//grup//**. Așadar, pentru acest laborator, vom avea următoarele repository-uri: | ||
| - | * IOService - conține codul pentru microserviciul IO implementat la laboratoarele anterioare | ||
| - | * BooksService - conține codul pentru microserviciul de cărți implementat la laboratoarele anterioare | ||
| - | * Configs - conține fișierele de configurare necesare rulării stivei de servicii. | ||
| - | |||
| - | Codul este accesibil pe [[https://gitlab.com/mobylab-idp|repo-ul oficial al laboratorului]]. | ||
| - | |||
| - | ==== Gitlab Runners ==== | ||
| - | |||
| - | Gitlab Runners sunt procese care execută pipeline-uri. Atunci când se dă comanda //**git push**//, este lansat în execuție un pipeline aferent repository-ului respectiv (de aici recomandarea de a avea un repository per serviciu). | ||
| - | |||
| - | Acestea vin în mai multe forme, însă modul cel mai facil de a lansa un runner în execuție este sub formă de containere Docker. | ||
| - | |||
| - | === Configurare === | ||
| - | |||
| - | Pentru a folosi un runner, este nevoie, în primul rând, să se acceseze pagina repository-ului sau a grupului GitLab. | ||
| - | |||
| - | <note tip> | ||
| - | Un runner de grup va putea rula pipeline-uri pentru fiecare repository din grupul respectiv. Un runner de repository va putea rula pipeline-uri doar pentru acel repository. | ||
| - | </note> | ||
| - | |||
| - | Se intră în meniul de CI/CD al paginii de proiect și apoi se selectează opțiunea „Expand” din dreptul „Runners”, | ||
| - | |||
| - | {{:cc:laboratoare:mobygrouprunner.png?800|}} | ||
| - | |||
| - | {{:cc:laboratoare:group_runner.png?800|}} | ||
| - | |||
| - | === Gitlab Runners în Docker === | ||
| - | |||
| - | Configuraera unui runner folosind Docker este simplă și necesită [[https://docs.gitlab.com/runner/install/docker.html|trei pași]]: | ||
| - | - instalarea | ||
| - | - înregistrarea | ||
| - | - modificarea fișierului de configurație //**config.toml**//. | ||
| - | |||
| - | == Instalarea == | ||
| - | |||
| - | Pentru instalare, se rulează următoarea comandă: | ||
| - | |||
| - | <code bash> | ||
| - | $ docker run -d --name gitlab-runner --restart always -v /srv/gitlab-runner/config:/etc/gitlab-runner \ | ||
| - | -v /var/run/docker.sock:/var/run/docker.sock gitlab/gitlab-runner:latest | ||
| - | </code> | ||
| - | |||
| - | <note important> | ||
| - | Runner-ul va rula în modul bind mount. Calea de pe gazdă dată runner-ului (în cazul de față, //**/srv/gitlab-runner/config**//) trebuie să existe. În ea vor fi reținute configurațiile runner-ului din interiorul containerului. În mod similar, se poate folosi un volum. | ||
| - | </note> | ||
| - | |||
| - | == Înregistrarea == | ||
| - | |||
| - | Pentru înregistrare, se rulează următoarea comandă și se urmează pașii specificați: | ||
| - | |||
| - | <code bash> | ||
| - | $ docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register | ||
| - | </code> | ||
| - | |||
| - | <note tip>Token-ul de înregistrare este cel din pagina grupului de GitLab.</note> | ||
| - | |||
| - | <note tip>Trebuie ținut minte ce se specifică la tag, deoarece tag-ul runnerul-ui va fi folosit în cadrul script-ului **//.gitlab-ci.yml//**.</note> | ||
| - | |||
| - | <note tip>Atunci când se cere imaginea de Docker, se poate specifica **//docker:19.03//**.</note> | ||
| - | |||
| - | <note important>Trebuie specificată aceeași cale de bind mount ca la comanda de instalare.</note> | ||
| - | |||
| - | == Modificarea fișierului de configurație == | ||
| - | |||
| - | Runner-ul de GitLab care rulează în Docker se bazează pe conceptul //**DinD**// („Docker in Docker”). Pentru anumite operații, este nevoie de acces elevat asupra sistemului Docker din gazdă. Așadar, trebuie făcute două modificări asupra fișierului de configurație **//config.toml//**. | ||
| - | |||
| - | <note tip> | ||
| - | Fișierul **//config.toml//** se găsesște la calea specificata în comanda de instalare de la etapa 1. | ||
| - | </note> | ||
| - | |||
| - | {{:cc:laboratoare:config_toml.png|?800}} | ||
| - | |||
| - | Modificările necesare sunt următoarele (marcate în fișierul prezentat mai sus): | ||
| - | * „privileged” trebuie să fie setat pe „true” | ||
| - | * la volume, trebuie adăugat și „/var/run/docker.sock:/var/run/docker.sock”. | ||
| - | |||
| - | Dupa ce se efectuează modificările, se execută următoarea comandă: | ||
| - | |||
| - | <code bash> | ||
| - | $ sudo docker restart gitlab-runner | ||
| - | </code> | ||
| - | |||
| - | === Scriere script .gitlab-ci.yml === | ||
| - | |||
| - | Scritpul **.gitlab-ci.yml** descrie executia pipeline-ului pe un runner. Un exemplu de script este cel folosit in cadrul laboratorului. | ||
| - | <note tip>Va trebuie sa scrieti cate un script .gitlab-ci.yml pentru fiecare repository. Scripturile sunt, oricum, similare.</note> | ||
| - | |||
| - | <code yaml> | ||
| - | docker-build-master: | ||
| - | # Official docker image. | ||
| - | stage: build | ||
| - | before_script: | ||
| - | - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY | ||
| - | script: | ||
| - | - docker build --pull -t "$CI_REGISTRY_IMAGE" . | ||
| - | - docker push "$CI_REGISTRY_IMAGE" | ||
| - | only: | ||
| - | - master | ||
| - | tags: | ||
| - | - lab-cc-pwd | ||
| - | |||
| - | # deploy-service-master: | ||
| - | # stage: deploy | ||
| - | # script: | ||
| - | # - apk add --update curl | ||
| - | # - curl -XPOST http://host.docker.internal:9000/api/webhooks/78074a4c-840c-4152-a9ab-b094fa5e525b | ||
| - | # only: | ||
| - | # - master | ||
| - | # tags: | ||
| - | # - lab-cc-pwd | ||
| - | |||
| - | </code> | ||
| - | |||
| - | Acest script descrie doua etape ale pipeline-ului: | ||
| - | * **build** - codul este construit intr-o imagine de docker si salvat in registrul privat de gitlab | ||
| - | * **deploy** - serviciul de docker este incarcat in clusterul de Swarm, utilizat un **webhook** Portainer | ||
| - | |||
| - | <note tip>Observati ca partea de deploy este comentata. Am facut acest lucru din mai multe motive: | ||
| - | * in primul rand, un webhook trebuie creat **dupa ce serviciul ruleaza deja in Swarm**. Asta inseamna ca prima oara, deploymentul se va face manual, prin comanda **docker stack deploy** | ||
| - | * in al doilea rand, link-ul pentru webhook difera de la persoana la persoana | ||
| - | </note> | ||
| - | |||
| - | <note tip>Observati cum IP-ul este **host.docker.internal** desi Portainer a generat webhook utilizand **localhost**</note> | ||
| - | |||
| - | ==== Rularea configuratiei de laborator ==== | ||
| - | |||
| - | Pentru a rula exemplul din laborator, este nevoie sa efectuati urmatoarele comenzi in repository-ul **Configs** | ||
| - | |||
| - | <code bash> | ||
| - | docker stack deploy -c stack-kong.yml lab4-cluster | ||
| - | </code> | ||
| - | |||
| - | <code bash> | ||
| - | docker stack deploy -c portainer-agent-stack.yml portainer | ||
| - | </code> | ||
| - | |||
| - | Puteti accesa container pe adresa //localhost:9000// | ||
| - | |||
| - | ==== Mentiuni lucru individual ==== | ||
| - | |||
| - | Daca doriti sa lucrati individual cu partea de CI/CD, este **obligatoriu** sa va faceti propriul grup de gitlab si propriile repositories. | ||
| - | |||
| - | Pentru a testa ca va merge partea de CI/CD, la o modificare de cod si rularea comenzii | ||
| - | |||
| - | <code git> | ||
| - | git push -u origin master | ||
| - | </code> | ||
| - | |||
| - | ar trebui sa vedeti executia cu succes a unui pipeline din panoul CI/CD al repository-ului. | ||
| - | |||
| - | {{:cc:laboratoare:pipelines_1.png?800|}} | ||
| - | |||
| - | {{:cc:laboratoare:pipeline_success.png?800|}} | ||
