## Introduction

Les conteneurs de production sont faciles à démarrer, mais difficiles à exploiter de manière cohérente lorsque la configuration fuit dans les images, les journaux ou le mauvais environnement. Ce guide montre comment garder les valeurs sensibles hors des images Docker, comment choisir entre fichiers d'environnement simples et secrets Docker, et comment vérifier que la configuration fonctionne réellement avant qu'elle n'atteigne la CI/CD ou un hôte de type production.

Vous verrez les commandes exactes pour créer un secret, le référencer dans un fichier Compose, le monter à l'exécution et confirmer que le conteneur voit la valeur attendue. L'objectif est un flux de travail reproductible et testable qui rend l'échec visible tôt.

## Vue d'ensemble du flux de travail

- Identifier la ressource – décidez quel identifiant ou valeur de configuration nécessite une protection (mot de passe de base de données, jeton API, clé privée TLS).

- Choisir le mécanisme – utilisez un fichier .env pour les réglages non secrets (drapeaux de fonctionnalité, niveau de journalisation) et un secret Docker pour tout ce qui doit rester hors de l'image et hors de la sortie de docker inspect .

- Appliquer le changement – créez le secret avec docker secret create db_password ./password.txt (mode Swarm) ou déclarez-le dans un fichier Compose sous secrets: pour le développement local.

- Vérifier l'état observé – lancez un conteneur qui lit le secret et l'affiche pour prouver que le montage fonctionne :

docker run --rm --secret source=db_password,target=db_password alpine cat /run/secrets/db_password 
 Si la commande affiche le mot de passe, le secret est correctement monté à /run/secrets/db_password .

Hypothèses cachées à faire émerger

- Les chemins de montage local ( ./secrets/password.txt ) peuvent ne pas exister sur la machine d'un autre développeur ou dans la CI.

- Les étiquettes d'image ( myapp:latest ) peuvent dériver ; épinglez un digest pour la reproductibilité.

- Les noms de réseau ( frontend_net ) doivent être créés avant docker compose up ou être définis dans le fichier Compose.

- Les limites de ressources ( cpus , memory ) et les limites de descripteurs de fichiers affectent la capacité de l'application à lire le fichier secret.

- Les permissions sur le fichier secret à l'intérieur du conteneur sont par défaut 0400 ; l'utilisateur en cours d'exécution doit avoir un accès en lecture.

Contrôles de santé rapides

- `docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" – liste les conteneurs en cours d'exécution.

- docker logs <conteneur> --tail 100 – affiche les erreurs récentes.

- docker inspect <conteneur> – confirme les montages, variables d'environnement et état de santé.

- Pour Compose : docker compose ps , docker compose logs -f <service> , docker compose exec <service> sh pour déboguer sans reconstruire.

## Plan de test local

Exécutez un test minimal de bout en bout sur votre portable avant d'intégrer le motif dans un pipeline.

- Créer le matériel secret

echo "s3cr3t-p4ss" > ./secrets/db_password.txt 

- Écrire un fichier Compose ( docker-compose.yml ) :

 version: "3.9"
services:
 app:
 image: alpine:3.20
 command: sh -c "cat /run/secrets/db_password && sleep 3600"
 secrets:
 - db_password
 env_file:
 - .env
secrets:
 db_password:
 file: ./secrets/db_password.txt 

- Ajouter un fichier .env non secret (optionnel, pour comparaison) :

 LOG_LEVEL=info
FEATURE_X=enabled 

- Démarrer la pile

 docker compose up -d 

- Confirmer que le secret n'est visible que là où prévu

 docker compose exec app cat /run/secrets/db_password 
 La sortie doit être s3cr3t-p4ss . Vérifier que les valeurs .env apparaissent dans l'environnement du processus :

docker compose exec app printenv | grep -E "LOG_LEVEL|FEATURE_X" 

- Test de redémarrage – arrêter et recréer le conteneur pour s'assurer que le secret persiste après les redémarrages :

 docker compose down
docker compose up -d
docker compose exec app cat /run/secrets/db_password 
 Le secret doit toujours être présent. Si le fichier disparaît, le service écrivait dans la couche accessible en écriture du conteneur au lieu du secret monté.

- Exemple de secret BuildKit (temps de construction uniquement) – ajouter une ligne Dockerfile pour consommer un jeton à la construction sans le cuire dans l'image :

# syntax = docker/dockerfile:1.4
FROM alpine:3.20
RUN --mount=type=secret,id=npm_token \
 npm config set //registry.npmjs.org/:_authToken="$(cat /run/secrets/npm_token)" && \
 npm ci 
 Construire avec :

DOCKER_BUILDKIT=1 docker build --secret id=npm_token,src=./secrets/npm_token.txt -t myapp:dev . 
 Le jeton n'apparaît jamais dans docker history ni dans l'image finale.

## Conclusion

Traitez la configuration comme du code qui doit être testé, pas copié. La voie la plus sûre consiste à garder chaque exemple petit, à exécuter les commandes localement et à confirmer le comportement attendu avant d'ajouter plus de services ou d'automatisation.

Prochaine étape : choisissez un service, documentez les commandes exactes utilisées pour construire, exécuter, inspecter, arrêter et recréer. Puis comparez le résultat avec des pratiques connexes telles que le durcissement de la sécurité Docker, le versionnage des fichiers Compose et les motifs de bonnes pratiques Dockerfile pour que l'implémentation s'intègre au modèle d'exploitation global.

Un flux de travail de conteneurs fiable rend l'échec visible : les journaux sont faciles à trouver, les données persistantes survivent aux reconstructions de conteneurs, et le comportement local reste assez proche de la production pour attraper les erreurs tôt.