1.2 A quoi sert Docker ?

Dans un monde idéal, je répondrais à cette question de manière très pragmatique et sans équivoque : à faciliter la vie des développeurs. Docker a permis de signer la fin de la fameuse phrase d'un ancien temps qui faisait fureur : "Pourtant, ça marchait sur ma machine !".

Mais en réalité, la réponse est un peu plus nuancée. Chaque solution technique vient avec son lot de nouveaux défis. Écrire un Dockerfile, c'est facile. Mais écrire un Dockerfile sans faille, sécurisé, léger et rapide à déployer, c'est une tout autre histoire.

1. La réalité face à l'IA et la complexité

Au fil du temps, les applications se sont développées, les frameworks ont gagné en complexité et le nombre de dépendances embarquées est devenu parfois difficilement gérable. Docker permet de résoudre une grande partie de ces problèmes de déploiement, à condition de respecter les bonnes pratiques.

À l'ère de l'intelligence artificielle, il est très tentant de demander à Gemini, Claude ou ChatGPT de dockeriser notre application. Ça dépanne bien, mais l'IA ne fait pas tout. C'est à vous de sécuriser l'image, de choisir les bonnes versions (les tags), d'appliquer les mises à jour et surtout d'éviter de copier des fichiers sensibles ou ultra-lourds (coucou les dossiers node_modules ou vendor qui doivent rester à la porte grâce au .dockerignore).

2. Le défi des architectures (ARM vs x86)

On dit souvent que Docker sert à packager son application de manière simple pour la déployer sur n'importe quelle machine. C'est vrai, mais c'est un petit raccourci.

Aujourd’hui, il existe plusieurs architectures matérielles (x86, ARM64, AMD64...). Et de manière très factuelle, vous ne pouvez pas prendre un conteneur compilé basiquement sur un Mac M1/M2/M3 (qui tourne sous architecture ARM64) et espérer qu'il tourne magiquement sur un serveur distant classique (souvent en AMD64).

Parce que Docker n'est pas un système de machine virtuelle (VM) complet. C'est un outil de conteneurisation qui partage le noyau (kernel) du système hôte (sur Linux nativement, ou via une VM allégée cachée sur Mac et Windows). La compilation des images est donc intrinsèquement liée au système sur lequel vous lancez le build.

La solution ?

Il existe un outil magique intégré nommé buildx. Il permet de créer des builds cross-platform et de faire sauter cette barrière matérielle. Grâce à lui, un développeur sur macOS peut compiler de manière transparente une image destinée à un serveur Linux ou Windows.

3. Au-delà de l'application : l'écosystème complet

Docker ne se cantonne pas uniquement à faire tourner votre code. Il permet aux développeurs de lancer tout l’écosystème qui entoure leurs applications (les bases de données, les services de cache, d’autres microservices...) grâce à Docker Compose. Cet outil va lancer plusieurs conteneurs en simultané et les faire communiquer entre eux dans un réseau privé, selon une configuration que vous avez établie.

Et comme on l'a vu plus haut, en production, Docker Swarm prend le relais. Il brille par sa simplicité de mise en place et reprend la logique des fichiers Docker Compose. Il va plus loin en gérant l'orchestration : autoscaling, haute disponibilité, et mise à jour de vos conteneurs sans interruption de service (rolling updates).

Docker est un outil de conteneurisation incontournable pour le développement, mais c'est aussi une plateforme robuste qui sert en production à manager une multitude d’applications de manière sécurisée, isolée et propre.