Écrire des Dockerfiles légers et des points d’entrée Shell

Dans les environnements de production, chaque mégaoctet d’une image Docker a un coût : téléchargements plus lents, surface d’attaque plus grande et espace de stockage du registre gaspillé. Des fichiers Docker légers associés à des scripts shell robustes servant de points d’entrée sont la marque d’une pratique DevOps mature.

• Les compilations multi-étapes séparent les outils nécessaires à la compilation de l’image finale d’exécution, ce qui réduit considérablement sa taille.
• Les relais de point d’entrée sont de petits scripts shell qui initialisent les conteneurs : ils génèrent les fichiers de configuration à partir de modèles, valident les variables d’environnement, gèrent les signaux et exécutent finalement le processus principal.
• Ensemble, ils constituent la base de charges de travail conteneurisées fiables et portables dans Kubernetes, ECS et les environnements sur serveurs physiques.

Cette leçon couvre ces deux domaines de bout en bout, avec des modèles prêts pour la production que vous pouvez intégrer directement à vos pipelines.

Un fichier Docker multi-étapes utilise plusieurs instructions FROM. Chaque étape est un ensemble de couches isolé ; vous ne copiez dans l’étape suivante que les artefacts dont vous avez besoin.

• Étape 0 (builder) : installe les compilateurs, les lanceurs de tests et les dépendances de compilation.
• Étape 1 (runtime) : part d’une base minimale (par exemple alpine, distroless) et ne copie que les binaires compilés ou les ensembles de fichiers de l’application.
• L’image finale ne contient jamais gcc, make ni le code source, sauf si vous les copiez explicitement.

Utilisez --from=<stage> dans COPY pour récupérer des fichiers au-delà des limites entre les étapes. Nommez les étapes avec AS <name> pour améliorer la lisibilité et permettre de cibler sélectivement une étape avec docker build --target.

Chaque instruction RUN, COPY et ADD crée une nouvelle couche. Des instructions mal ordonnées invalident inutilement le cache de compilation, ce qui ralentit les pipelines d’intégration continue.

• Copiez les manifestes de dépendances (package.json, go.mod, requirements.txt) avant de copier le code source afin que l’installation des dépendances soit mise en cache indépendamment.
• Enchaînez les commandes associées avec && et effectuez le nettoyage dans la même couche RUN afin d’éviter de laisser le cache des paquets dans les couches intermédiaires.
• Utilisez --no-cache dans les gestionnaires de paquets et supprimez les fichiers de listes après l’installation.

Les registres privés, les clés SSH et les jetons d’API ne doivent jamais apparaître dans les couches d’une image. Docker BuildKit fournit deux mécanismes sûrs :

• --secret : monte un fichier secret dans une seule étape RUN sans l’intégrer à une couche. Accédez-y via /run/secrets/<id>.
• --ssh : transfère le socket de l’agent SSH de l’hôte dans la compilation afin que git clone puisse s’authentifier sans intégrer de clés privées.

Activez BuildKit avec DOCKER_BUILDKIT=1 ou via docker buildx build. La directive # syntax=docker/dockerfile:1 active ces fonctionnalités.

Le relais de point d’entrée est un script shell défini comme ENTRYPOINT dans le fichier Docker. Son rôle est de préparer l’environnement d’exécution avant de céder le contrôle au processus principal.

Un relais bien structuré respecte l’ordre suivant :

• Étape 1 : définissez set -euo pipefail afin que tout échec provoque un arrêt immédiat.
• Étape 2 : validez les variables d’environnement requises et arrêtez rapidement l’exécution avec un message explicite en cas de problème.
• Étape 3 : générez les fichiers de configuration à partir des variables d’environnement.
• Étape 4 : enregistrez des gestionnaires de signaux pour permettre un arrêt correct.
• Étape 5 : exec "$@" — remplacez le shell par le processus principal afin que le PID 1 soit l’application, et non le relais.

Le dernier exec est essentiel : sans lui, les signaux envoyés par Kubernetes ou le moteur d’exécution Docker ne sont pas transmis au processus enfant.

envsubst (issu du paquet GNU gettext, disponible dans Alpine sous la forme de gettext) remplace les marqueurs ${VAR} d’un fichier modèle par les valeurs actuelles de leurs variables d’environnement.

• Incluez dans l’image un modèle de configuration *.tmpl ; le point d’entrée le génère au démarrage.
• Transmettez explicitement la liste des variables à envsubst afin qu’il ne développe pas accidentellement des signes dollar sans rapport (par exemple dans une expression régulière NGINX).
• Écrivez le fichier généré dans un chemin accessible en écriture, comme /tmp, ou dans un volume de configuration dédié.

Les conteneurs reçoivent SIGTERM lorsqu’ils sont arrêtés par Kubernetes, ECS ou docker stop. Si votre relais de point d’entrée est le PID 1 et qu’il ne transmet pas les signaux, le processus principal est tué avec SIGKILL à la fin du délai de grâce, ce qui peut entraîner la perte de requêtes ou la corruption de données.

• Utilisez trap pour intercepter SIGTERM et SIGINT dans le relais.
• Transmettez le signal au PID enfant avec kill -TERM "$child".
• Utilisez wait "$child" pour bloquer jusqu’à la fin du processus enfant, puis retransmettez son code de sortie.
• Vous pouvez également utiliser exec pour remplacer entièrement le shell ; le système d’exploitation transmet alors directement les signaux au processus enfant, sans qu’un gestionnaire soit nécessaire. C’est le modèle recommandé dans les cas simples.

Lorsque votre conteneur crée des processus enfants (par exemple un shell qui lance des processus de travail), vous avez besoin d’un véritable processus d’initialisation pour récupérer les processus zombies. tini est un petit binaire d’initialisation conçu spécialement pour les conteneurs.

• Ajoutez tini à votre image et définissez-le comme relais du point d’entrée.
• Il récupère les processus enfants zombies, transmet correctement les signaux et se termine avec le code d’état du processus enfant.
• Docker fournit un tini intégré, activé avec docker run --init, mais l’intégrer à l’image garantit un comportement cohérent entre les moteurs d’exécution (Kubernetes, ECS, etc.).

Les conteneurs qui s’exécutent en tant que root (UID 0) représentent un risque de sécurité majeur : une évasion du conteneur donne un accès complet à l’hôte. Passez toujours à un utilisateur non privilégié avant d’exécuter le processus principal.

• Créez un utilisateur et un groupe système dédiés dans le fichier Docker avec addgroup / adduser (Alpine) ou groupadd / useradd (Debian).
• Modifiez le propriétaire des fichiers de l’application avec COPY --chown=appuser:appgroup — c’est plus efficace qu’une couche RUN chown distincte.
• Passez à cet utilisateur avec l’instruction USER. Le point d’entrée et CMD héritent de cet utilisateur.
• securityContext.runAsNonRoot: true de Kubernetes refuse de démarrer une image qui s’exécute encore en tant que root.

Les sondes de vivacité et de disponibilité de Kubernetes sont définies dans les manifestes, mais vous pouvez également intégrer un HEALTHCHECK au fichier Docker pour les environnements autonomes utilisant docker run et Docker Compose.

• HEALTHCHECK --interval=10s --timeout=3s --start-period=15s --retries=3 CMD ...
• Utilisez curl --fail ou wget -qO- pour les services HTTP ; pour les démons non HTTP, testez un socket avec /dev/tcp/localhost/PORT.
• Installez uniquement ce dont vous avez besoin : dans les images distroless, évitez d’ajouter curl uniquement pour les contrôles de santé ; utilisez plutôt un binaire de sonde dédié ou le binaire de contrôle de santé de l’application.

Voici un relais de point d’entrée complet, prêt pour la production, qui combine tous les modèles de cette leçon : validation de l’environnement, génération de la configuration à partir d’un modèle, transmission des signaux et transfert avec exec. Ce modèle est utilisé dans des microservices Node.js, Python et Go réels déployés sur Kubernetes.

• Chaque section est commentée pour servir de modèle explicite et auto-documenté.
• Le relais fait moins de 50 lignes — les points d’entrée doivent rester simples et faciles à auditer.
• Remarquez le exec "$@" final : une fois toute la préparation terminée, le shell est remplacé par le processus de l’application, qui devient ainsi le PID 1 et reçoit directement tous les signaux du système d’exploitation.

Vérifiez votre compréhension de la gestion des signaux dans les scripts servant de points d’entrée aux conteneurs.

Vous avez étudié tous les aspects de la création de conteneurs prêts pour la production :

• Les compilations multi-étapes utilisent plusieurs instructions FROM pour exclure les compilateurs et les outils de compilation de l’image finale, ce qui produit des couches d’exécution légères et minimales.
• L’ordre des couches — copier les manifestes de dépendances avant le code source — maximise les utilisations du cache et accélère les pipelines d’intégration continue.
• Les secrets et montages SSH de BuildKit gardent les identifiants hors de l’historique de l’image sans empêcher les compilations authentifiées.
• Les relais de point d’entrée valident les variables d’environnement, génèrent les fichiers de configuration avec envsubst et transfèrent le contrôle à l’application via exec "$@".
• La gestion des signaux nécessite soit exec (pour que l’application soit le PID 1), soit un modèle explicite trap + kill + wait lorsque des tâches en arrière-plan sont utilisées.
• tini assure la récupération des processus zombies et la transmission correcte des signaux lorsque le conteneur crée plusieurs processus.
• Les utilisateurs non root et les instructions HEALTHCHECK complètent une image sécurisée et observable, prête pour les charges de travail Kubernetes en production.

Appliquez ces modèles de façon cohérente : vos images seront plus petites, plus rapides à déployer et nettement plus robustes en conditions de production.