blog.bressure.net

Application, Gestion de projet, Paramétrage

Limites du gitlab-runner pour déployer les applications docker-compose

admin

J’utilise depuis près d’une an et demi le gitlab-runner comme outil de déploiement. En effet au sein du CI/CD il me suffit d’utiliser un runner positionné sur la bonne machine cible et je dispose alors d’un clone des sources. Puis il me suffit d’indiquer dans le gitlab-ci de lancer l’application par une incantation de type:

docker-compose up -d
Gitlan runner pour lancer les applications et donc les « déployer »
Un gitlab-runner non conteneurisé dit de bootstrap permet d’initialiser la chaine de déploiement en déployant le gitlab-runner de déploiement

Avantages du runner

Ce moyen permet d’éviter de gérer le rapatriement des binaires à déployer. Dans le cas d’une application docker-compose le binaire c’est le fichier compose. Donc le git clone réalisé par le runner répond à ce besoin de rapatriement. En corollaire on voit qu’il n’est pas nécessaire de gérer un dépôt de binaires ou d’artefacts tel que Nexus puisque c’est le dépôt de source qui fait office de dépôt de binaire.

Limites de cette méthode artisanale

C’est une méthode qui fonctionne bien dans le cas d’application docker-compose. Néanmoins on voit clairement que dans le cas général où une application ne s’exécute pas à partir de ses source que cela ne suffit pas.

Déployer des sources

Il faudrait reconstruire l’application ce qui est normalement possible car on fait tout pour que la construction soit répétable Il y a d’ailleurs des distributions Linux qui compilent les applications pour les installer. Je pense notamment à Gentoo. Cela pose alors le problème de puissance de traitement: compiler c’est coûteux ! très coûteux.

Un runner par cible

Comme le runner s’exécute sur la machine cible, même dans le cas favorable où l’application s’exécute à partir des sources, il faut installer le runner sur cette machine cible. C’est un tâche d’administration fastidieuse.

Lors de la mise en place de mon instance Mediagoblin je voulais avoir un environnement où déployer la branche de développement. Je voulais que cet environnement soit physiquement et logiquement disinct bien sur de la production et de la pré-production.

Pour cela il faut installer un runner sur l’environnement d’exécution de la branche de développement et inscrire le runner à Gitlab. Mais ce n’est pas tout.

Imbrication avec le gitlab-ci

Pour que le runner soit utilisé afin de déployer sur l’environnement ciblé, il faut qu’une étape dédiée dans le pipeline de construction soit configurée. Cette étape doit sélectionner le runner et donc l’étape est dédié à un environnement. On voit que l’ajout d’environnement à la volée n’est pas sans intervention manuelle:

Environnement à la volée

Or je vais avoir besoin d’environnement en masse si je veux pousser le concept de branche vivante à toutes les branches d’un projet. Je veux pouvoir créer un environnement dès que je veux exécuter une branche. Ainsi une branche dédiée à une fonctionnalité ( branche dite feature), n’est plus cantonnée au stade du développement. Ce que jeux dire c’est qu’on pourra voir l’exécution de l’application correspondant à cette branche sur un environnement accessible à tous, sans passer par l’application qui tourne sur le poste du développeur.

Author: Vincent DriessenOriginal blog post: http://nvie.com/posts/a-succesful-git-branching-modelLicense: Creative Commons BY-SA

Le fameux « ça marche chez moi » pourra réellement être vérifiable et même « démonstrable ». Une branche de feature qui n’est pas encore remontée sur la branche de développement (branche qui possède son environnement vivant au même titre que la prod ou la staging) pourra faire l’objet d’une démonstration. Toute le réglage d’infra pour rendre cela possible doit être automatique !

Solution temporaire

Comme actuellement je développe beaucoup j’ai besoin au moins d’un environnement de déploiement pour la branche de développement. Afin de limiter le travail d’installation de runner et de configuration de mon reverse proxy TLS, je vais me servir de l’environnement staging qui existe sur mon infra pour y déployer les applications en cours de développement. Moyennant une adaptation du gitlab-ci pour modifier le fichier compose staging j’arrive à avoir le fameux environnement live !

environnement staging à la demande

La modification du fichier compose est effectuée par une étape du CI/CD dédiée au déploiement des branches. Ici le squelette utilisé par le prochet archetype de type application pour générer le gitlab-ci :

deploy_review:
  stage: staging
  tags:
    - infra
    - docker
    - regular
  script:
    - echo "Deploy a review app"
    # ajouter un déploiement avec docker-compose
    - echo "on fabrique un docker-compose spécifique"
    - sed -i "s/%%NOM_PROJET%%.bressure.net/$CI_ENVIRONMENT_SLUG.bressure.net/g" docker-compose.staging.yml
    - sed -i "s/staging_%%NOM_PROJET%%/$CI_ENVIRONMENT_SLUG/g" docker-compose.staging.yml
    - docker-compose pull
    - docker-compose -p $CI_ENVIRONMENT_SLUG -f docker-compose.yml -f docker-compose.staging.yml up -d
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: https://$CI_ENVIRONMENT_SLUG.bressure.net:444
    on_stop : stop_review
  only:
    - branches
  except:
    - master

Au même titre que staging cet environnement n’est pas public et n’est accessible que depuis mon réseau interne. C’est une bonne chose. Toutes les branches bénéficient d’un déploiement sur un environnement live. C’est une bonne chose aussi. En revanche on surcharge l’infra et la positionnement physique de l’environnement sur l’infra se fait via un concept gitlab dans le CI/CD parle choix du runner en fonction des tag infra, docker et regular. La solution reste donc imbriquée et dépendant de GitLab. Décider de déployer par exemple sur une autre machine signifie modifier le gitlab-ci. Or la configuration du déploiement ne devait pas être du ressort du gitlab-ci. C’est une solution temporaire en attendant la suite.

Vers un déploiement industriel

Quand je me contentais de 2 environnements : prod et staging, je ne voyais pas l’utilité de mettre en place une méthode plus industrielle. Mais lorsque j’ai commencé avec Mediagoblin à capitaliser sur la création de projet dans GitLab à travers les archetype de génération de projet, j’ai mis en lumière les limitations évoquées précédemment.

Les caractéristique de l’infrastructure et de l’outillage que je veux mettre place pour dépasser ces limitations sont les suivantes:

Afin d’aller vers la cible suivante où le runner ne définit plus l’environnement d’exécution et les runners sont virtuellement interchangeables quel que soit leur localisation !

CI/CD d’un projet non exécutable entant que serveur
Projet produisant un logiciel exécutable en tant que serveur

Par rapport aux diagrammes du début de l’article on voit que l’aspect conteneurisation a disparu de la réflexion. La solution sera bien sur conteneurisée mais l’implémentation ne doit pas être influencée par la conteneurisation.

Tags:

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Back to top