Docker est une des plus grandes innovations qui sont arrivées dans le domaine du développement logiciel dans les 10 dernières années. Par contre, comme toute technologie, il y a de bonnes façons de l’utiliser et de moins bonnes.

J’ai tout d’abord découvert Docker du côté du déploiement. En effet, cette technologie permet de « packager » une application au complet dans ce qu’on appelle un conteneur, et ce conteneur peut rouler sur n’importe quelle plateforme! Ça permet donc aux développeurs de tester leur application sur un poste Windows et de la faire rouler sur un serveur Linux. Mais surtout, le conteneur contient tout ce dont l’application a besoin en termes de dépendances (Java, Node, etc.), ce qui permet d’éviter les problèmes classiques que j’avais en début de carrière.

En effet, « dans mon temps » 🫠, notre environnement de production était monté de toute pièce à un moment X et on continuait de pousser nos builds dessus, en natif, jour après jour. Non seulement, pour certaines technologies, ça nous obligeait à rouler sous Windows, ce qui coûtait très cher, mais en plus, ça nous forçait à nous connecter à l’environnement de production, installer les dépendances manuellement et espérer que tout soit compatible. La moindre mise à jour pouvait briser tout ça ; alors on désactivait le tout, et là, c’était la sécurité qui criait. Bref, ce n’était pas idéal, mais c’était le début de la colonie.

Donc, je crois qu’on peut tous s’entendre sur le fait que déployer une image Docker, c’est le bonheur. Une panoplie de technologies se sont ajoutées par-dessus ça, rendant le tout de « super simple » à « hyper complexe et puissant ». Je pense à Kubernetes, Kamal, Container Apps, etc.

Arrive maintenant « Compose »… et c’est là que ça dérape un peu. Compose permet de définir un fichier YAML et de créer un mini « network » où plusieurs conteneurs Docker sont définis et peuvent interagir entre eux.

J’ai eu beaucoup de misère à comprendre l’intérêt de « Compose » au début, car je l’ai vu utilisé de plusieurs façons assez étranges au fil des années.

Personnellement, je l’utilise pour définir toutes les dépendances de type « service » de mon application, en local, quand je fais du développement. Quand je démarre mon ordinateur et que je suis prêt à développer, je lance mon Docker Compose et j’ai instantanément ma base de données SQL Server, ma base de données InfluxDB et mon broker MQTT. Ensuite, je n’ai qu’à lancer mon application via l’IDE ou la ligne de commande, en natif, et continuer ma journée.

Anciennement, j’aurais fait un long README qui explique comment installer les bases de données et le broker, comment les configurer, quelle version prendre, etc. Maintenant, c’est un Docker Compose et quelques étapes à faire une seule fois (environ une minute), et on est sûrs que tout le monde a la même chose.

C’est quoi l’erreur dont je parle dans le titre ? Développer « en Docker ».

Dans la dernière compagnie pour laquelle j’ai travaillé, des équipes travaillaient entièrement en Docker. On devait donc avoir un plugin Docker dans l’IDE qui démarrait toutes les dépendances de type « service » (Compose) et qui roulait le code lui-même dans un conteneur, et non en natif. C’était lourd en ressources, long à démarrer et ça ajoutait inutilement une couche de complexité. De plus, les plugins « Docker » pour faire ça sont très différents entre IntelliJ, VS Code, Visual Studio, etc. En gros, c’est une fausse bonne idée. Je ne comprends toujours pas, à ce jour, pourquoi ce type de plugin existe et pourquoi des développeurs tiennent à l’utiliser.

Je suis entièrement d’accord pour « streamliner » le setup local et éviter les différences, mais il n’y a, selon moi, aucun avantage à faire rouler le code lui-même en Docker durant le développement. Ça empêche d’utiliser tous les outils natifs d’un IDE, toutes les commandes en ligne de commande, toutes les optimisations. Sans compter que s’il y a des bugs dans le plugin Docker, c’est compliqué à déboguer.

Je comprends qu’il existe certains contextes où développer en Docker peut se justifier, mais dans la majorité des projets applicatifs classiques, les inconvénients dépassent largement les bénéfices.

Êtes-vous un des développeurs qui utilise cette méthode ? Si oui, écrivez-moi pour m’expliquer la raison, car je suis honnêtement très curieux !

En résumé, Docker, c’est super, mais il ne faut pas l’utiliser pour tout non plus !