Ce qu'est docker-compose.yml, en un paragraphe
Un service est un conteneur, et un fichier `docker-compose.yml` est une liste de services qui doivent tourner ensemble (votre app, une base de données, peut-être un cache et un reverse proxy). Une commande, `docker compose up`, démarre la stack entière et une autre, `docker compose down`, la ramène à zéro. C'est la manière standard de faire tourner des apps multi-conteneurs sur une seule machine : laptops de dev, serveurs prod single-node, runners CI.
Ce générateur écrit ce fichier pour vous. Choisissez un preset (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, un Redis seul, un ClickHouse seul), éditez les services dans des formulaires simples, et le panneau de droite montre le YAML exact prêt à coller dans `docker-compose.yml`. Chaque option a une astuce en clair.
Tout tourne dans votre navigateur. Rien n'est uploadé, pas besoin de compte, aucun conteneur n'est réellement démarré ici - la sortie est le même texte que vous écririez à la main.
Mode d'emploi
- Choisissez un preset en haut (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, Single Redis, ClickHouse single-node). Le formulaire remplit des défauts sensés que vous pouvez ajuster.
- Réglez un nom de projet en haut. Ça devient le champ `name:` dans le fichier et le préfixe pour les noms de conteneurs (plus de noms aléatoires comme `myapp_web_1`).
- Pour chaque service réglez : image (par exemple `nginx:alpine`), ports (host:container, répétable), volumes (avec un toggle read-only), et variables environment.
- Choisissez une politique de restart : `no`, `always`, `on-failure`, ou `unless-stopped`. Pour les serveurs de prod, `unless-stopped` est le choix habituel.
- Utilisez depends_on pour dire "démarre la base de données avant l'app". Ajoutez un healthcheck sur la base de données pour que les autres services puissent attendre la disponibilité, pas juste le démarrage.
- Définissez les networks au niveau top et assignez chaque service à un ou plusieurs. Les services sur le même réseau s'atteignent par nom (par exemple `db:5432`).
- Cliquez sur Copier dans le panneau d'aperçu, ou Télécharger pour sauvegarder comme `docker-compose.yml`, puis lancez `docker compose up -d` dans le même dossier. C'est tout le flow.
Quand cet outil est utile
Sept situations concrètes où docker-compose rend la vie bien plus facile :
- Un laptop de dev qui a besoin de Postgres, Redis et votre app Node. Un fichier, un `docker compose up`, et votre stack entière est en ligne. Pas de Homebrew, pas d'apt-get, pas de dérive de version dans l'équipe.
- Un petit VPS hébergeant une ou deux apps. Compose est le chemin le plus simple : écrivez le fichier, `docker compose up -d`, mettez nginx devant, fini. Kubernetes c'est trop pour une seule boîte.
- Miroir local de la production. Si la prod tourne Postgres 16, Redis 7 et Node 20, le même fichier compose épingle ces versions sur chaque machine de dev. "Marche sur mon laptop" devient "marche sur chaque laptop".
- Pipelines CI qui ont besoin de vrais services. Compose monte un vrai Postgres pour les tests d'intégration en quelques secondes, puis le démonte. Bien plus proche de la prod que les mocks ou sqlite.
- Self-hosting d'apps tierces : WordPress, Ghost, Mastodon, NextCloud, Plausible, Gitea, n8n. Le fichier compose officiel est généralement le chemin d'install documenté.
- Mettre une stack en ligne pour une démo. Vous livrez un repo avec un fichier et le reviewer tape une commande. Pas de "installe d'abord Postgres 14 avec ces extensions".
- Essayer une nouvelle base de données. Envie de jouer avec ClickHouse, MongoDB ou DuckDB sans rien installer globalement ? `docker compose up` pour cinq minutes, puis `docker compose down -v` et la machine est propre à nouveau.