This is an old revision of the document!
Î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 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.
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.
Conceptul de CI/CD se referă la:
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:
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:
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 faci de a lansa un runner în execuție este sub formă de containere Docker.
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:
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:
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:
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
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.