Même le plus petit projet mérite d’avoir son pipeline CI/CD (Partie 3) : le déploiement continu

Dans le précédent article, nous avons vu comment automatiser le déploiement de notre application à la suite d’un commit sur la branche master de notre dépôt Gitlab. Il serait alors utile et intéressant de pouvoir le généraliser à toutes les branches. Voilà ce que nous allons voir dans cette 3e partie de l’article.

L’idée désormais est d’obtenir une image Docker par feature branche. Ceci implique de demander au serveur de démarrer un containeur à chaque fois qu’une branche est poussée sur Gitlab. Dans ce cas, nous avons besoin d’un moyen permettant au serveur de router les requêtes HTTP vers le conteneur approprié. Par exemple, les requêtes adressées à l’URL master.blog.meritis.fr doivent se rediriger vers le conteneur principal (celui de la branche master), tandis que les requêtes adressées à feat-ci-config.blog.meritis.fr doivent être redirigées vers le conteneur relatif à la branche feat-ci-config.

Effectuer ce type de routage est le rôle d’un Reverse Proxy. Et il en existe un excellent adapté pour Docker : il s’appelle Traefik !

Mise en place de Traefik

Puisque nous utilisons Docker, nous déploierons Traefik sur notre VM à l’aide de Docker également. Nous allons tout mettre dans le répertoire /opt/traefik.

Afin que Traefik puisse fonctionner correctement, nous avons besoin d’un réseau Docker dédié. Créons-le et appelons-le « Web » :

Créons maintenant un fichier nommé docker-compose.yml dans notre répertoire Traefik dans lequel nous pouvons copier le contenu ci-dessous :

/opt/traefik/docker-compose.yml

Vous devez changer le nom de domaine (mydomain.fr) dans votre configuration. Pensez également à installer Docker Compose si vous ne l’avez pas.

C’est fait ? Démarrons alors Traefik !

Pour vérifier que tout va bien, accédez à l’URL http://{your_vm_ip_address_or_dns}:8080 pour voir le dashboard Traefik. Nous y retournerons une fois que nous aurons déployé un nouveau containeur.

Si vous souhaitez en apprendre davantage, consultez la documentation Traefik.

Rediriger les requêtes HTTP vers le bon conteneur Docker

Les requêtes HTTP provenant de Traefik doivent être acheminées vers le conteneur approprié. Cela se fait en fonction du nom de domaine.

Comme indiqué précédemment, les demandes adressées à master.mydomain.fr doivent être redirigées au conteneur principal (celui de la branche master), tandis que les requêtes sur feat-ci-config.mydomain.fr doivent être adressées à la branche feat-ci-config.

Pour y parvenir, vous devez configurer votre DNS afin que mydomain.fr et *.mydomain.fr pointent sur la même adresse IP.

Utiliser xip.io

Si vous ne disposez pas d’un nom de domaine et que vous avez la flemme de chercher à en acheter un puis de le configurer, ne vous inquiétez pas, j’ai une petite astuce pour vous qui ne coûte rien 😉

Nous allons utiliser xip.io. De quoi s’agit-il ? Xip.io est un nom de domaine magique 😀qui fournit un DNS générique pour toute adresse IP dans le monde.

Par exemple, si l’adresse IP de mydomain.fr est 220.20.30.20 alors 220.20.30.20.xip.io pointe sur “220.20.30.20“. Mieux encore : master.220.20.30.20.xip.io pointe également sur220.20.30.20“.

Ainsi, pour notre branche feat-ci-config, on peut créer et déployer un conteneur, et configurer Traefik pour router toutes les requêtes adressées à feat-ci-config.[my-ip-adress].xip.io vers le conteneur ayant le tag feat-ci-config.

Et voilà, nous avons fini ! Vraiment ? Mais non, cela ne suffit pas. Il faut en effet désormais informer nos containeurs docker de l’arrivée de leur nouvel ami Traefik !

Configurer les containeurs Docker avec Traefik

Traefik fonctionne avec les étiquettes (ou labels) Docker. Lorsqu’un conteneur démarre, il analyse ses labels et achemine les requêtes vers ce conteneur en fonction de ses labels.

Ces étiquettes peuvent être ajoutées directement lors du démarrage du conteneur ou être intégrées à l’image Docker lors de sa création.

Nous allons mettre des labels dans l’image Docker et également dans la commande permettant de démarrer le conteneur pour tout ce qui relève des labels dynamiques (ceux qui seront créés par Gitlab CI/CD).

Les labels sont à ajouter dans le fichier Dockerfile.

LABEL traefik.docker.network=web traefik.enable=true traefik.port=8888 traefik.default.protocol=http

Ici, nous avons rajouté 4 labels :

  • traefik.docker.network=web : c’est le nom du réseau Docker à utiliser pour accéder à ce conteneur
  • traefik.enable=true : explicite
  • traefik.port=8888 : le conteneur écoute sur le port 8888
  • traefik.default.protocol=http : le conteneur utilise le protocole HTTP

Nous allons ajouter deux autres labels au niveau du job Gitlab permettant de déployer notre application. Plus précisément, dans la commande permettant de démarrer un containeur :

  • traefik.backend=${IMAGE_NAME} : c’est tout simplement le “nom” du conteneur cible dans Traefik. Il pourrait avoir n’importe quelle valeur mais devrait être unique pour notre conteneur (sinon nous devrons faire de l’équilibrage de charge).
  • traefik.frontend.rule=Host:${TAG_IMAGE}.${DNS} : c’est la règle utilisée pour router les requêtes destinées à ce conteneur. Ici, la règle est Host:${TAG_IMAGE}.${DNS} qui est la concaténation de deux variables que nous avons déclarées dans notre manifeste Gitlab CI (voir la première partie de l’article). La valeur serait alors une URL qui pointe sur un sous-domaine de notre DNS ayant comme nom celui de la branche actuelle.

Déploiement automatique de nos feature branches

Avec Traefik configuré et nos conteneurs intégrant les bons labels, nous sommes prêts à déployer une version de notre application par feature branche.

Nous allons donc éditer notre fichier .gitlab-ci.yml pour activer les étapes “release” et “deploy-staging” à toutes les branches commençant par “feat-” et qui auparavant étaient seulement activées pour la branche master.

Comment procéder ? Grâce à la directive “only” permettant de mettre en place des contraintes sur l’exécution d’une tâche. Nous pouvons dire qu’une tâche s’exécutera uniquement sur l’événement d’un push sur master ou d’une branche préfixée par la valeur “feat-“.

L’expression régulière /^(feat-|master).*$/ permettrait de matérialiser cette condition au niveau du job où nous voulons l’appliquer.

Voilà alors le contenu de notre manifeste Gitlab après ces changements :

Et voilà notre pipeline CI/CD permet dorénavant de déployer une nouvelle version de notre application à chaque fois qu’une branche est créée et poussée 😃. Cela est indiqué dans le dashboard Traefik où nous pouvons voir qu’une nouvelle règle de routage a été ajoutée pour cette branche afin de pointer sur un containeur Docker qui lui a été dédié.

L’application relative à la feature branche feat-ci-config est également accessible sur l’URL feat-ci-config.{ip-address}.xip.io

Les environnements Gitlab

Mais ce n’est pas encore fini, il reste encore un petit souci ! 🙁

Jusqu’à présent, nous n’avons aucun moyen de supprimer l’application et le containeur associé lorsqu’une branche est détruite (dans le cas où il n’est plus nécessaire de l’utiliser). À force de créer plus de branches, nous empilons des containeurs Docker sur notre serveur jusqu’à ce que celui-ci soit saturé et ne démarre plus.

Il faudrait ainsi trouver un moyen, depuis l’espace Gitlab ou lors de la suppression d’une branche, d’arrêter les containeurs inutiles et de supprimer les images Dockers associées. C’est là que les environnements Gitlab entrent en jeu 😀

En attendant de les voir dans la prochaine et dernière partie de cet article, je vous présente la manipulation à effectuer afin d’arrêter et de supprimer un containeur.

Connectez-vous en SSH sur le serveur puis, avec le nom du containeur et celui de l’image à supprimer, exécutez ces commandes :

Nous verrons aussi comment répondre à des problématiques d’optimisation du temps de build du projet ainsi que celui de son déploiement. Des nouveaux ajustements bonus seront également apportés à notre pipeline.

Lire aussi

Même le plus petit projet mérite d’avoir son pipeline CI/CD (Partie 1)
Même le plus petit projet mérite d’avoir son pipeline CI/CD (Partie 2)

Laisser un commentaire

MERITIS ICI. ET LÀ.

Carte Meritis

Meritis Finance

5 – 7, rue d’Athènes
75009 Paris

+33 (0) 1 86 95 55 00

contact@meritis.fr

Meritis PACA

Les Algorithmes – Aristote B
2000 Route des Lucioles
06901  Sophia Antipolis Cedex

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Europarc de Pichaury – Bâtiment B5
13290 Aix-en-Provence

+33 (0) 4 22 46 31 00

contact@meritis-paca.fr

Meritis Technologies

5 – 7, rue d’Athènes
75009 Paris

contact@meritis-technologies.fr

+33 (0) 1 86 95 55 00


Contactez-nous

Pour connaître et exercer vos droits, concernant l'utilisation des données collectées par ce formulaire, veuillez consulter la page sur notre politique de confidentialité.