Tout d’abord, regardons comment fonctionne un pipeline GitLab. Un pipeline GitLab se base sur un fichier .gitlab-ci.yml qui doit se trouver dans votre repository, et contient les différentes étapes de votre pipeline. En voici un exemple :
Comme vous pouvez le voir, on a ici défini trois stages : test, build et deploy. On a aussi 2 jobs qui appartiennent aux stages : lint-test et build-push (ici nommés d’après les actions qu’ils exécutent, mais on aurait pu les nommer d’après leur stage).
Les stages sont exécutés à la suite, en suivant l’ordre prédéfini. Si il y a plusieurs jobs pour un stage, ils sont exécutés en parallèle.
Dans ces exemples, ils sont exécutés à chaque fois que du code est push sur le repository. GitLab permet d’ajouter du filtrage à cette exécution : par exemple, exécuter un job sur une branche ou un tag spécifique, ou déclencher une exécution manuellement. Vous pouvez remarquer que le stage “deploy” ne contient aucun job : on reviendra sur ce point lors de la dernière partie de ce tutoriel.
Pour comprendre le reste de cette CI, il est important de regarder ce qu’est un gitlab-runner. C’est le processus qui exécute les jobs : un gitlab-runner peut être un processus qui tourne sur une VM, un pod dans Kubernetes, un docker etc, et peut être configuré pour scale en fonction de vos besoins. Il est possible d’avoir plusieurs runners, de les différencier en utilisant des tags, et de leur assigner des jobs ou des repositories spécifiques.
Quand on exécute un job, on peut choisir d’utiliser l’image de runner par défaut, ou bien de l’exécuter dans une image spécifique. Si on reprend l’exemple ci-dessus, le job “lint-test” est exécuté dans une image de node :11.10.1.
On a aussi configuré un service pour le second job : un service est une image Docker liée au job et exécutée au même moment. Par exemple, on peut l’utiliser pour lier des instances de bases de données pour des tests, ou utiliser du docker-in-docker comme on l’a fait ici.
Utiliser des runners de type Docker+Machine pour exécuter les stages de test et build est une bonne pratique car ces stages consomment plus de ressources que le dernier. Pour déployer ce type de runners, nous vous conseillons de suivre la documentation GitLab.
Concentrons-nous sur le stage “deploy”. Pour déployer notre application sur un cluster Kubernetes, il vaut mieux disposer d’un gitlab runner dans un pod. Le chart Helm officiel permet d’en déployer un en quelques minutes, et permet d’utiliser la fonctionnalité serviceAccount de Kubernetes pour éviter de gérer l'authentification avec l’API server directement dans la CI.
Voici un fichier values.yaml simplifié pour le chart Helm :
Vous devez avoir configuré Helm dans votre cluster (avec Tiller pour Helm 2.x) avant d’exécuter les commandes suivantes. Remplissez le fichier values.yaml ci-dessus avec les valeurs adéquates, et exécutez les deux commandes ci-dessous :
Votre gitlab-runner devrait maintenant tourner dans votre cluster Kubernetes, et être visible dans l’interface Gitlab.
Pour déployer le projet avec le job ci-dessus, le projet doit utiliser Helm, et il faut donc préciser le chemin du chart Helm.
Notons que les tags sont utilisés pour sélectionner le runner que l’on vient de déployer.
Le runner et le pipeline sont maintenant prêts, il ne reste qu’à ajouter le job vu précédemment au fichier .gitlab-ci.yml pour déployer l’application Kubernetes avec GitLab-CI !
GitLab met aussi à disposition un outil d’intégration Kubernetes qui permet de gérer et de surveiller le cluster via l’interface GitLab.
Si vous n’arrivez toujours pas à vous décider entre GitLab-CI, GitHub et CodeBuild, vous pouvez lire cet article : “Create a CodePipeline to deploy an EKS Cluster with Helm” pour vous former votre propre opinion.
Vous pouvez aussi regarder nos trucs et astuces pour améliorer votre productivité sur Kubernetes pour aller plus loin sur l’amélioration de vos pipelines.