Docker — livraison et exploitation des applications

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.

Comprendre le mécanisme

Chaque étape d’un Dockerfile participe à la construction d’une image et à son cache. Copier les fichiers de dépendances avant le code changeant peut éviter de recalculer une installation coûteuse. Un build multi-stage nomme plusieurs étapes puis copie uniquement les artefacts nécessaires vers le runtime. Un fichier supprimé dans une couche ultérieure peut rester récupérable dans une couche antérieure : supprimer un secret après COPY ne suffit pas.

Raisonner et vérifier

Réduisez le contexte avec .dockerignore et fournissez les secrets de build par un mécanisme temporaire adapté. Le processus de build ne doit pas recopier le secret dans un artefact ou un log. Une image petite n’est pas une preuve de sûreté ; vérifiez aussi provenance, dépendances, permissions et fonctionnement. N’exécutez pas une résolution libre de versions si vous recherchez un artefact reproductible.

Séparer construction et exécution

Un build multi-stage permet de placer l’outillage de construction dans une étape puis de copier les artefacts utiles vers une étape runtime. Cette copie ciblée peut réduire ce qui est distribué. Elle ne doit pas oublier les dépendances nécessaires à l’exécution. Décrivez le contenu attendu de chaque étape et testez l’image finale seule ; un succès dans l’étape de build ne prouve pas qu’elle contient le bon livrable runtime.

Réduire le contexte envoyé au build

Le contexte peut inclure des fichiers locaux inutiles ou sensibles avant même les instructions du Dockerfile. .dockerignore aide à en exclure des éléments selon son contrat. Vérifiez les chemins réellement envoyés et évitez de compter seulement sur une suppression ultérieure. Un répertoire de développement peut contenir logs, sauvegardes et credentials qui n’appartiennent pas au périmètre de distribution du code.

Une suppression tardive ne retire pas toute trace

Copier un secret dans une couche puis le supprimer dans une instruction ultérieure ne garantit pas qu’il a disparu de l’historique d’image. La vue finale n’est pas toute l’archive distribuée. La bonne question est de savoir où la capacité a été exposée et quelles copies existent. Si le secret a réellement fuité, changer le build futur doit accompagner une procédure de retrait et de rotation.

Utiliser un mécanisme de secret adapté au build

Les montages de secrets ou mécanismes SSH prévus pour la construction peuvent exposer temporairement une capacité à l’instruction qui en a besoin. ARG et ENV ne constituent pas un coffre universel. Configurez l’entrée du secret et son usage sans le recopier dans l’artefact ou les logs. Un outil de build peut toujours divulguer une valeur qu’un script imprime ; le mécanisme demande donc une utilisation cohérente.

Verrouiller les dépendances utiles

Des manifestes et versions verrouillées aident à reproduire les dépendances installées. Une résolution flottante peut changer l’image alors que le code applicatif paraît identique. Conservez les versions, l’outil de construction et la plateforme. Cette reproductibilité ne démontre pas l’absence de défauts : elle rend leur identification et la comparaison de deux builds plus précises.

Organiser les étapes pour le cache

L’ordre des instructions influence les possibilités de réutilisation du cache. Copier les manifestes de dépendances avant le code qui change souvent peut éviter de réinstaller tout lorsque ces manifestes restent identiques. Cette stratégie doit conserver le bon contrat : une entrée réellement nécessaire ne doit pas être cachée hors du calcul. Mesurez le gain et vérifiez que l’artefact contient effectivement la version attendue.

Conserver les besoins du runtime

Copier un binaire ou un répertoire ne prouve pas que toutes les bibliothèques, fichiers de configuration et ressources utiles sont présents. Les dépendances dynamiques et la plateforme comptent. Lancez la dernière étape sans les répertoires du poste ni les outils de build, puis exercez le parcours utile. Une image plus petite n’est une amélioration que si elle conserve les capacités prévues.

Construire n’est pas tester la santé

Le succès de docker build indique que les instructions ont abouti dans le contexte de construction. Il ne prouve pas que la base est joignable, que le serveur accepte les demandes ou que l’application expose la bonne release. Ajoutez une exécution contrôlée et un health check représentatif. Le diagnostic doit distinguer erreur de construction, configuration runtime et panne de dépendance.

Choisir la plateforme cible

Une image et ses artefacts doivent correspondre à l’architecture et aux capacités de l’environnement d’exécution. Un build réalisé sur une machine ne prouve pas une exécution native sur toutes les autres. Documentez la plateforme demandée et celle réellement servie, notamment avec les images multi-plateformes. Les tests hors de l’IDE doivent vérifier l’artefact destiné au déploiement, pas seulement un assemblage local différent.

Inspecter sans exposer les secrets

Le contenu final et les métadonnées d’image doivent pouvoir être revus avec des fixtures publiques de laboratoire. Cherchez fichiers inattendus, logs et traces de credentials selon le périmètre de votre outil. Une absence dans la vue courante ne prouve pas toute l’histoire des couches. Les preuves doivent montrer la propriété recherchée et ses limites sans publier elles-mêmes la capacité que la revue voulait protéger.

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

FROM composer:2 AS build
WORKDIR /app
COPY composer.json composer.lock ./
RUN composer install --no-dev --no-scripts
FROM php:8.4-cli
COPY --from=build /app/vendor /app/vendor

La dernière étape de l’exemple copie seulement le répertoire vendor issu de build. Elle ne reçoit pas automatiquement tout le système de fichiers de cette étape. L’extrait montre une séparation et une sélection d’artefact, mais ne suffit pas à démarrer un service HTTP complet : le code applicatif, ses ressources et sa commande doivent encore être définis selon le produit.

Construisez une image de laboratoire avec un fichier témoin présent uniquement dans l’étape de build. Vérifiez qu’il n’apparaît pas dans la dernière étape si aucune copie ne le sélectionne. Examinez ensuite les besoins runtime réels et lancez le livrable dans un environnement propre. Une copie ciblée est une technique de distribution, pas une garantie automatique de complétude ni de sécurité du contenu copié.

Secrets de build : une suppression ultérieure ne retire pas la couche

Une image est construite à partir de couches et de métadonnées. Copier un token dans une couche puis le supprimer dans une instruction ultérieure peut le laisser récupérable dans l’historique de construction ou les artefacts intermédiaires.

Utilisez un secret de build monté temporairement à l’étape qui en a besoin. Le montage évite son inscription automatique comme fichier de l’image, mais la commande exécutée pourrait toujours le recopier dans une sortie, un cache ou un log. Contrôlez donc le comportement du gestionnaire de dépendances et les fichiers conservés dans l’image finale.

Vérifiez également contexte de build et fichiers exclus : un secret ne doit pas être envoyé inutilement au builder. Testez avec une valeur factice identifiable et examinez image finale, couches et logs selon votre pipeline. Si une valeur réelle a déjà été publiée, corriger le Dockerfile traite les prochains builds ; la capacité exposée demande séparément retrait et rotation.

Points de vigilance : Base64 ne protège pas un secret récupérable dans une couche. Le montage fournit le secret à l’étape nécessaire sans l’inscrire automatiquement dans l’image ; l’étape ne doit pas le divulguer. ARG et une copie vers l’image ne constituent pas un mécanisme approprié pour les secrets. Le contrôle du registre limite l’accès, mais ne supprime pas les octets des couches.

Comprendre le mécanisme

Un tag est un nom de référence susceptible d’être déplacé ; un digest identifie un contenu de manifeste. Utiliser une référence par digest aide à retrouver l’artefact attendu, sans démontrer à lui seul qu’il est sans vulnérabilité. Une image multi-plateforme peut pointer vers des variantes : identifiez aussi la plateforme effectivement utilisée. La provenance et la politique de confiance font partie du choix d’image.

Raisonner et vérifier

Conservez le lien entre commit, tests, build et image poussée au registre. Un scan et une nomenclature de dépendances apportent des informations à une date donnée, pas une garantie éternelle. Une mise à jour doit être reconstruite, testée et promue de façon contrôlée. Le retour de version doit cibler un artefact connu, avec vérification de compatibilité des données.

Comprendre la mutabilité d’un nom

Un tag est une référence nommée qui peut être réaffectée selon la politique du registre. Deux lancements séparés d’un même nom ne prouvent donc pas un contenu identique. Conservez la résolution effective lors du déploiement et prévoyez la politique de mise à jour. Cette trace aide à distinguer changement de configuration et changement d’artefact lorsque le nom apparent du service reste inchangé.

Fixer un contenu ne le rend pas exempt de défauts

Un digest aide à identifier précisément le contenu choisi. Il ne corrige pas les vulnérabilités que ce contenu peut déjà posséder ou qui seront découvertes plus tard. La maintenance doit donc savoir quel artefact est exécuté puis décider de sa mise à jour. L’immuabilité d’une référence facilite cette décision ; elle ne remplace pas l’analyse des risques et la vérification du nouveau comportement.

Établir une provenance de confiance

Une empreinte correcte montre une relation avec des octets attendus, pas automatiquement la légitimité de leur producteur. Une image malveillante possède aussi une identité de contenu. Définissez les éditeurs et processus admis ainsi que les preuves pertinentes pour votre distribution. Le téléchargement depuis un emplacement connu ne doit pas devenir une confiance indéfinie dans toute future publication portant un nom ressemblant.

Limiter les credentials du registre

Lire une image, publier un nouveau contenu et supprimer des artefacts sont des capacités différentes. Distribuez aux consommateurs le périmètre nécessaire plutôt qu’un credential universel. Les outils de diagnostic et de build ne doivent pas recopier ces secrets dans leurs sorties. Une compromission doit pouvoir être reliée à ses opérations possibles et à une procédure de retrait adaptée.

Conserver ce qui permet la reprise

Une politique de rétention peut supprimer un ancien artefact nécessaire à un retour arrière. Définissez les versions qui doivent rester accessibles et leur durée utile, sans conserver aveuglément toutes les données indéfiniment. Le test de rollback doit récupérer et lancer la référence réellement conservée. L’existence d’un nom de version dans un document ne prouve pas la disponibilité de ses couches dans le registre.

Décrire l’image multi-plateforme exécutée

Une référence multi-plateforme peut conduire à des contenus adaptés à des architectures différentes. Pour une release traçable, notez la plateforme cible effectivement choisie en plus de la référence générale. Une panne spécifique à une architecture peut rester invisible sur le poste de build. Les preuves doivent donc relier la machine, le contenu résolu et le parcours exécuté.

Vérifier une signature avec une politique

La présence d’une signature ne suffit pas si le consommateur accepte n’importe quelle clé ou n’importe quel éditeur. La politique doit définir les autorités et usages admis, puis vérifier les éléments pertinents avant exécution. Le contenu signé peut encore comporter des défauts ; authenticité de distribution et sécurité de l’application restent des propriétés différentes. Documentez ce que votre contrôle de signature démontre exactement.

Un scan possède une date et un périmètre

Un scan compare un contenu à un référentiel et des règles à un moment donné. Un rapport vert ne garantit pas toute sécurité future ni l’absence de défauts inconnus. Conservez l’identité analysée, la version de l’outil et les limites du contrôle. Lorsqu’un nouveau risque apparaît, cette traçabilité permet de déterminer quelles releases sont concernées et quel contrôle complémentaire devient nécessaire.

Relier le commit à l’image déployée

Une chaîne de preuve utile relie source, tests, build et identité de l’image effectivement lancée. Un succès de test sur un commit ne couvre pas un autre contenu construit manuellement ensuite. Évitez les substitutions silencieuses entre étapes et vérifiez l’identité servie après la bascule. Le nom du projet ne suffit pas pour diagnostiquer quelle version a produit un incident.

Protéger le téléchargement et son destinataire

Le transport vers le registre doit vérifier le pair prévu selon le modèle TLS utilisé. Désactiver la vérification de certificat pour contourner une erreur retire une garantie importante. Corrigez la chaîne, le nom ou le magasin de confiance en conservant le contrôle. Cette vérification de canal complète la politique de provenance du contenu ; elle ne donne pas, seule, une assurance sur tout ce que l’image exécutera.

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

services:
  api:
    image: example/lab-api:latest

Le fichier Compose de l’atelier utilise le tag latest. Cette référence peut rester identique dans le texte tout en visant un autre contenu au registre. Le YAML ne constitue donc pas une preuve d’immutabilité de l’artefact. Il ne dit pas non plus que le contenu est sans vulnérabilité ou que toute mise à jour est interdite.

Pour le laboratoire, relevez la référence résolue puis comparez deux publications contrôlées sous un même tag. Définissez ensuite une référence et une trace adaptées à votre processus de release. Si plusieurs plateformes sont proposées, notez celle réellement exécutée. La conclusion doit permettre de retrouver ce qui a été testé et servi, sans confondre identité des octets et légitimité ou qualité de leur producteur.

Comprendre le mécanisme

Le réseau d’un conteneur est distinct du contexte réseau de l’application hôte. Dans un conteneur, localhost désigne normalement ce conteneur, pas un autre service. Sur un réseau utilisateur approprié, les services peuvent se joindre par leurs noms. Publier un port associe une écoute hôte à une écoute de conteneur ; EXPOSE documente une intention dans l’image mais ne crée pas à lui seul cette publication.

Raisonner et vérifier

Ne publiez une base sur l’hôte que si un besoin explicite le justifie et contrôlez l’interface d’écoute. Une communication interne entre services n’exige pas nécessairement une ouverture publique. Vérifiez les chemins réels : navigateur vers reverse proxy, proxy vers application, application vers base. Un test depuis l’hôte ne démontre pas toute la résolution DNS interne.

EXPOSE est une indication de l’image

EXPOSE documente un port attendu par le service ; cette instruction ne publie pas automatiquement ce port sur les interfaces de l’hôte. La publication demande une configuration de lancement distincte. Lors d’une revue, séparez ce que l’image décrit de ce que l’instance expose réellement. Une ligne présente dans le Dockerfile ne prouve donc ni accessibilité depuis Internet ni isolement complet du service.

L’adresse de binding fixe une portée

Publier un port avec une adresse hôte explicite choisit une portée d’écoute selon le contexte. Une liaison à 127.0.0.1 n’a pas le même périmètre qu’une écoute générale. Vérifiez les règles du moteur et de l’hôte réellement utilisés. Le test doit provenir d’un point de réseau pertinent : une connexion locale réussie ne prouve pas l’accès depuis l’extérieur, et l’inverse ne doit pas être supposé.

Localhost appartient au contexte courant

Dans le modèle réseau habituel du conteneur, localhost désigne son propre contexte de boucle locale. Il ne signifie pas automatiquement le conteneur voisin ni le serveur de base. Pour joindre une dépendance, utilisez le nom et le réseau prévus par le déploiement. Exécutez le diagnostic depuis le conteneur applicatif afin d’exercer sa résolution et sa connectivité, pas seulement celles du poste hôte.

Résoudre les services par leur contrat

Un réseau Compose peut fournir une résolution par nom de service. Ce nom permet d’éviter de traiter une adresse d’instance éphémère comme une identité fixe éternelle. La présence du nom ne prouve pas encore la disponibilité métier de la dépendance. Testez résolution, connexion et requête utile séparément pour localiser une panne sans attribuer à tout échec SQL une cause de mot de passe.

Vérifier la frontière effectivement exposée

Les ports publiés, interfaces et règles de pare-feu participent à l’accès réel. Une étiquette private dans un document ne bloque pas une publication ouverte. Inventoriez les services qui ont besoin d’une entrée externe et ceux qui peuvent rester sur un réseau interne. Le contrôle doit observer le chemin déployé ; un fichier de configuration seul ne démontre pas que toutes ses règles sont appliquées.

TLS se termine quelque part

Une terminaison TLS au proxy protège le canal jusqu’à cette frontière. Elle ne chiffre pas automatiquement la connexion interne vers l’application. Décrivez chaque saut et les hypothèses de confiance correspondantes. La configuration du proxy doit aussi maîtriser les champs de contexte transmis. Le schéma annoncé par un client non fiable ne doit pas décider librement de la sécurité perçue du parcours.

Communiquer sans publication hôte

Deux services connectés à un réseau prévu peuvent communiquer sans que chaque port soit publié vers l’hôte ou Internet. Une base réservée à l’application n’a donc pas nécessairement besoin d’une exposition externe. Cela ne supprime pas l’authentification et les permissions SQL. Limitez les voies d’accès utiles, puis testez le parcours réellement utilisé par le consommateur plutôt qu’ouvrir une interface supplémentaire uniquement pour faciliter un diagnostic.

L’absence de port public ne bloque pas les sorties

Une politique d’entrée et une politique de sortie répondent à des directions différentes. Un conteneur sans port publié peut encore appeler des services distants selon sa configuration. Pour un client HTTP piloté par des données reçues, limitez les destinations et les budgets. La confidentialité d’une dépendance interne ne doit pas être supposée à partir de la seule absence d’une publication de port sur l’application.

DNS et redirections peuvent changer la destination

Un nom initialement admis peut conduire à d’autres adresses, et une redirection peut choisir un autre hôte. Le client doit suivre un contrat de sortie maîtrisé sur tout le parcours. Évitez de considérer HTTPS comme une autorisation universelle de destination. Les tests doivent simuler un partenaire qui redirige hors du périmètre et vérifier que le service ne contacte pas librement une ressource interne.

Observer depuis les bons points

Un diagnostic réseau doit préciser d’où la demande est émise et quel saut il mesure. L’hôte, un conteneur applicatif et un navigateur distant peuvent avoir des résolutions et règles différentes. Conservez les versions, noms et erreurs expurgées. Cette chronologie évite les corrections aveugles, comme publier la base mondialement alors que le défaut concernait seulement le nom de service utilisé dans le conteneur.

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

services:
  api:
    image: example/lab-api:1
    ports:
      - "127.0.0.1:8080:80"

La publication montrée utilise 127.0.0.1 comme adresse hôte et 8080 comme port hôte, vers le port 80 du conteneur. Elle demande donc une portée locale dans ce contexte, pas une écoute générale du port 80 de l’hôte. Le registre d’image n’est pas l’interface de publication et ne décide pas de cette adresse.

Vérifiez le mapping dans un laboratoire depuis l’hôte puis depuis un autre point réseau prévu pour le test. Comparez avec une communication entre services qui utilise le réseau interne plutôt que le port publié. Documentez les résultats sans les extrapoler à toute topologie. Une configuration peut être correcte pour un proxy local et insuffisante ou trop large pour un autre mode de déploiement.

Comprendre le mécanisme

Un volume géré par Docker persiste indépendamment d’une instance donnée selon son cycle de vie. Un bind mount expose un chemin de l’hôte et lie davantage le conteneur à cet environnement. Monter un volume au-dessus d’un répertoire existant masque le contenu visible sous ce point de montage. La persistance n’est pas une sauvegarde : suppression, corruption ou erreur métier peuvent affecter les données durables.

Raisonner et vérifier

Pour une base active, copier des fichiers à un moment arbitraire n’est pas forcément une sauvegarde cohérente. Utilisez une procédure supportée par le moteur ou un instantané cohérent selon son contrat. Testez la restauration dans une instance et un volume séparés. Les options de lecture seule et permissions limitent certains accès, sans remplacer le choix du propriétaire des données et les droits du processus.

Le stockage possède son propre cycle de vie

Un volume peut survivre au remplacement d’un conteneur selon sa configuration et les opérations effectuées. Cette persistance permet de séparer les données de l’instance, mais ne promet pas une survie à toute suppression ou perte d’hôte. Définissez qui possède le volume, comment il est conservé et comment il est restauré. Un test doit remplacer réellement l’instance tout en vérifiant les données attendues.

Le bind mount dépend du chemin hôte

Un bind mount relie un emplacement de l’hôte à une vue dans le conteneur. Sa disponibilité et ses permissions dépendent donc aussi de cet hôte. Un chemin existant sur le poste peut manquer sur le serveur ou contenir un autre contenu. Documentez la source et la destination, puis testez l’environnement cible proprement au lieu de déduire la portabilité depuis une exécution locale confortable.

Persistance et sauvegarde sont deux capacités

Un volume conservé n’est pas automatiquement une copie indépendante et restaurable. Il peut subir une suppression logique, une corruption ou une perte avec son support. Une sauvegarde doit avoir un périmètre, une conservation et une procédure de restauration vérifiée. Les tests doivent observer cette reprise, pas seulement la présence d’un nom de volume dans un fichier de configuration.

Ce qui est visible sous un montage

Monter une ressource sur un répertoire déjà rempli peut masquer le contenu présent dans l’image sous ce point. Cela explique certains écarts entre inspection d’image et comportement d’instance. Comparez les deux vues avant de conclure que le build a oublié des fichiers. Le montage n’est pas une fusion universelle de tous les contenus ; ses options et son type doivent être compris selon le contrat utilisé.

Aligner les permissions avec l’utilisateur runtime

Le conteneur utilise un utilisateur et des droits qui doivent permettre les écritures réellement nécessaires, sans élargir tout le stockage. Un volume ne rend pas magiquement tous ses fichiers accessibles à tous les processus. Testez la création, la lecture et la reprise avec l’identité runtime déployée. Une correction qui accorde tous les droits sans limite peut cacher le défaut initial et agrandir le périmètre d’impact.

La lecture seule limite une direction

Un montage en lecture seule peut refuser des modifications par ce point d’accès. Il ne chiffre pas les données et ne décide pas si l’acteur métier peut les consulter. Le service peut aussi disposer d’autres chemins d’écriture selon sa configuration. Décrivez précisément la propriété visée et testez l’opération interdite, puis maintenez les contrôles d’autorisation et de confidentialité nécessaires à la distribution.

Sauvegarder une base dans un état cohérent

Copier arbitrairement les fichiers d’une base active peut produire une copie qui ne respecte pas les conditions de reprise du moteur. Utilisez une méthode de sauvegarde adaptée et conservez ses préconditions, journaux et versions nécessaires. La taille d’une archive ne prouve pas sa cohérence. Restaurez-la dans un laboratoire et vérifiez des invariants métier pour démontrer une capacité utile.

Partager ne sérialise pas les opérations

Plusieurs conteneurs peuvent accéder à des données communes selon le montage choisi. Cette accessibilité ne rend pas atomiques les écritures concurrentes du domaine. Deux travailleurs peuvent lire le même état puis produire des effets incompatibles. Définissez un protocole de coordination adapté au stockage et testez le scénario concurrent. Le mot shared n’est pas un verrou ni une règle de déduplication métier.

Prévoir les suppressions destructives

Certaines commandes de nettoyage peuvent supprimer des volumes et leurs données. La possibilité de recréer un conteneur depuis une image ne signifie pas que ce contenu métier est récupérable. Définissez les ressources éphémères et durables avant une opération, puis vérifiez ses cibles. Une procédure de reprise doit être connue et testée avant de considérer un nettoyage comme réversible.

Valider le résultat restauré

Une restauration techniquement terminée doit encore fournir le résultat utile : rôles, relations, fichiers et parcours applicatifs prévus. Mesurez le délai avec un volume représentatif et conservez les limites de l’exercice. Un succès sur trois fichiers ne justifie pas un objectif de reprise pour toutes les données. La preuve doit relier contenu retrouvé, environnement et contrôles métier observés.

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

services:
  db:
    image: postgres:18
    volumes:
      - lab-data:/var/lib/postgresql
volumes:
  lab-data: {}

La syntaxe de l’exercice nomme lab-data comme volume et le monte à la destination indiquée dans le conteneur. Elle ne désigne pas un chemin absolu du poste comme le ferait un bind mount. Cette configuration de persistance ne crée pas non plus une sauvegarde distante automatique ni une preuve que la base restaurera correctement toutes ses données.

Dans un laboratoire, écrivez une donnée témoin, remplacez le conteneur selon une procédure qui conserve le volume puis vérifiez la lecture. Étudiez séparément une suppression explicite du stockage et une restauration depuis une copie adaptée. Cette séparation rend visibles trois capacités différentes : recréer le processus, conserver son état et récupérer cet état après un incident qui détruit le support courant.

Comprendre le mécanisme

Compose décrit plusieurs services, leurs réseaux, volumes et configuration. Une dépendance ordonne le démarrage mais le simple état running ne prouve pas qu’une base accepte déjà des requêtes. Un healthcheck et une condition de dépendance adaptée peuvent aider au démarrage. L’application doit néanmoins gérer les indisponibilités ultérieures : le succès initial ne garantit pas la disponibilité permanente d’une dépendance.

Raisonner et vérifier

Les variables d’environnement et les fichiers dotenv de Compose participent à l’interpolation et à la configuration selon leurs règles propres. Ne confondez pas leur traitement avec celui de Symfony. Pour un secret, choisissez un montage ou gestionnaire adapté et évitez l’exposition dans les images et logs. Vérifiez le rendu de configuration sans diffuser de valeurs sensibles.

Une déclaration décrit des intentions

Compose organise des services et ressources selon un fichier et un environnement donnés. Un YAML syntaxiquement valide ne prouve pas la disponibilité réelle d’une API ou de sa base. Les images, variables, volumes et réseaux doivent aussi être corrects. Lisez la configuration effective puis lancez le parcours utile ; la présence des bons noms de sections n’est pas une observation du comportement déployé.

Démarrer n’est pas être prêt

Une dépendance peut être en exécution alors que son initialisation n’est pas terminée. Un ordre de démarrage simple ne garantit donc pas que la base accepte déjà la première requête métier. Définissez le critère de disponibilité et les conditions que l’application peut attendre. Un délai fixe choisi au hasard peut masquer le problème sur une machine rapide sans le résoudre sur une autre.

Observer une santé pertinente

Un health check doit correspondre à une propriété clairement définie. Vérifier seulement qu’un processus existe ne démontre pas l’accès aux données nécessaires au parcours. À l’inverse, un contrôle trop lourd ou mutateur peut perturber le service. Choisissez une observation bornée et interprétable, avec un diagnostic minimisé. Le succès doit rester limité aux dépendances et conditions réellement exercées.

Comprendre la condition de démarrage

Une condition comme service_healthy peut organiser le démarrage d’un service consommateur selon la santé déclarée de sa dépendance. Cette coordination ne garantit pas sa disponibilité éternelle. Vérifiez la définition du health check et le comportement du mode de déploiement ciblé. Une configuration porte des règles ; les tests doivent montrer ce qu’elles font lors d’un démarrage lent et d’un refus persistant.

Les pannes peuvent arriver après le démarrage

Une dépendance initialement saine peut tomber en panne pendant le service. L’application doit donc conserver des délais, erreurs et reprises adaptées indépendamment de l’ordre initial. Tester uniquement docker compose up ne couvre pas cette phase. Simulez une indisponibilité après un parcours réussi et vérifiez le refus borné, la récupération et l’absence de répétition incontrôlée d’un effet métier sensible.

Deux usages différents des fichiers dotenv

L’interpolation de variables par Compose et la lecture de configuration par Symfony ne sont pas nécessairement le même mécanisme ni le même moment. Une valeur disponible pour construire le YAML ne se retrouve pas automatiquement dans tout processus. Définissez la chaîne d’injection attendue et contrôlez les variables effectives sans publier les secrets. Un nom de fichier identique ne rend pas deux contrats de configuration interchangeables.

Un nom de service n’exige pas un port public

Sur le réseau prévu, les services peuvent utiliser leur résolution interne pour communiquer. La dépendance db n’a pas toujours besoin d’une publication vers Internet. Cette possibilité de connexion ne remplace ni authentification ni disponibilité SQL. Testez depuis le consommateur réel afin de distinguer erreur de nom, refus réseau et erreur de credentials sans élargir inutilement la surface exposée.

La politique de redémarrage a des limites

Relancer un processus peut aider après certains échecs, mais ne répare pas une donnée invalide ou une mauvaise configuration permanente. Une boucle de redémarrages peut consommer des ressources et masquer la cause. Définissez les conditions et l’observation de reprise. Un test doit inclure un défaut persistant et montrer que l’exploitation peut le diagnostiquer, au lieu d’interpréter toute nouvelle tentative comme un progrès.

Vérifier les ressources dans le runtime choisi

Les options de limite doivent être effectivement prises en compte par le moteur et le mode de déploiement utilisés. Leur présence dans un exemple ne prouve pas la même application partout. Mesurez consommation, refus et comportement sous pression dans l’environnement cible. Un budget mémoire borne certaines conséquences mais ne corrige pas la fuite qui les provoque ; il peut conduire à un arrêt qu’il faut aussi gérer.

Construire des scénarios dégradés

Un démarrage nominal ne couvre pas dépendance silencieuse, réponse lente et erreur durable. Utilisez des services simulés ou un laboratoire pour provoquer ces états sans toucher les données réelles. Pour chaque scénario, écrivez durée maximale et effet interdit. Cette matrice permet de vérifier la résilience comme un contrat observable, plutôt que l’attribuer au seul fait d’utiliser un orchestrateur ou une politique de restart.

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

services:
  api:
    image: example/lab-api:1
    depends_on:
      - db
  db:
    image: postgres:18

L’extrait déclare une dépendance de démarrage entre api et db. Il ne présente ni condition de santé ni preuve que PostgreSQL accepte une requête lorsque l’application effectue son premier appel. Il faut donc distinguer la relation déclarée, bien présente, de la disponibilité métier qui reste à définir et observer.

Dans un laboratoire, ralentissez l’initialisation de la base et relevez le comportement de l’API. Ajoutez une coordination adaptée si elle répond au besoin, puis provoquez une panne après un démarrage réussi. L’application doit encore respecter ses budgets et sa politique de reprise. Le test montre ainsi ce que l’organisation initiale apporte, et quelles responsabilités restent dans le consommateur pendant la durée du service.

Comprendre le mécanisme

L’isolation repose notamment sur namespaces, cgroups et politiques de sécurité. Un utilisateur non root, des capacités minimales et des montages limités réduisent le périmètre accessible. L’accès au socket Docker peut permettre un contrôle très étendu de l’hôte selon la configuration ; ne le donnez pas à une application ordinaire par commodité. Le mode privilégié doit être justifié par un besoin précis, pas utilisé comme remède général aux erreurs de permission.

Raisonner et vérifier

Une racine en lecture seule exige de prévoir explicitement les répertoires temporaires ou données nécessaires. Les limites mémoire et CPU bornent certaines consommations, sans corriger une fuite mémoire ou un algorithme incorrect. Un conteneur n’est pas une preuve d’isolation absolue : maintenez aussi noyau, runtime et dépendances. Testez les droits nécessaires et les refus attendus sous le véritable utilisateur runtime.

Réduire les privilèges du processus

Exécuter le service avec un utilisateur non root peut limiter certaines opérations si le reste de la configuration respecte cette intention. Cela n’empêche pas toutes les vulnérabilités applicatives : le processus peut encore accéder aux données légitimement disponibles pour son rôle. Définissez les capacités nécessaires puis testez une opération refusée et un parcours nominal. Le durcissement doit réduire l’impact sans être confondu avec une preuve générale d’absence de bug.

Ne garder que les capacités utiles

Les capabilities et autres options de privilège doivent correspondre à un besoin réel du service. En ajouter toutes élargit les pouvoirs disponibles, même si une fonction nominale semble continuer à marcher. Inventoriez les opérations système attendues et retirez les capacités superflues selon une procédure vérifiée. Une configuration minimale doit être testée, pas simplement copiée d’un autre produit dont les dépendances diffèrent.

Définir les écritures nécessaires

Une racine de conteneur en lecture seule peut limiter des modifications inattendues, mais le programme a parfois besoin d’espaces temporaires ou de données explicitement montées. Identifiez-les et contrôlez leur durée et taille. Cette restriction ne chiffre pas les fichiers et ne filtre pas toutes les sorties réseau. Les tests doivent distinguer écriture interdite, écriture utile et chemin de reprise après une erreur de stockage.

Le socket donne une capacité, pas un fichier anodin

Monter le socket Docker peut exposer des opérations puissantes sur le démon et l’environnement hôte selon les droits et la configuration. Ce n’est pas une lecture ordinaire comparable à une image publique. Évitez ce montage pour une application qui n’a pas besoin de ce contrôle. Une revue doit considérer l’impact d’une RCE dans le service qui pourrait alors utiliser l’interface exposée.

Distribuer les secrets selon leur usage

Un processus qui consomme un secret doit pouvoir l’obtenir d’une manière utile ; son injection ne le rend donc pas inaccessible à tout code exécuté dans ce périmètre. Limitez les détenteurs, les logs et la conservation. Séparez environnements et finalités pour réduire l’impact d’un incident. Une valeur publique de démonstration ne doit pas devenir le credential réel parce que le format d’injection paraît sécurisé.

Borner sans prétendre réparer

Des limites de CPU et de mémoire participent au partage de ressources et peuvent borner certaines conséquences d’un abus ou d’une fuite. Elles ne corrigent pas automatiquement la cause. Une limite mémoire peut conduire à un arrêt, qui demande une stratégie de diagnostic et de reprise. Mesurez aussi files, volume de travail et délais ; déplacer l’attente vers une autre ressource ne fournit pas une capacité infinie.

Comprendre le mode privilégié

Le mode privilégié élargit des possibilités au lieu de représenter une restriction maximale. Son utilisation doit donc être liée à un besoin explicite et à une analyse du périmètre. Un exemple qui fonctionne uniquement avec ce mode peut cacher un défaut de permissions ou une dépendance excessive. Cherchez la capacité minimale nécessaire et testez-la séparément, plutôt que rendre tout l’environnement accessible par facilité.

Maintenir le contenu exécuté

Une image identifiée par digest peut rester vulnérable ou devenir concernée par une information de sécurité nouvelle. La traçabilité facilite le repérage des instances affectées ; elle ne retire pas le besoin de maintenance. Définissez construction, analyse et mise à jour avec des vérifications de comportement. Le nom d’une base réputée ou le résultat ancien d’un scan ne garantit pas tout état futur.

Garder l’autorisation dans le domaine

Un runtime durci limite des capacités système, pas les droits d’un utilisateur sur une facture. Une requête paramétrée et un compte non root peuvent encore renvoyer les données du mauvais tenant si le filtre métier est absent. Testez cette frontière directement avec deux acteurs. La défense doit combiner des propriétés complémentaires, sans attribuer à un mécanisme d’isolation la connaissance de toutes les règles du produit.

Observer la restriction effective

Le fichier de déploiement peut être surchargé ou interprété dans un contexte différent de celui du poste. Vérifiez l’utilisateur, les montages, capacités et limites de l’instance réellement exécutée. Une intention dans un commentaire ne prouve rien de ces décisions. La preuve doit conserver la version et les observations utiles sans exposer les secrets, afin qu’un autre opérateur puisse comprendre ce qui a été testé.

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

services:
  api:
    image: example/lab-api:1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Le volume de l’atelier ne monte pas seulement des données métier : il expose le socket de l’environnement Docker. Un processus compromis pourrait disposer de capacités de contrôle importantes par cette interface selon sa configuration. Aucun port 443 ni mécanisme de chiffrement du volume n’est défini dans cet extrait ; ces réponses décriraient d’autres propriétés.

Réalisez la revue sur une configuration de laboratoire et demandez si le service a réellement besoin d’opérer le démon. Retirez le montage lorsqu’il ne correspond pas à sa responsabilité, puis vérifiez le parcours nominal. Complétez avec utilisateur, capacités et ressources minimales. Le but est de limiter l’impact d’un code hostile tout en conservant les contrôles métier qui empêchent un utilisateur ordinaire d’accéder aux données d’un autre.

Après une RCE : réduire les capacités du processus

Une défense en profondeur suppose que la prévention puisse échouer. Un processus compromis dispose au minimum des droits de l’application ; l’objectif est de limiter les capacités supplémentaires accessibles depuis ce point.

Exécutez sans root, retirez les capacités inutiles, évitez mode privilégié et socket Docker, et rendez le système de fichiers en lecture seule lorsque possible. Fournissez seulement les répertoires temporaires nécessaires avec budgets de taille et durée. Limitez aussi sorties réseau et accès aux secrets selon les besoins réels du service.

Ces mesures ne rendent pas le conteneur invulnérable et ne retirent pas les données que l’application doit légitimement lire. Vérifiez le fonctionnement nominal sous ces restrictions puis simulez des opérations de laboratoire qui doivent échouer, comme une écriture hors répertoire admis. Une configuration déclarative doit être confrontée aux permissions et montages réellement présents sur le runtime déployé.

Points de vigilance : La réduction des droits et des accès hôte diminue les possibilités après RCE ; ce n’est pas une isolation absolue. Une image petite ne neutralise pas les privilèges du processus. L’accès au socket peut permettre de contrôler le démon et compromettre l’hôte selon sa configuration. Le mode privilégié et les montages sensibles compromettent le confinement attendu.

Comprendre le mécanisme

Une application conteneurisée doit exposer des journaux utiles et un comportement d’arrêt défini. La commande principale et la forme de lancement influencent la propagation des signaux. À l’arrêt, terminez ou annulez proprement le travail en cours dans un délai borné. Un redémarrage automatique peut aider à la disponibilité, sans résoudre une erreur de configuration ou une corruption répétée.

Raisonner et vérifier

La vérification de santé doit tester un contrat significatif sans divulguer de secret. Corrélez image exécutée, révision et événements métier minimisés. Pour revenir à une version précédente, utilisez un artefact identifié et vérifiez sa compatibilité avec les données et migrations. Une procédure n’est fiable qu’après exercice dans un environnement contrôlé ; documentez aussi le délai de retour et les limites.

Une identité de release retrouvable

Une release doit relier source, tests et contenu exécuté. Un tag mutable seul ne permet pas de retrouver exactement ce qui a été servi à une date donnée. Conservez les références pertinentes et vérifiez l’identité active après bascule. Cette preuve aide à distinguer un défaut du nouveau code d’un processus resté sur l’ancien artefact ou d’une configuration différente.

Les logs sont un stockage à contrôler

Collecter stdout ne rend pas chaque donnée appropriée à une conservation ou un partage. Les traces peuvent contenir tokens, corps personnels et chemins sensibles. Définissez champs, accès et durée selon le besoin d’exploitation. Un incident doit être corrélable par des éléments minimisés. Les diagnostics d’échec demandent une attention particulière car ils traversent parfois des chemins moins contrôlés que les réponses nominales.

Arrêt gracieux et travail en cours

Un arrêt propre possède un délai et un contrat sur les tâches commencées. Transmettre un signal ne garantit pas l’annulation d’une mutation distante déjà validée. Le service doit savoir ce qu’il termine, reporte ou réconcilie. Testez l’arrêt pendant une opération de laboratoire et observez effets, files et redémarrage. Un processus arrêté rapidement n’est pas forcément un état métier correctement repris.

Le retour d’image ne rembobine pas les volumes

Revenir à une ancienne image modifie le code exécuté, pas automatiquement les écritures persistantes. Les volumes et bases peuvent conserver un format nouveau ou un effet déjà appliqué. Une procédure de rollback doit donc analyser la compatibilité avec l’état courant et les mécanismes de reprise. L’existence d’un ancien artefact ne démontre pas que sa réexécution est sûre sur toutes les données récentes.

Prouver la sauvegarde par une restauration

Une archive doit être restaurée dans un environnement distinct avec les outils et préconditions nécessaires. Vérifiez un parcours fonctionnel et les invariants utiles après récupération. Mesurez le délai sur un volume représentatif et conservez les limites. Un redémarrage automatique ou une réplication active ne protège pas nécessairement contre une suppression logique qui a déjà été propagée.

Tester le bon endpoint de santé

Un résultat 200 sur une page statique ne prouve pas que l’application, sa base et la release attendue fonctionnent ensemble. Le contrôle doit porter sur une garantie précise et bornée. Conservez l’identité de version avec la réponse utile, sans publier de secrets. Le succès décrit ce parcours observé ; il ne remplace pas une suite d’autorisation ni une restauration de secours.

Renouveler les processus avec le contenu

Modifier un tag dans un registre ne transforme pas automatiquement les conteneurs déjà actifs. La procédure doit récupérer la bonne référence et remplacer ou renouveler les instances selon le modèle choisi. Vérifiez ensuite le contenu réellement servi. Une simple copie de fichiers ou modification de configuration ne prouve pas que chaque processus a chargé l’état prévu.

Coordonner la migration de données

Une migration peut rendre une ancienne version incompatible avec le schéma courant. Définissez les phases compatibles et les critères qui autorisent le retrait de l’ancien contrat. Avant rollback, examinez cette situation avec les nouvelles écritures déjà effectuées. Un exercice doit simuler la panne à un point intermédiaire, car une démonstration sur une base vide ne couvre pas les données de production.

Surveiller la capacité et les boucles de reprise

Un état running n’assure pas une capacité suffisante ni une configuration correcte. Le processus peut être saturé ou répéter le même échec après chaque redémarrage. Reliez ressources, files, délais et résultats métier dans le diagnostic. La reprise automatique doit être bornée et observable ; elle ne constitue pas une correction d’un défaut permanent de configuration ou de donnée.

Conserver un dossier d’incident utile

Les preuves d’exercice doivent préciser actif, version, chronologie, observations et limites sans publier les credentials réels. Chaque action doit avoir une raison et un résultat vérifiable. Notez les risques résiduels et les étapes qui n’ont pas été testées. Ce dossier permet d’améliorer la procédure après l’incident, au lieu de conclure que tout est restaurable parce qu’une seule commande a terminé sans erreur.

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

# Plan proposé :
# 1. Déployer lab-api:2 et migrer la base.
# 2. En cas d’erreur, relancer lab-api:1.
# Aucune procédure de données n’est définie.

Le plan de l’atelier revient au code précédent après une migration annoncée comme incompatible. Cette seule action ne restaure ni schéma ni données. L’ancien binaire peut donc démarrer puis échouer ou mal interpréter l’état courant. Le défaut n’est pas le nom du tag ou celui du conteneur, mais l’absence d’une stratégie de compatibilité et de reprise de la couche persistante.

Préparez un jeu de données de laboratoire puis exercez les deux versions autour d’une migration contrôlée. Notez le point où le retour direct cesse d’être valable et quelles opérations supplémentaires sont nécessaires. Une stratégie progressive peut limiter cette fenêtre, mais elle doit être démontrée. Le contrôle de santé final doit confirmer une réponse applicative attendue liée à la version réellement active.