Differences
This shows you the differences between two versions of the page.
|
idp:laboratoare:06 [2021/04/21 17:38] 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 faci de a lansa un runner în execuție este sub formă de containere Docker. | ||
| - | |||
| - | === Setup Gitlab Runners === | ||
| - | |||
| - | Pentru a folosi un runner, este nevoie, in primul rand, sa accesati pagina repository-ului sau din pagina grupului, daca folositi grup. | ||
| - | |||
| - | <note tip>Un runner de grup va putea rula pipelines pentru fiecare repository din grupul respectiv. Un runner de repository va rula pipelines doar pentru acel repository.</note> | ||
| - | |||
| - | <note tip>Noi vom folosi un runner de grup</note> | ||
| - | Intrati in meniul de CI/CD al paginii de proiect | ||
| - | |||
| - | {{:cc:laboratoare:mobygrouprunner.png?800|}} | ||
| - | |||
| - | si apoi selectati optiunea "Expand" din dreptul "Runners" | ||
| - | |||
| - | {{:cc:laboratoare:group_runner.png?800|}} | ||
| - | |||
| - | O sa observati ca noi avem un runner pornit pentru grupul nostru MobyCloudComputing. Este runnerul folosit de test la acest laborator. | ||
| - | |||
| - | === Instalare Gitlab Runners folosind Docker === | ||
| - | |||
| - | Instalarea unui runner folosind docker este [[https://docs.gitlab.com/runner/install/docker.html|simpla]] si necesita 3 pasi: | ||
| - | |||
| - | - "Instalarea runnerului" | ||
| - | - Inregistrarea runnerului | ||
| - | - Schimbarea fisierului de configuratie config.toml | ||
| - | |||
| - | == Instalarea efectiva == | ||
| - | Trebuie sa rulati comanda | ||
| - | |||
| - | <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>Atentie, runnerul va rula in modul bind mount. Calea de pe host pe care o dati runnerului (in cazul de fata, /srv/gitlab-runner/config) trebuie sa existe. In ea vor fi retinue configuratiile runnerului din interiorul containerului.</note> | ||
| - | |||
| - | == Inregistrarea runnerului == | ||
| - | Trebuie sa rulati comanda | ||
| - | |||
| - | <code bash> | ||
| - | docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register | ||
| - | </code> | ||
| - | |||
| - | si sa urmati pasii specificati | ||
| - | <note tip>Tokenul de inregistrare este cel din pagina grupului vostru</note> | ||
| - | <note warning>Va trebui sa folositi grupul personal de gitlab si runnerul vostru personal. Nu folositi token-ul de inregistrare al grupului MobyCloudComputing</note> | ||
| - | <note tip>Tineti minte ce specificati la tag. **Tag-ul runnerului va fi folosit in cadrul .gitlab-ci.yml**</note> | ||
| - | <note tip>Atunci cand vi se cere imaginea de docker, specificati **docker:19.03**</note> | ||
| - | <note important>Observati ca trebuie sa specificati aceeasi cale de bind mount, ca la prima comanda</note> | ||
| - | |||
| - | == Modificarea fisierului de configuratie config.toml == | ||
| - | |||
| - | Runnerul de gitlab care ruleaza in docker se bazeaza pe conceptul //dind// (docker-in-docker). Pentru anumite operatii, este nevoie de acces elevat asupra sistemului docker din gazda. Asadar, trebuie facute 2 mici modificari asupra fisierului de configuratie **config.toml**. | ||
| - | |||
| - | <note tip>Veti gasi fisierul la calea specificata in comanda de rulare de la etapa 1 (cea de instalare)</note> | ||
| - | {{:cc:laboratoare:config_toml.png|?800}} | ||
| - | |||
| - | <note tip>Observati liniile marcate cu un punct verde</note> | ||
| - | |||
| - | Modificarile sunt urmatoarele: | ||
| - | * **privileged** trebuie sa fie setat pe **true** | ||
| - | * la volume trebuie adaugat si **"/var/run/docker.sock:/var/run/docker.sock"** | ||
| - | |||
| - | Dupa ce efectuati modificarile, executati comanda: | ||
| - | |||
| - | <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|}} | ||
