Utilisation avancée du CI/CD de Gitlab

Workflows complexes

Dans les chapitres précédents, nous avons mis l’accent sur la création d’images Docker multi-architecture et la configuration du CI/CD était plutôt simple.

Dans la pratique, le fichier “.gitlab-ci.yaml” est beaucoup plus long et le workflow plus complexe. Il y aura plusieurs phases (stages) et dans chaque phase il y aura plusieurs tâches (jobs) Certaines tâches se feront dans des conditions données (only/except et rules). Par exemple, on ne fera pas la même chose si il y a un nouveau tag dans le dépôt git, si le CI/CD est lancé suite à un merge request ou si on fait un commit dans la branche main.

Jetez un coup d’œil au fichier de configuration du dépôt de GitLab lui-même pour vous en faire une idée. Et si ça vous semble peu, regardez les dernières lignes qui importent le contenu du répertoire. .gitlab/ci

Etudiez aussi l’utilisation du mot clé extend pour simplifier des configurations complexes.

Pour maîtriser le CI/CD de GitLab, il est important que cous compreniez le concept d’artifact et que vous sachiez utiliser les caches efficacement. Lisez le chapitre sur les releases de GitLab (principalement la partie qui explique comment produire une release depuis le CI/CD) pour apprendre comment publier un artifact sur GitLab.

Déploiement sans interruption de service

Pour les services en ligne, il n’est souvent pas acceptable d’interrompre le service pendant le déploiement d’une nouvelle version. C’est d’autant plus important si on décide de faire des déploiements très fréquents.

Voici quelques liens qui vous donnent des pistes pour permettez un déploiement sans interruption de service :

• https://octopus.com/blog/blue-green-red-black
• https://www.redhat.com/en/topics/devops/what-is-blue-green-deployment
• https://circleci.com/blog/canary-vs-blue-green-downtime/

Liens

Étudiez le contenu de ces liens pour apprendre comment utiliser le CI/CD de GitLab efficacement :

• https://docs.gitlab.com/ee/ci/
• https://docs.gitlab.com/ee/ci/yaml/index.html
• https://about.gitlab.com/topics/ci-cd/continuous-integration-best-practices/
• https://about.gitlab.com/blog/2022/02/03/how-to-keep-up-with-ci-cd-best-practices/

Votre propre Runner

Les runners partagés dans le réseau de l’école sont dans un cluster Kubernetes et permettent de faire la plupart des choses, mais parfois vous avez besoin de votre propre runner. C’est principalement dans les cas suivants :

• Vous avez besoin de matériel spécifique (GPU, matériel réseau …)
• Vous devez connecter d’autres systèmes (programmation de systèmes embarqués …)
• Vous avez besoin de plus de ressources (CPUs plus rapides, plus de RAM …)
• Vous avez besoin d’une architecture différente (Apple, ARM …)

Votre Docker peut être affecté à un projet donné ou à un groupe. Faisons un exemple avec un groupe.

Commencez par démarrer un runner sur votre machine à l’aide d’une image Docker. Créez tout d’abord un volume pour sauvegarder la configuration :

docker volume create gitlab-runner-config

Démarrez maintenant le runner :

docker run -d --name gitlab-runner --restart always \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -v gitlab-runner-config:/etc/gitlab-runner \
    gitlab/gitlab-runner:latest

Dans votre groupe allez dans “CI/CD” → “Runners” et cliquez sur “Register a group runner”. Vous obtiendrez un “Registration token”.

Enregistrez votre runner :

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

et répondez aux questions :

Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab.forge.hefr.ch/
Enter the registration token:
YOUR-REGISTRATION-TOKEN
Enter a description for the runner:
[SOME-HEXADECIMAL-VALUE]: my-runner
Enter tags for the runner (comma-separated):
osx
Registering runner... succeeded
Enter an executor: docker, shell, ssh, docker+machine, instance, kubernetes, custom, docker-ssh, parallels, virtualbox, docker-ssh+machine:
docker
Enter the default Docker image (for example, ruby:2.7):
python:3
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"

Votre runner est fonctionnel et apparaît dans l’interface web

Pour l’utiliser, spécifiez un tag que vous avez configuré (osx dans l’exemple ci-dessus) dans votre fichier “.gitlab-ci.yml”

Vous pouvez supprimer votre runner avec les commandes suivantes :

docker rm --force gitlab-runner
docker volume rm gitlab-runner-config

Supprimez aussi le runner de votre groupe dans l’interface web.