This shows you the differences between two versions of the page.
idp:laboratoare:06 [2021/04/17 16:57] alexandru.hogea |
idp:laboratoare:06 [2023/02/22 11:12] (current) radu.ciobanu |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Laboratorul 06 - Portainer si Gitlab CI/CD ===== | + | ===== Laboratorul 06 - Portainer și GitLab CI/CD ===== |
- | ==== Introducere Laborator ==== | ||
- | In acest laborator vom discuta despre utilizarea **interfetei Portainer** care actioneaza ca un GUI pentru clusterul de Swarm. In plus, vom implementa procesul de CI/CD (continuous integration/continuous deployment) utilizant Gitlab CI/CD si Portainer. | ||
- | |||
- | Laboratorul se va desfasura, de data asta, pe local, intrucat infrastructura de la Play With Docker nu suporta rularea runnerilor de gitlab. | ||
- | |||
- | |||
- | ==== Portainer ==== | ||
- | |||
- | [[https://www.portainer.io|Portainer]] este o aplicatie web ce va permite administrarea clusterului de Docker Swarm | ||
- | |||
- | {{:cc:laboratoare:portainer.png?800|}} | ||
- | |||
- | Portainer poate rula ca si container separat sau ca si serviciu de Swarm. **Va recomandam sa il rulati ca serviciu de Swarm**.<note tip>In cazul in care ruleaza ca si serviciu de Swarm, portainer are doua componente. Aplicatia web propriu zisa si un agent, care ruleaza in mod global (pe toate nodurile)</note> | ||
- | |||
- | <code yaml> | ||
- | #stiva yml pentru Portainer | ||
- | 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 langa utilitatea oferita de posibilitatea gestiunii clusterului prin interfata vizuala, Portainer ofera **webhookuri** de CI/CD. Un webhook este un URL care, atunci cand este accesat, executa o actiune. In cazul Portainer, webhook-urile vor actualiza serviciile de Docker. Pentru a genera un Webhook, trebuie sa intrati pe pagina serviciului, si sa faceti toggle pe "Service Webhook" | ||
- | |||
- | {{:cc:laboratoare:portainer_webhook.png?800|}} | ||
- | |||
- | <note important>Atentie, pentru a crea un webhook, trebuie mai intai ca serviciul sa ruleze in cadrul Docker Swarm</note> | ||
- | ==== Gitlab CI/CD ==== | ||
- | |||
- | Conceptul de **CI/CD** se refera la: | ||
- | * continuous integration - integrarea modificarilor de cod automat in sistemul nou | ||
- | * continuous deployment - punerea codului modificat automat in testare/productie | ||
- | |||
- | Acest concept se muleaza natural pe filosofia microserviciilor, unde o aplicatie este sparta in mai multe **module separate si independente**. Pe masura ce codul unui modul este actualizat, acesta este integrat si deployed automat in sistem, fara sa perutrbe executia celorlalte module. | ||
- | |||
- | Pentru acest laborator am ales sa exemplificam procesul de CI/CD folosind Gitlab. | ||
- | |||
- | Gitlab CI/CD se bazeaza pe doua componente: | ||
- | |||
- | * [[https://docs.gitlab.com/runner/|Gitlab Runners]] - procese care executa pipelines | ||
- | * .gitlab-ci.yml - fisier yml de configuratii declarative care descrie ce face fiecare etapa dintr-un pipeline | ||
- | |||
- | <note tip>Un runner va executa un pipeline. Un pipeline este format din etape. Fiecare etapa este descrisa in fisierul de configuratie **.gitlab-ci.yml**</note> | ||
- | |||
- | ==== Preamblu Gitlab CI/CD ==== | ||
- | |||
- | Pentru a putea sa folositi conceptul de CI/CD folosind Gitlab //cat mai eficient// este recomandat sa aveti fiecare microserviciu in propriul sau **repository** si repository-urile grupate intr-un **grup**. Asadar, pentru acest laborator, vom avea urmatoarele repository-uri: | ||
- | * IOService - tine codul pentru microserviciul IO implementat la laboratoarele anterioare | ||
- | * BooksService - tine codul pentru microserviciul de carti implementat la laboratoarele anterioare | ||
- | * Configs - tine fisierele de configurare necesare rularii stivei de servicii | ||
- | |||
- | Codul este accesibil pe [[https://gitlab.com/mobycloudcomputing|repo-ul oficial al laboratorului]]. | ||
- | |||
- | ==== Gitlab Runners ==== | ||
- | |||
- | Gitlab Runners sunt procese care executa pipelines. Atunci cand se da comanda //git push// este lansat in executie un pipeline aferent repository-ului respectiv (de aici necesitatea de 1 repo / serviciu). | ||
- | |||
- | Acestea vin in mai multe forme, insa noi va recomandam sa folositi Gitlab Runners sub forma de containere Docker, fiind cel mai simplu mod de lansat in executie. | ||
- | |||
- | === 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|}} |