Processus, images et cycle de vie

Comprendre le mécanisme

Une image est un modèle de système de fichiers et de configuration ; un conteneur est une instance avec un processus et une couche d’écriture. Arrêter une instance n’équivaut pas à supprimer son image. Les conteneurs utilisent les mécanismes du noyau hôte pour isoler des processus et ne sont pas des machines virtuelles complètes par nature. Le comportement exact de l’hôte varie notamment selon la plateforme d’exécution.

Raisonner et vérifier

Le processus principal détermine la vie du conteneur : lorsqu’il termine, l’instance s’arrête. Un processus en arrière-plan lancé par un shell peut donc disparaître avec son parent ou laisser une instance terminée. Préférez une commande principale au premier plan et comprenez la réception des signaux. Les données importantes ne doivent pas dépendre uniquement de la couche jetable de l’instance.

Modèle distribué et instance exécutée

Une image décrit un contenu et des paramètres utiles au lancement ; un conteneur exécute une instance selon une configuration. Deux conteneurs fondés sur la même image peuvent avoir des montages, variables et états différents. Pour diagnostiquer, notez donc l’identité de l’image et la configuration effective de l’instance. Le nom du projet ne suffit pas à décrire le processus réellement servi.

Une isolation qui dépend de l’environnement

Un conteneur ne doit pas être assimilé systématiquement à une machine virtuelle disposant de son propre noyau complet. Les mécanismes d’isolation et l’environnement d’exécution définissent les frontières réelles. Cette distinction compte pour les droits et l’impact d’un code compromis. Dessinez les accès à l’hôte, aux volumes et au réseau ; le seul mot conteneur ne décrit pas toutes les capacités disponibles.

La couche écrivable n’est pas l’archive source

Les modifications de fichiers d’une instance ne republient pas automatiquement une nouvelle image dans le registre. La couche écrivable possède un cycle distinct et peut être jetable lors du remplacement du conteneur. N’y conservez pas l’unique copie de données métier durables. Définissez stockage, sauvegarde et restauration selon le besoin, puis testez le remplacement complet de l’instance avec ces données.

Le processus principal porte le cycle de vie

Lorsque le processus principal termine normalement selon ce modèle, le conteneur s’arrête. Un service lancé en arrière-plan peut donc laisser son wrapper terminer alors que l’intention était de maintenir le service disponible. Gardez le processus principal au premier plan selon son contrat. Les tests doivent observer démarrage, fin nominale et échec, sans conclure qu’une image construite reste automatiquement en exécution.

Le tag est une référence qui peut bouger

Un tag comme latest est un nom dont le contenu cible peut évoluer selon le registre. L’utiliser ne prouve pas que deux déploiements successifs exécutent le même artefact. Pour une analyse d’incident, conservez l’identité du contenu réellement résolu. Une politique de mise à jour doit être explicite : la commodité d’un nom stable ne remplace pas une trace de version.

Le digest identifie, sans certifier la qualité

Un digest relie une référence à un contenu selon le format concerné. Il aide à vérifier l’identité de l’artefact, mais ne prouve pas l’absence de vulnérabilité ni la légitimité de l’éditeur. Ces propriétés demandent d’autres contrôles et une politique de confiance. Pour une image multi-plateforme, notez aussi la plateforme effectivement choisie afin de décrire l’instance réelle.

Transmettre les signaux au bon acteur

La forme de lancement et les wrappers influencent la réception des signaux d’arrêt. Un shell ajouté sans gestion adaptée peut rendre le cycle moins direct que la forme exec prévue pour le processus principal. Définissez l’arrêt gracieux et son délai, puis observez le comportement réel. Un arrêt forcé qui semble rapide ne prouve pas que les travaux en cours ont été terminés ou repris correctement.

Une variable d’environnement reste une donnée sensible

Injecter un secret par environnement ne le rend pas impossible à observer. Le processus qui le consomme et certains outils de diagnostic peuvent y avoir accès selon les droits. Limitez distribution, journalisation et conservation. Les exemples de laboratoire doivent utiliser des valeurs publiques fictives. Retirer une variable d’une nouvelle release ne révoque pas une capacité déjà exposée dans une ancienne copie.

Ajouter les restrictions nécessaires

L’isolation disponible doit être complétée par des choix de runtime : utilisateur, capacités, montages, accès au socket et ressources selon le besoin. Un processus non privilégié peut encore présenter des vulnérabilités métier. La défense doit donc limiter les conséquences tout en maintenant les contrôles applicatifs. Vérifiez les restrictions effectives plutôt que leur seule présence dans un commentaire de configuration.

Tester le conteneur réellement livré

Une construction réussie ne démontre pas le démarrage ni le comportement du service. Lancez l’artefact avec une configuration représentative et vérifiez le parcours utile, les erreurs et l’arrêt. Conservez image, paramètres et résultat dans la preuve. Tester depuis le poste avec des fichiers non embarqués peut masquer une dépendance manquante ; un environnement propre rend ces hypothèses visibles.

Atelier guidé : lire, expliquer et vérifier le code

FROM php:8.4-cli
COPY worker.php /app/worker.php
CMD ["php", "/app/worker.php"]

Le CMD de l’atelier est écrit en forme JSON dite exec. Il décrit le lancement du processus PHP avec son script, sans demander ici une forme shell qui interpréterait la commande comme une ligne de shell. L’extrait ne publie aucun port et ne déclare aucun volume ; ces propriétés demanderaient leur propre configuration.

Dans le laboratoire, lancez un script qui attend puis traite un arrêt contrôlé. Comparez la forme de lancement et la transmission des signaux en observant les événements du processus. Remplacez ensuite entièrement le conteneur et examinez les fichiers persistants attendus. Ces expériences séparent contenu d’image, cycle de processus et stockage, au lieu de considérer qu’un seul Dockerfile démontre le fonctionnement complet du service.