Estructura y plantilla de Docker Compose YAML

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:006:17

Estructura y plantilla de Docker Compose YAML

Curso de Docker Avanzado

Clase 26 de 34

Clase 26 / 34

Recursos

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 requerida
services:
  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.

Santiago Gómez

Hace un año

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).

services:
  web:
    build: .
    depends_on:
      db:
        condition: service_healthy
        restart: true
      redis:
        condition: service_started
  redis:
    image: redis
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U your_user -d your_database"]

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:

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Estructura y plantilla de Docker Compose YAML