Î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 runnerilor de GitLab.

Portainer este o platformă Web care permite administrarea unui cluster Docker Swarm. Instrucțiunile oficiale se pot găsi aici.

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

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:2.11.1
    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:2.11.1
    command: -H tcp://tasks.agent:9001 --tlsskipverify
    ports:
      - "9443:9443"
      - "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:

Dashboard-ul Portainer va fi accesibil pe portul 9000. La prima accesare, se setează un utilizator administrator cu o parolă.

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.

De asemenea, Portainer vă facilitează interacțiunea cu Docker Swarm fără a fi nevoie de a da comenzi în terminal, cum ar fi gestionarea secretelor.

Nu doar atât, dar, ca să aveți control complet asupra serviciilor ce pot rula în Swarm, puteți să lansați stiva de servicii direct din editorul de YML din secțiunea Stacks.

Ca Portainer să poată să vă acceseze registrele private, puteți să adăugați acele registre de imagini în secțiunea Registries cu utilizatorul vostru și parola/un token de acces.

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.

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

Pentru a folosi un runner, este nevoie, în primul rând, să se acceseze pagina repository-ului sau a grupului GitLab.

Se intră în meniul de CI/CD al paginii de proiect și apoi se selectează opțiunea „Expand” din dreptul „Runners”.

Configuraera unui runner folosind Docker este simplă și necesită trei pași:

1. instalarea
2. înregistrarea
3. modificarea fișierului de configurație config.toml.

= Instalarea =

Pentru instalare, se rulează următoarea comandă:

$ 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

= Înregistrarea =

Pentru înregistrare, se rulează următoarea comandă și se urmează pașii specificați:

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

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

concurrent = 1
check_interval = 0
 
[session_server]
  session_timeout = 1800
 
[[runners]]
  name = "IDP lab 4 runner"
  url = "https://gitlab.com/"
  token = "jEzCz9PACYL4Y1FB8vs2"
  executor = "docker"
  [runners.custom_build_dir]
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]
    [runners.cache.azure]
  [runners.docker]
    tls_verify = false
    image = "docker:19.03"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    shm_size = 0

Modificările necesare sunt următoarele:

• „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ă:

$ docker restart gitlab-runner

Script-ul .gitlab-ci.yml descrie execuția unui pipeline pe un runner. Puteți observa un astfel de script mai jos.

docker-build-master:
  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:
    - idp
    - lab4

deploy-service-master:
  stage: deploy
  script:
    - apk add --update curl
    - curl -XPOST http://192.168.99.126:9000/api/webhooks/e37c80b1-9315-49d2-b0ad-5b3d8dade98e
  only:
    - master
  tags:
    - idp
    - lab4

Script-ul prezentat mai sus descrie două etape ale pipeline-ului:

• build - codul este construit într-o imagine de Docker și salvat într-un registru
• deploy - serviciul de Docker este încărcat in cluster-ul de Swarm, utilizând un webhook Portainer.

Un pipeline se poate observa din GitLab mergând la meniul „CI/CD” al unui repository, la opțiunea „Pipelines”.