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 este o aplicatie web ce va permite administrarea clusterului de Docker Swarm

Portainer poate rula ca si container separat sau ca si serviciu de Swarm. Va recomandam sa il rulati ca serviciu de Swarm.

#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:

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”

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:

• Gitlab Runners - procese care executa pipelines
• .gitlab-ci.yml - fisier yml de configuratii declarative care descrie ce face fiecare etapa dintr-un pipeline

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 repo-ul oficial al laboratorului.

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.

Pentru a folosi un runner, este nevoie, in primul rand, sa accesati pagina repository-ului sau din pagina grupului, daca folositi grup.

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.

Instalarea unui runner folosind docker este simpla si necesita 3 pasi:

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

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

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

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.

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

Scritpul .gitlab-ci.yml descrie executia pipeline-ului pe un runner. Un exemplu de script este cel folosit in cadrul laboratorului.

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