Un fichier .env ignoré par Git reste un fichier en clair. Dans une stack Docker Compose, il finit facilement dans une copie de migration, une sauvegarde, une archive de support ou, un jour, l’historique du dépôt.
SOPS et age permettent de corriger une partie du problème sans déployer un gestionnaire de secrets centralisé. Le principe est simple : le dépôt contient un fichier chiffré, les clés privées restent hors de Git et le serveur ne déchiffre que les valeurs nécessaires au déploiement.
Docker Compose reçoit ensuite ces valeurs sous forme de fichiers montés dans /run/secrets/. Les mots de passe ne passent plus par environment: et ne finissent plus dans la configuration du conteneur.
Cette méthode convient bien à un homelab, à quelques VPS ou à une petite infrastructure pilotée par Git. SOPS reste un outil de chiffrement de fichiers, pas un gestionnaire de secrets centralisé, et ne protège pas un hôte déjà compromis.
J’ai longtemps gardé tout mon homelab sous Docker Compose. Pas par rejet de Kubernetes : Compose faisait le travail, les volumes étaient faciles à retrouver et je savais remettre un service en route sans relire une pile de manifests.
K3s est arrivé plus tard, quand j’ai voulu uniformiser les déploiements et préparer l’ajout d’autres machines. Je n’ai pas tout migré pour autant. Aujourd’hui, les deux cohabitent encore. C’est volontaire.
Pour trancher, je regarde surtout la panne : avec lequel des deux vais-je retrouver les données et remettre le service en route sans improviser ?
Le tag latest est confortable.
On écrit un compose.yml, on lance docker compose up -d, et le service démarre. Pas besoin de choisir une version de PostgreSQL, Redis, Traefik, Gitea, Vaultwarden ou n’importe quelle application auto-hébergée.
Le problème, c’est que latest ne veut pas dire “dernière version stable adaptée à mon environnement”. Ça veut seulement dire : “ce tag pointe vers quelque chose dans le registre au moment où Docker le résout”.
Ce quelque chose peut changer sans que votre fichier Compose change.
Pour une stack de test, ce n’est pas très grave. Pour une base de données, un reverse proxy exposé, un service d’authentification ou une application avec des volumes persistants, c’est une mauvaise convention d’exploitation.
Le vrai sujet n’est pas Docker. C’est la reproductibilité.
