Docker et Make sur nos projets : on voulait améliorer le confort de nos développeurs, maintenant ils sont accro

Chez Troopers, nous utilisons Docker et Make pour simplifier la gestion technique de tous nos projets depuis 2019. C'est une Ouvre une nouvelle fenêtreconférence de Ouvre une nouvelle fenêtreRomain Gautier qui nous a ouvert les yeux à l'époque.

Je vais vous expliquer pourquoi je n’imagine plus faire sans Docker et Makefile pour nos projets, tout en évitant d’entrer dans une présentation exhaustive et trop technique.

Pourquoi utiliser Docker ?

En deux mots : pour reproduire un environnement projet rapidement, sans dévier de la configuration cible commune à tous. Sans cela, on risque de perdre du temps à chaque fois qu’un nouveau développeur arrive sur le projet.

Docker est une solution de virtualisation applicative : Docker ne crée pas de machines virtuelles, mais des conteneurs. La configuration logicielle (système d’exploitation, logiciels installés etc) des conteneurs est définie au travers de fichiers texte appelés Dockerfile.

Nos projets ont des configurations diverses : Apache ou Nginx ? MySQL ou PostgreSQL ? ElasticSearch ? Sans parler de leurs versions, ni de celles de PHP, Node…

Nous définissons un Dockerfile pour chacun de ces éléments et Docker nous permet de définir quelles applications exécuter dans quel conteneur. Ces applications sont isolées de la machine hôte : machine de développeur, serveur d’intégration continue, serveur de (pré)production… Fini les conflits de versions lorsque l'on change de projet, fini les dépendances manquantes sur le serveur.

Chaque projet contient sa propre configuration Docker, qui verrouille les versions utilisées mais aussi les tâches d'installation et de configuration. Besoin d'un module PHP peu courant ? Cela sera inscrit dans la configuration et installé automatiquement dans tous les environnements du projet.

Et même si l’environnement de production n'est pas dockerisé, ce n'est pas un problème : vous pouvez reprendre la procédure décrite dans le Dockerfile et être certains de construire un environnement compatible.

Docker-compose : "un service, un conteneur"

Dans chaque projet, la configuration Docker est découpée en plusieurs fichiers. Cela permet de configurer séparément chaque service du projet (serveur web, base de données, application PHP ou JS...).

Lorsque votre projet évolue et qu'il requiert un nouveau service, vous n'aurez qu'à ajouter la configuration Docker de ce service, construire et lancer le conteneur et configurer votre projet pour qu'il communique avec...

Aïe ! Faire communiquer des conteneurs Docker entre eux, ce n'est pas très facile lorsque l'on se limite à l'outil Docker de base. C'est là le rôle de docker-compose : permettre à nos conteneurs de discuter entre eux avec une configuration minimale.

Déjà deux outils supplémentaires…

J'ai remarqué qu'à ce stade, les développeurs ne sont pas forcément convaincus : Docker et docker-compose ajoutent de la complexité, ce sont de nouveaux outils à apprivoiser. Et surtout, on se retrouve avec des commandes à rallonge.

Alors que je pouvais tranquillement faire un

Make à la rescousse

Pour pallier ce problème, on utilise un outil très répandu : Make. On peut imaginer Make comme un cuisinier à qui l’on donne un livre de recettes (le makefile). On peut alors lui demander d’exécuter une recette (une “cible” du makefile).

On va lister les commandes à rallonge dans un fichier makefile, et définir des cibles plus courtes et plus simples à mémoriser, comme ceci :

Le but de Make est de "fabriquer" des fichiers ou répertoires. Dans mon exemple, lorsque je vais lancer la commande

On peut aller plus loin et lier entre elles les cibles.

Make nous donne alors un avantage très précieux : lorsque j'utilise

• S'il n'existe pas, il va le créer grâce aux commandes définies ;
• Mieux, si le dossier
  est plus récent que le fichier
  , Make va considérer que le dossier est à jour et donc ne rien faire
• Et si le fichier
  est plus récent, Make va exécuter les commandes définies et mettre à jour mon projet.

En résumé, cela permet de chaîner les opérations requises en listant leur dépendances, et de laisser Make faire le tri : il n'exécute que les dépendances requises.

Make permet d'autres choses très pratiques avec les variables, ne serait-ce que pour conserver un fichier lisible. Il y a également une astuce très pratique pour avoir une commande

Make pour toutes les opérations du projet

On va remplir le Makefile avec les commandes d'installation et mise à jour des dépendances. Mais aussi celles permettant de construire et démarrer nos conteneurs Docker. Une fois le système en place, autant l'utiliser au maximum : les tests y seront également automatisés.

Et au final, même le système d'intégration continue va utiliser le Makefile pour construire et tester le projet. Fini les excuses du genre "mais ce test passait sur ma machine !" car les développeurs et l’intégration continue utilisent le même environnement (Docker) et les mêmes commandes (make).

La mort du README

Nos projets n'ont plus de README (ou presque). En général, ces fichiers contenaient des indications plus ou moins à jour pour installer le projet, ou lancer certaines opérations. Maintenant, tout cela est défini dans le Makefile, qui double son rôle de configuration par un rôle de documentation.

C'est un confort très appréciable pour un développeur comme moi : je sais que pour intervenir sur un projet, je dois le récupérer avec la commande

Ça marche, c'est rapide et facilement répétable sur la machine d’un collègue.

Ou bien via un système de cloud pour construire un nouvel environnement de test.

Ou encore en utilisant le système de Ouvre une nouvelle fenêtrereview apps de Gitlab

C'est un pas en avant sur l'industrialisation de nos projets, et une bonne pratique que je vous invite à explorer.