Près d’un an après sa première démonstration, Docker rend les conteneurs beaucoup plus accessibles. Une image décrit un système de fichiers et une commande; le moteur démarre un processus isolé avec espaces de noms, limites de ressources et réseau virtuel. Contrairement à une VM, le conteneur partage le noyau Linux de l’hôte.

L’image est composée de couches en lecture seule. Au démarrage, Docker ajoute une couche écrivable. Si le conteneur disparaît, cette couche disparaît avec lui à moins que la donnée vive dans un volume ou un service externe. Cette propriété encourage des instances remplaçables, mais elle surprend si on traite le conteneur comme une petite machine permanente.

Emballer une application Web

Un flux de livraison peut être :

1. partir d’une image de base identifiée par version;
2. copier les dépendances et le binaire;
3. définir utilisateur non privilégié et port;
4. construire une image immuable;
5. lancer les tests sur cette image;
6. publier son empreinte dans un registre;
7. déployer exactement cette empreinte.

La configuration spécifique à l’environnement arrive au démarrage, pas dans l’image. Le même artefact passe de test à production. Un tag latest peut changer sous nos pieds; une empreinte ou version immuable permet de savoir ce qui roule et de revenir.

Le registre devient un composant sensible. Il faut authentification, transport chiffré, rétention et analyse des dépendances. Une image de base compromise se propage à chaque application qui la reconstruit. Les correctifs demandent de rebâtir et redéployer, pas de modifier chaque conteneur à la main.

Le conteneur ne règle pas les dépendances

La base, les fichiers et les secrets restent à concevoir. Un volume local attache l’instance à un hôte; une base externe rend le déplacement plus facile mais ajoute réseau et timeout. Les secrets ne devraient ni entrer dans le Dockerfile ni rester dans l’historique d’une couche.

Le partage du noyau réduit l’isolation par rapport à une VM. Une faille du moteur ou du noyau peut traverser la frontière. Exécuter sans privilèges, limiter capacités, mémoire et CPU, protéger le socket Docker et séparer les charges sensibles réduisent le risque.

Une application peut recevoir SIGTERM avant d’être tuée. Elle doit cesser d’accepter du trafic, terminer ou remettre ses travaux et fermer ses connexions. Les probes de santé et les logs vers stdout facilitent l’exploitation, mais une probe qui teste seulement le processus ne prouve pas que la base répond.

Limiter l’image à ce qui doit vraiment rouler

Une image qui contient compilateur, utilitaires réseau et sources augmente sa taille et les outils disponibles à un attaquant. Je construirais dans une étape séparée, puis copierais seulement binaire et dépendances d’exécution dans l’image finale. Le fichier de construction fixe les versions et retire les caches. Le démarrage vérifie la configuration sans imprimer les secrets. Une analyse compare les paquets aux vulnérabilités, mais une exception documentée reste possible si aucun chemin exploitable n’existe. Cette réduction accélère les transferts, rend les différences plus faciles à lire et diminue le nombre de correctifs urgents qui n’ont aucun rapport avec la fonction du service.

Je commencerais par un service stateless, le construirais automatiquement et tuerais son conteneur au milieu d’une requête. Si une autre instance reprend sans perte et que la version est traçable, l’emballage apporte une vraie amélioration. Les conteneurs simplifient l’unité de livraison; ils rendent les choix de données, réseau et sécurité encore plus visibles.