Valider Docker Compose et fichiers `.env` en ligne
Vérifiez la structure de vos `compose.yml` et `.env` avant de lancer `docker compose up` — sans installer d'outils.
Pourquoi valider Compose et `.env` avant le deploy ?
Un `docker compose up` qui échoue à cause d'une clé `services` mal indentée ou d'une ligne `.env` sans `=` fait perdre du temps sur une machine neuve, en CI ou pendant un onboarding. Un contrôle rapide de la structure avant de lancer la stack attrape les fautes de frappe évidentes avant que Docker ne s'en plaigne. Sur FastMinify, vous pouvez valider un fichier Docker Compose en ligne et valider un fichier `.env` en ligne — 100 % dans le navigateur, sans installer Docker ni Node. Le cluster complet est sur le hub d'outils DevOps, à côté de Terraform, du Dockerfile et du HCL.
Erreurs fréquentes et workflow avant deploy
Quelques fautes reviennent constamment. Les corriger avant `docker compose up` évite des messages Docker cryptiques.
Le validateur signale les clés qui ressemblent à des secrets (`PASSWORD`, `API_KEY`, `SECRET`, `TOKEN`), mais ce n'est qu'un rappel — pas un scan de secrets. La vraie discipline reste de ne pas committer les `.env`.
Compose vs `.env` : deux intentions
Compose et `.env` se complètent : l'un décrit la stack, l'autre injecte la config. En revue, validez les deux avant de lancer la stack.
Ce qui est vérifié
Quand l'utiliser
Un enchaînement simple évite de découvrir les erreurs au moment du deploy.
Quand l'outil navigateur suffit
Pas besoin de Docker installé pour vérifier trois erreurs sur un `compose.yml` reçu par message.
Limites : ce que le navigateur ne remplace pas
Dès que vous devez résoudre l'interpolation `${VAR}`, fusionner plusieurs fichiers Compose (`-f`), ou vérifier qu'une image existe, la CLI Docker et le démon restent obligatoires.
Un service arrive souvent avec un Dockerfile, du HCL Terraform et un `.env`. Valider Compose et `.env` + linter le Dockerfile + formater le HCL couvre le parcours DevOps quotidien.
CLI et écosystème
La CLI Docker et quelques linters restent le standard. Les outils FastMinify sont un complément rapide pour l'exploration et les one-shots.
docker compose config
Rend le fichier final avec variables résolues et signale les erreurs de spec.
Avantages :
Inconvénients :
dotenv-linter
Linter `.env` rapide (Rust) avec règles sur les clés et les valeurs.
Avantages :
Inconvénients :
yamllint
Linter YAML générique utile pour l'indentation et le style.
Avantages :
Inconvénients :
Anatomie d'un `compose.yml` et d'un `.env`
Un fichier Compose moderne est un unique document YAML avec une clé racine `services` obligatoire. Chaque service devrait déclarer une `image` ou un bloc `build`. Les autres clés racine attendues sont `networks`, `volumes`, `secrets`, `configs`, `name` et l'historique `version`. La clé `version` est désormais optionnelle dans la spec Compose actuelle, mais reste tolérée.
Un `.env` est une liste de paires `KEY=VALUE`, une par ligne. Les lignes vides et les commentaires (`#`) sont ignorés, et le préfixe `export ` est toléré. Les noms de clé suivent la convention shell (lettres, chiffres, underscore, sans commencer par un chiffre). Une valeur avec des espaces doit être entre guillemets pour éviter les surprises.
Ces deux validateurs font des contrôles <strong>structurels</strong>, pas une validation complète de la spec Compose ni un scan de secrets. Ils ne résolvent pas l'interpolation de variables (`${VAR}`), ne vérifient pas qu'une image existe sur un registre, et ne lancent pas `docker compose up`. Pour la vérité runtime, `docker compose config` et le démon Docker restent la référence.
Deux validations : Compose et `.env`
Le validateur parse le YAML, vérifie qu'il y a un seul document, une racine de type mapping et une clé `services`. Il signale les services sans `image` ni `build` et les clés racine inconnues. Essayez le validateur Docker Compose en ligne.
Le validateur `.env` lit chaque ligne, remonte celles sans `=` ou avec une clé illégale, détecte les guillemets non fermés, les clés dupliquées et les valeurs non quotées contenant des espaces. Utilisez le validateur `.env` en ligne avant de partager un fichier d'exemple.
Un service arrive rarement seul. Enchaînez avec le linter Dockerfile en ligne et le formateur Terraform / HCL en ligne pour couvrir toute la config d'infra.
Conclusion
Valider la structure de vos `compose.yml` et `.env` avant `docker compose up` évite des échecs de deploy sur des fautes de frappe. Utilisez le navigateur pour un premier filtre structurel, puis `docker compose config` et le démon Docker pour la vérité runtime. Enchaînez avec le Dockerfile et le HCL Terraform sur le même hub DevOps.
Articles connexes
Détectez les anti-patterns Docker (root user, cache layers, tags `latest`) et formatez vos Dockerfiles avant la CI.
Formatez et validez votre code HCL/Terraform avant un `terraform plan`. Outils navigateur, bonnes pratiques IaC et pièges courants.
Optimisez votre site WordPress avec la minification JavaScript, CSS et HTML. Comparatif des plugins, configuration et astuces pour un WordPress ultra-rapide.