Le conteneur comme emballage standard. Pourquoi « ça marche sur ma machine » n'est plus un argument.
Catégorie · DevOps & Infra
Ce qu'est Docker.
Docker empaquette une application avec toutes ses dépendances — runtime, bibliothèques, configuration — dans une image autonome. Cette image s'exécute à l'identique sur n'importe quel hôte, qu'il s'agisse d'un ordinateur portable, d'un runner CI ou d'un serveur de production.
Contrairement à une machine virtuelle, un conteneur n'embarque pas son propre système d'exploitation : il partage le noyau de l'hôte. C'est ce qui le rend léger : des secondes au lieu de minutes pour démarrer, des mégaoctets au lieu de gigaoctets.
Pourquoi nous conteneurisons systématiquement.
Chaque produit que nous construisons et exploitons tourne dans un conteneur. L'environnement fait ainsi partie du code — la phrase « ça marche sur ma machine » n'est plus un argument, car l'environnement est partout le même.
Cela réduit l'effort d'intégration d'un nouveau développeur à un « docker compose up » et rend les déploiements reproductibles. C'est précisément ce dont nous avons besoin pour des chaînes d'exploitation traçables et auditables.
Où se situe la limite.
Docker résout l'empaquetage, pas l'orchestration. Dès que plusieurs conteneurs doivent monter en charge sur plusieurs machines, fonctionner sans interruption et être remplacés automatiquement, il faut une couche au-dessus — le plus souvent Kubernetes.
Pour un seul serveur avec quelques services, Docker Compose suffit. C'est la charge et l'exigence de disponibilité qui décident si l'on doit aller plus loin.
