blog.bressure.net

Depuis avril mon infra personnelle me permet d’avoir des environnements de pré-prod très facilement pour tester mes applications web sans les exposer sur internet mais en étant sous tous les autres aspects identiques à la production. Cet article d’avril montre comme je m’y prends.

Si la partie infrastructure pour le run est résolue et la partie développement ne l’était pas. J’entends par développement toute la phase amont où on écrit du code. Dans mon cas le code était constitué principalement de fichiers docker-compose.yml et parfois de Dockerfile. En effet mes projets consistaient surtout à assembler des conteneurs existants. Rien que cela m’obligeait déjà à faire des copier/coller de projet existant et à modifier les nom dans les docker-compose et autre .gitlab-ci !

Puis je me suis mis à développer mes propres images docker et un motif de code source a émergé avec un Dockerfile toujours partant d’une debian par exemple notamment avec l’image Mediagoblin. Cela m’a amené à développer une image docker qui permet de générer des projets adaptés à mes besoins depuis le code (Dockefile ou docker-compose) en passant la la construction jusqu’au déploiement (CI/CD)

De la génération du code source…

J’ai 2 types projets:

• production d’image
• application utilisant ces images

Puisque j’applique une distinction nette entre production d’image et mise leur en œuvre, le contenu des sources est pour le moins différents dans chacun des types de projet. Donc j’ai produit 2 images docker l’une pour produire des projet Dockerfile et l’autre pour produire des projets docker-compose. Néanmoins le mécanisme de génération est factorisable car il ne s’agit finalement que de copier un squelette de code source et de la paramétrer par nom du projet notamment. Il y a donc une image parente qui factorise les étapes de productions communes.

Cela me rappelle le plugin maven archetype qui permet de générer un nouveau projet déjà fonctionnel ie constructible avec maven. Mon idée était d’aller un peu plus loin. Si avec docker je produis des projet docker/docker-compose, je veux également que le projet s’inscrive dans le CI/CD de Gitlab. Mes archétypes doivent générer un gitlab-ci fonctionnel.

… le CI/CD

Le CI/CD est un sujet qui me tiens vraiment à cœur car c’est un processus que certain confond avec le développement en production. Il n’en est rien: au contraire, le développeur développe sur son poste et un outillage permet de manière contrôlée et automatisée d’amener le code produit en production.

Pour comprendre l’objectif du CI/CD dans un projet de type docker ou docker-compose, il faut revenir à la définition des étapes qui partent du code et amène au déploiement en production. Dans sa forme la plus simple on a les étapes:

• construction (build) : création du produit
• test (test) : on vérifie que le produit fonctionne
• déploiement (deploy): le produit est accessible à l’utilisateur

CI/CD d’un projet Dockerfile

Le produit correspondant à un projet Dockerfile ( par raccourci docker) est une image. Dans la phase de construction le CI/CD doit donc exécuter la commande

docker build

Le test de l’image consiste à vérifier à minima que l’image se lance dans un environnement vierge (docker in docker) via un

docker run -d

Enfin le déploiement du produit pour qu’il soit à disposition de l’utilisateur consiste à mettre l’image sur un registry. Et uniquement ça ! Lancer l’image sur un serveur n’est pas un déploiement d’image car l’utilisateur d’une image une application via docker-compose. Certes certaines images (comme apache) peuvent se lancer toutes seules mais d’autres sinon la plupart doivent être associées à d’autres images pour être utilisées ou encore certaines images sont interactives (ou exécutable one shot) donc la notion de déploiement sur un serveur n’a pas de sens !

Donc au final la phase de déploiement se résume à faire

docker push

CI/CD d’un projet docker-compose

Pour rappel un tel projet ne construit pas d’image mais assemble des images pour obtenir une application fonctionnelle. La phase de construction est donc vide.

La phase de test consiste à démarrer l’application dans un environnement vierge (docker in docker):

docker-compose up -d

Enfin le déploiement de l’image se fait en 2 étapes. La première automatique en environnement préprod (staging) et la seconde en production nécessite chez moi une intervention humaine tant que les tests ne sont pas entièrement automatisés.

Au final les étapes pour les projets docker-compose sont:

• test
• staging
• production

Cas concret avec Mediagoblin

C’est la mise en place de Mediagoblin dockerisé qui a motivé récemment la création des projets archétypes. j’ai pu tester le développement des archétypes pour la génération de mon image Mediagoblin et la création de l‘application Mediagoblin.

Ce premier jet permet d’ouvrir des pistes pour travail :

• limiter les déploiements en fonction de la branche
• forcer le déploiement en production (et la préprod) uniquement si c’est une release
• gérer les construction dépendante : souvent l’application dépend du service du même nom (ou pas), l’utilisation de sous-module git pourrait permettre de travailler simultanément sur 2 projets tout gardant l’indépendance du sous-module

La suite au prochain numéro.