Docker : Pilier incontournable de la gestion moderne des containers
Introduction
Docker fait partie de ma boîte à outils depuis 2015. De mes premiers docker-compose up chez SFR Business Team à la construction d'images multi-plateforme pour WizOps en passant par les architectures microservices de Bloomflow, Docker a fondamentalement changé ma manière de travailler. En 10 ans de pratique quotidienne et plus de 100 projets, j'ai vu Docker passer du statut de curiosité à celui de standard industriel. Je ne conçois plus un projet sans conteneurisation. Voici pourquoi, avec des exemples concrets de chaque étape de cette évolution.
Du bare metal au conteneur : la révolution silencieuse
Chez SFR Business Team, mes débuts en 2013, on déployait des applications directement sur des VM. Chaque serveur avait sa configuration unique, ses dépendances installées à la main, et son historique de patches accumulé sur des mois. Quand un serveur tombait, le reconstruire prenait une journée complète de travail -- et il n'était jamais tout à fait identique à l'original. Le fameux "ça marche sur ma machine" était notre quotidien.
La mise en place de Docker a tout changé : une application packagée avec ses dépendances exactes, reproductible sur n'importe quel hôte. Chez Epiconcept, la transition a été spectaculaire : on est passé de VM gérées à la main avec Ansible à des conteneurs Docker déployés via GitHub Actions. Le temps de provisionnement d'un environnement applicatif est passé de 2 heures (installation manuelle des dépendances PHP, MariaDB, configuration Apache) à 5 minutes avec un simple docker-compose up. En 4 ans de mission, pas un seul incident causé par une différence d'environnement entre le dev et la production.
Le Dockerfile optimisé : de 1.2 Go à 120 Mo
Un bon Dockerfile fait la différence entre une image de 1.2 Go qui met 3 minutes à se pull et une image de 120 Mo qui démarre en 10 secondes. Sur le backend WizOps (Django), j'utilise un multi-stage build : le premier stage installe Poetry et compile les dépendances C/Python dans un virtualenv, le second stage copie uniquement le virtualenv finalisé et le code applicatif dans une image Alpine minimale. L'image finale fait 180 Mo au lieu de 1.2 Go en single-stage. Le gain n'est pas cosmétique : sur Kubernetes, une image légère se pull plus vite, ce qui accélère le rolling update et réduit le temps de recovery en cas de crash.
Chez TEKYN, le frontend React utilisait le même pattern : un stage Node.js pour le npm run build, puis un stage Nginx Alpine qui ne contenait que les fichiers HTML/JS/CSS statiques et la configuration Nginx. L'image finale faisait 25 Mo. Chez Bloomflow, j'avais imposé une règle stricte : aucune image en production ne dépasse 300 Mo. Cette contrainte forçait les développeurs à optimiser leurs Dockerfiles et à choisir des images de base légères. En 5 ans, cette discipline a évité l'inflation des images que j'observe chez les clients qui ne la pratiquent pas.
Docker dans la CI/CD : le fil conducteur de la livraison
Docker est au coeur de tous mes pipelines CI/CD. Sur WizOps, GitHub Actions construit les images Docker avec Buildx (support multi-plateforme AMD64 + ARM64), les taggue avec le SHA du commit pour la traçabilité, et les pousse sur GHCR (GitHub Container Registry). Chez TEKYN, les images étaient poussées sur AWS ECR pour ECS Fargate. Chez Bloomflow, sur un registre Harbor privé auto-hébergé sur Kubernetes. Le pattern est invariable : build, tag, scan, push, deploy.
Docker Compose reste indispensable pour le développement local. Sur WizOps, un docker-compose up lance PostgreSQL pour le backend Django, et le frontend Nuxt tourne en mode dev avec hot-reload. Chez Epiconcept, le docker-compose lançait l'application complète : MariaDB, PHP-FPM, Apache, et les workers de traitement asynchrone. Fini les "tu as quelle version de PostgreSQL ?" ou "il te faut installer Redis d'abord". Docker Compose standardise l'environnement de chaque développeur et garantit que le docker-compose up du nouveau développeur produira le même résultat que celui du lead tech.
Sécurité Docker : la discipline des environnements sensibles
La sécurité Docker ne s'improvise pas, et certains de mes clients opèrent dans des contextes où elle est non négociable. Chez KNDS (Défense), chaque image était scannée avec Trivy dans la CI pour détecter les CVE connues. Les images de base étaient exclusivement des images officielles Alpine ou distroless, maintenues et auditées. Les conteneurs tournaient en mode non-root avec des capabilities Linux minimales et des profils seccomp qui limitaient les appels système autorisés. Un conteneur compromis ne pouvait ni accéder au filesystem de l'hôte, ni écouter sur des ports non autorisés, ni exécuter de commandes shell.
Chez Bloomflow (ISO 27001), j'ai ajouté Cosign pour la signature cryptographique des images : chaque image buildée dans la CI était signée avec une clé privée, et un admission controller Kubernetes vérifiait la signature avant d'autoriser le déploiement. Une image non signée ou modifiée après le build était rejetée. Ces pratiques ont un coût de mise en place (environ 2 jours), mais elles sont devenues mon standard sur tous les projets sensibles -- défense, santé, fintech.
Docker et Kubernetes : la séparation des responsabilités
Docker construit les images, Kubernetes les exécute. Cette séparation est fondamentale et souvent mal comprise. Chez Metronome, les développeurs construisaient leurs images en local avec Docker, les testaient avec docker-compose pour valider les interactions entre services, puis les poussaient vers le registre. Le cluster Kubernetes OVH récupérait les images et les déployait via Helm. Le Dockerfile était la source de vérité pour le packaging de l'application (quoi empaqueter, comment configurer le runtime), et le Helm Chart pour son déploiement (combien de replicas, quelles ressources, quels health checks).
Cette séparation claire des responsabilités facilite le travail de chacun : les développeurs maîtrisent leur Dockerfile sans avoir besoin de comprendre Kubernetes, l'équipe ops maîtrise le Helm Chart sans avoir besoin de comprendre le build de l'application. Chez Bloomflow, avec plus de 30 microservices, cette séparation était vitale : chaque équipe était autonome sur son Dockerfile, et l'équipe platform (dont je faisais partie) gérait les Helm Charts et l'infrastructure Kubernetes.
Conclusion
Docker est la fondation de l'infrastructure moderne. Sans Docker, pas de Kubernetes, pas de CI/CD conteneurisé, pas de microservices fiables. Maîtriser Docker, c'est maîtriser les Dockerfiles optimisés (multi-stage, images légères), la sécurité des images (scan, signature, non-root), l'intégration CI/CD (build, tag, push automatisés) et la collaboration via les registres. En 10 ans de pratique quotidienne, Docker reste l'outil le plus transformateur de ma carrière d'ingénieur DevOps.