This is an old revision of the document!


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

Portainer este o platformă Web care permite administrarea unui cluster Docker Swarm.

Portainer poate rula ca un container separat sau ca serviciu de Swarm. Vă recomandăm să îl rulați ca serviciu de Swarm.

Î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).

Un exemplu de fișier Docker Compose de stivă de servicii pentru Portainer poate fi observat mai jos.

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:

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.

Pentru a crea un webhook, trebuie mai întâi ca serviciul să ruleze în cadrul Docker Swarm.

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:

  • 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.

Un runner execută un pipeline. Un pipeline este format din etape. Fiecare etapă este descrisă în fișierul de configurație .gitlab-ci.yml.

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 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.

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.

Noi vom folosi un runner de grup

Intrati in meniul de CI/CD al paginii de proiect

si apoi selectati optiunea “Expand” din dreptul “Runners”

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 simpla si necesita 3 pasi:

  1. “Instalarea runnerului”
  2. Inregistrarea runnerului
  3. Schimbarea fisierului de configuratie config.toml
Instalarea efectiva

Trebuie sa rulati comanda

   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

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.

Inregistrarea runnerului

Trebuie sa rulati comanda

docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register

si sa urmati pasii specificati

Tokenul de inregistrare este cel din pagina grupului vostru

Va trebui sa folositi grupul personal de gitlab si runnerul vostru personal. Nu folositi token-ul de inregistrare al grupului MobyCloudComputing

Tineti minte ce specificati la tag. Tag-ul runnerului va fi folosit in cadrul .gitlab-ci.yml

Atunci cand vi se cere imaginea de docker, specificati docker:19.03

Observati ca trebuie sa specificati aceeasi cale de bind mount, ca la prima comanda

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.

Veti gasi fisierul la calea specificata in comanda de rulare de la etapa 1 (cea de instalare)

?800

Observati liniile marcate cu un punct verde

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:

sudo docker restart gitlab-runner

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.

Va trebuie sa scrieti cate un script .gitlab-ci.yml pentru fiecare repository. Scripturile sunt, oricum, similare.

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

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

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

Observati cum IP-ul este host.docker.internal desi Portainer a generat webhook utilizand localhost

Rularea configuratiei de laborator

Pentru a rula exemplul din laborator, este nevoie sa efectuati urmatoarele comenzi in repository-ul Configs

docker stack deploy -c stack-kong.yml lab4-cluster
docker stack deploy -c portainer-agent-stack.yml portainer

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

git push -u origin master

ar trebui sa vedeti executia cu succes a unui pipeline din panoul CI/CD al repository-ului.

idp/laboratoare/06.1619015885.txt.gz · Last modified: 2021/04/21 17:38 by radu.ciobanu
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