Docker a profondément changé la façon de développer et de déployer des applications. La containerisation est aujourd’hui un standard,difficile d’imaginer une infrastructure moderne qui n’en fait pas usage.
Mais Docker est un de ces outils qu’on peut commencer à utiliser en quelques heures, et passer des années à vraiment maîtriser, même en agence DevOps. La distance entre « j’ai un Dockerfile qui marche » et « j’opère des containers en production de façon fiable et sécurisée » est considérable.
Voici ce que cette distance recouvre.
Ce que Docker fait vraiment
Docker permet de packager une application et toutes ses dépendances dans une unité portable et isolée : le container.
L’avantage principal : ce qui tourne sur le poste d’un développeur tourne de la même façon en production. Les problèmes de « ça marche chez moi » disparaissent,ou du moins, se déplacent à un niveau qu’on peut mieux contrôler.
Un container Docker s’appuie sur une image, qui est construite à partir d’un Dockerfile. Cette image est versionnée, stockée dans un registry, et peut être déployée sur n’importe quelle machine qui fait tourner Docker.
Lire aussi : DevOps Engineer : ce que fait vraiment ce profil (et pourquoi c’est souvent mal compris)
DevOps et Kubernetes : ce que ça change dans la gestion d’une infrastructure
Migration cloud : le rôle du DevOps et les pièges à éviter
La différence entre développement et production
En développement, Docker est un outil de confort. Il standardise les environnements, facilite l’onboarding et permet de faire tourner plusieurs services en parallèle sur une même machine avec Docker Compose.
En production, les exigences sont différentes. Un container qui tombe doit redémarrer automatiquement. Le trafic doit être distribué entre plusieurs instances. Les logs doivent être collectés et centralisés. Les secrets ne doivent pas être exposés dans les images. Les ressources doivent être limitées pour qu’un service défaillant ne consomme pas tout ce qu’il y a sur la machine.
Ces exigences de production ne sont pas gérées par Docker seul. Elles demandent une réflexion sur l’orchestration (Kubernetes ou équivalent), la supervision, la sécurité et les pratiques de build.
Écrire un bon Dockerfile : plus subtil qu’il n’y paraît
Un Dockerfile, c’est la recette de construction d’une image Docker. La syntaxe est simple. Mais écrire un Dockerfile qui produit une image propre, légère, sécurisée et maintenable demande de connaître quelques principes.
La taille de l’image. Les images lourdes ralentissent les déploiements et consomment de l’espace dans le registry. L’utilisation d’images de base légères (Alpine, distroless), la réduction du nombre de couches et le nettoyage des fichiers temporaires sont des pratiques de base.
Le multi-stage build. Le build en plusieurs étapes permet de séparer l’étape de compilation de l’étape d’exécution. Résultat : l’image finale ne contient pas les outils de build, seulement ce qui est nécessaire pour faire tourner l’application. Les images sont plus légères et la surface d’attaque est réduite.
L’ordre des instructions. Docker met en cache chaque couche d’une image. Un Dockerfile bien ordonné,avec les instructions qui changent rarement en premier, celles qui changent souvent en dernier,permet de tirer parti du cache et d’accélérer les builds.
Les non-root users. Par défaut, les processus dans un container tournent en tant que root. C’est un risque de sécurité. La bonne pratique est de créer un utilisateur dédié dans le Dockerfile et de l’utiliser pour exécuter l’application.
La gestion des secrets : le sujet qu’on bâcle souvent
Les secrets,mots de passe, tokens, clés API,ne doivent jamais se retrouver dans une image Docker. Ni dans le Dockerfile, ni dans les variables d’environnement inscrites en dur, ni dans les fichiers de configuration versionnés.
En pratique, on voit encore régulièrement des secrets encodés en dur dans des images qui finissent dans un registry, parfois public par erreur de configuration.
Les approches correctes dépendent du contexte d’orchestration, mais passent généralement par :
- Les secrets managers des providers cloud (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault)
- Kubernetes Secrets avec des contrôles d’accès RBAC appropriés
- Des outils comme Vault pour les environnements plus complexes
La règle de base : une image Docker doit pouvoir être publiée sur un registry public sans exposer aucune information sensible.
La supervision des containers en production
Un container qui tourne en production doit être surveillé. Plusieurs dimensions sont à couvrir.
La santé des containers. Kubernetes et les orchestrateurs similaires s’appuient sur des probes pour déterminer si un container est vivant (liveness probe) et s’il est prêt à recevoir du trafic (readiness probe). Ces probes mal configurées sont une source fréquente d’incidents,des redémarrages intempestifs ou du trafic envoyé vers des instances qui ne sont pas prêtes.
Les métriques de ressources. CPU, mémoire, réseau,la supervision des ressources consommées par chaque container permet de détecter les fuites mémoire, les saturations et les anomalies de comportement.
Les logs. Dans un environnement containerisé, les logs ne peuvent pas rester sur le système de fichiers du container,celui-ci est éphémère. Ils doivent être collectés et centralisés. Le choix de la stack (ELK, Loki, Datadog…) dépend des contraintes de volume, de coût et de complexité opérationnelle.
La sécurité des images Docker
Les images Docker sont des artefacts logiciels comme les autres. Elles peuvent contenir des vulnérabilités.
Le scan des images. Des outils comme Trivy, Snyk ou les fonctionnalités natives des registries (ECR, GCR…) permettent de scanner les images à la recherche de CVE connues. Ce scan doit être intégré au pipeline CI/CD,pas fait manuellement de temps en temps.
La mise à jour des images de base. Si votre image de base contient des vulnérabilités, votre application les hérite. Les images de base doivent être mises à jour régulièrement, et ce processus doit être automatisé.
Le contrôle des images utilisées. Dans un environnement Kubernetes, il est possible (et recommandé) de n’autoriser que des images provenant de registries de confiance. Des outils comme OPA/Gatekeeper ou Kyverno permettent d’enforcer ces politiques.
Docker Compose en production : une fausse bonne idée
Docker Compose est excellent pour le développement local et les environnements de test. L’utiliser en production est tentant,la configuration est simple, tout le monde la comprend.
Mais Docker Compose ne gère pas la haute disponibilité, le scaling automatique, la récupération en cas de défaillance d’une machine, ni une gestion fine des ressources. Pour un usage en production sérieux, Kubernetes (ou un équivalent comme Nomad ou ECS) est la réponse adaptée.
Ça ne signifie pas que Compose n’a jamais sa place en production,pour des cas très simples sur une seule machine, ça peut suffire. Mais il faut en avoir conscience et accepter les limites.
Ce que propose Calopsys
Nos ingénieurs interviennent sur la mise en place de pipelines de build Docker, l’optimisation des images, la sécurisation des environnements containerisés et l’exploitation en production,dans des contextes Kubernetes sur AWS, GCP et Azure.
Docker a simplifié le packaging et le déploiement des applications. Mais « simplifier » ne signifie pas « sans complexité ». L’opérer correctement en production demande une expertise réelle sur des sujets,sécurité, supervision, gestion des ressources,qui vont bien au-delà du Dockerfile.