Domina la estructura YAML de Docker Compose y conviértela en una plantilla reutilizable para desplegar desde uno hasta cien contenedores sin fricción. Aquí verás cómo definir servicios, puertos, volúmenes, variables de ambiente, redes y el parámetro depends_on para un arranque ordenado y confiable.
¿Cómo estructurar un YAML de Docker Compose paso a paso?
La base es clara: el archivo YAML organiza todo en secciones que describen tu mini orquestación. Desde la versión (hoy ya opcional desde 3.8), hasta los services, networks y volumes. La indentación es crítica: cualquier desalineación rompe la definición.
¿Qué incluye la sección services?
Nombre del servicio único y descriptivo.
Imagen remota o local: puedes usar una image pública sin pasos previos.
Construcción local: usa build con Dockerfile en la carpeta actual.
Puertos: mapeo entre host, Docker y contenedor.
Volúmenes: persistencia y montaje de carpetas/archivos.
Variables de ambiente: configuración clara por servicio.
depends_on: arranque condicionado a otros servicios.
# docker-compose.yml# version: '3.8' # opcional; ya no es requeridaservices:web:build:context: .
dockerfile: Dockerfile
ports:-"8080:80"volumes:- ./:/app
environment:- APP_ENV=prod
depends_on:- db
- cache
- proxy
proxy:image: public/imagen:tag
ports:-"80:80"networks:- app_net
db:image: public/imagen-db:tag
volumes:- db_data:/var/lib/data
networks:- app_net
cache:image: public/imagen-cache:tag
networks:- app_net
networks:app_net:{}volumes:db_data:{}
¿Qué ventajas aportan servicios, volúmenes y variables de ambiente?
Definir todo en Compose es más presentable y mantenible que encadenar banderas en docker run. Además, Compose descarga automáticamente imágenes públicas cuando no existen localmente, reduciendo pasos manuales.
¿Por qué mejora tu flujo de trabajo?
Legibilidad superior: configuración declarativa y ordenada.
Repetibilidad: se ejecuta igual en distintos entornos.
Persistencia con volúmenes nombrados como db_data.
Configuración centralizada con variables de ambiente por servicio.
Escalabilidad: funciona para uno o muchos contenedores.
¿Cómo usar redes y depends_on para orquestar contenedores?
Con networks creas una red común y su configuración se propaga a los contenedores que la usan. Esto facilita la comunicación interna y reduce errores. Con depends_on, garantizas que un servicio dependiente no arranque hasta que sus dependencias estén listas y ejecutándose, evitando fallos por orden de inicio.
¿Cómo convertirlo en una plantilla confiable?
Guarda y reutiliza este archivo como template de referencia.
Imprímelo o consérvalo en formato digital para consulta rápida.
Ajusta nombres de servicios, puertos y volúmenes según el proyecto.
Mantén la indentación alineada para evitar errores sutiles.
Agrega redes y volúmenes según el crecimiento del entorno.
¿Tienes dudas o un caso de uso particular con Compose? Comenta cómo organizarías tus servicios y qué te gustaría optimizar en tu template.
Solo como nota: en las ultimas versiones de Docker ya no es necesario poner la versión al principio del archivo, ya se toma como deprecated.
Me llamó la atención el atributo depends_on de la especificación del Docker Compose. Por lo tanto, decidí profundizar un poco más y aquí les comparto lo que encontré.
El atributo depends_on se utiliza para controlar el orden en el cual se inician y terminan los servicios definidos en el archivo Docker Compose. De este modo, se garantiza que las dependencias se ejecuten antes que el servicio dependiente. Sin embargo, me inquietaba conocer el criterio que utiliza Docker para determinar cuando una dependencia se encuentra “lista”. De acuerdo con la documentación, para este fin se utiliza el atributo condition, al cual se le asignan los valores que le indican a Docker cuándo considerar una dependencia como “lista”:
service_started: La dependencia está lista tan pronto como el contenedor inicia su ejecución.
service_healthy: La dependencia está lista tan pronto como se apruebe el healthchcek.
service_completed_successfully: La dependencia está lista tan pronto como el servicio termine su ejecución exitosamente.
La diferencia entre los valores service_started y service_completed_successfully radica en que el primero hace referencia a un servicio que ejecuta un proceso de manera indefinida y el segundo a un proceso que se ejecuta una vez y tiene un estado de salida (exit status).
En el ejemplo anterior, el servicio “web” inicia tan pronto como el contenedor de Redis se ejecute y la base de datos PostgreSQL se encuentre lista para recibir conexiones.
Adjunto el enlace a la documentación oficial:
A mi me encanta ocupar docker compose en ambientes de desarrollo porque es bastante cómodo el levantar varios contenedores a la vez sin mucho esfuerzo. Por ejemplo si estas haciendo un proyecto de PHP ocuparías los siguientes contenedores:
Contenedor de PHP-Apache
Contenedor de Base de datos
Contenedor de PHPMyAdmin
Todos dentro de un único archivo docker-compose.yml para todos los participantes del proyecto es muy sencillo levantar el ambiente de desarrollo con una linea:
docker compose up -d --build
Es una buena forma de simular lo que sería un ambiente "productivo", aprendiendo a usar docker, como se conectan entre si, como puedo almacenar y persistir los datos de la BD, y como puedo leer y escribir desde el el aplicativo php y todo siendo conectado por medio de contenedores
Es mala practica colocar en un solo contenedor esos 3 servicios?
Yo tengo una duda, y no se si algunos de los profesores pueda ayudarme.
Usando docker-compose, estoy tratando de crear un contenedor de mongo, y quiero usar transacciones ya que estoy haciendo un proyecto lo mas cercano a nivel profesional para ganar experiencia, pero aun no logro habilitar correctamente para usar transacciones, como este es un curso avanzado, pensaba que alguno de los profesores puede tener experiencia en eso.
Agradecería su aporte
Si, eso sucede porque los transactions solo funcionan en ambientes con replicas set.
Puedes intentar algo como se describe en este post de Stackoverflow:
En el proyecto donde trabajo tenemos un fallback en caso que el transaction falla debido a la topología de la red volvemos a intentar el proceso sin usar transactions esto me permite hacer pruebas locales.
En el volumen del servicio web, que luce así en la configuración: ./web:/usr/share/nginx/html, necesitariamos una carpeta ./web? Porque no entiendo del todo esta configuración
Docker Compose es ampliamente compatible con muchos servicios en la nube, pero no todos los servicios pueden admitirlo de manera nativa. Algunos proveedores de servicios en la nube, como AWS o Azure, permiten el uso de Docker pero pueden tener sus propias herramientas y configuraciones para gestionar contenedores. La implementación de Docker Compose puede requerir ajustes específicos o el uso de otras herramientas, como Kubernetes, en ciertos entornos. Es importante consultar la documentación del servicio en la nube que estés considerando.
