This is an old revision of the document!
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:
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:
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:
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:
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 </code <code bash> 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.