Docker Compose sigue siendo la forma más rápida de levantar entornos multi-contenedor: aplicación + base de datos + caché + reverse proxy, todo con un único docker compose up. Este generador visual produce archivos docker-compose.yml conformes al Compose Spec actual, con puertos mapeados, volúmenes persistentes, redes personalizadas y variables de entorno bien tipadas, listos para desarrollo local y para producción sencilla.
Compose Spec: el estándar actual
Desde 2020 el campo `version` ha desaparecido y todos los archivos se validan contra el Compose Spec unificado. Los generadores modernos no lo emiten para evitar warnings. Nuestro generador respeta esta convención y produce YAML compatible tanto con `docker compose` (plugin oficial) como con `docker-compose` v2 heredado.
Redes y aislamiento entre servicios
Por defecto Compose crea una red bridge para el proyecto y expone cada servicio bajo su nombre como hostname interno. Puedes definir varias redes para aislar tráfico: por ejemplo, colocar la base de datos solo en una red `backend` y el proxy Nginx a caballo entre `frontend` y `backend`. Este patrón simula redes de producción y mejora la seguridad al no exponer la DB al mundo.
Volúmenes: named vs bind mounts
Los volúmenes con nombre (`db-data:/var/lib/postgres`) los gestiona Docker y persisten datos entre reinicios; son la opción correcta para bases de datos y caches. Los bind mounts (`./src:/app/src`) mapean directorios del host y son útiles en desarrollo para hot-reload, pero causan problemas de rendimiento en macOS/Windows y de permisos en Linux. Evítalos en producción.
Variables de entorno y secretos
Compose lee automáticamente un archivo .env local. No commitees ese archivo: añádelo a .gitignore y comparte un .env.example con las claves esperadas. Para secretos reales (contraseñas, tokens) usa `secrets:` (que monta archivos read-only) o integra un gestor externo como HashiCorp Vault o AWS Secrets Manager.
Casos de uso comunes
- Levantar un stack de desarrollo (app + PostgreSQL + Redis) en 30 segundos.
- Reproducir en local un entorno idéntico al de staging para reproducir bugs.
- Desplegar apps pequeñas en un VPS sin necesidad de Kubernetes.
- Onboarding de nuevos devs: clonar el repo y `docker compose up`.
Buenas prácticas
- Fija versiones exactas de imágenes: `postgres:16.2-alpine`, no `postgres:latest`.
- Añade healthchecks y `depends_on: condition: service_healthy` para orden de arranque.
- Limita recursos con `deploy.resources.limits` para evitar que un contenedor consuma todo.
- Usa `restart: unless-stopped` en producción; `no` en desarrollo.