Cómo limitar recursos por contenedor en Docker Compose

Necesidad de limitar recursos en Docker Compose

Cuando despliegas aplicaciones con Docker Compose, cada servicio arranca en su propio contenedor. Por defecto, estos contenedores intentan consumir todos los recursos de CPU y memoria que el host les permita. Esto es un problema real en producción, especialmente en servidores con recursos limitados.

Sin límites de recursos, un contenedor puede acaparar toda la CPU, agotar la memoria disponible o incluso hacer que el servidor se quede sin capacidad de respuesta. La limitación de recursos es una medida para garantizar estabilidad y rendimiento.

Cómo configurar memory limit y CPU en Docker Compose

La configuración de límites de memoria y CPU se hace directamente en tu archivo docker-compose.yml, dentro de la sección deploy para cada servicio. Docker utiliza cgroups para aplicar estas restricciones a nivel de sistema operativo.

Aquí tienes un ejemplo práctico para un servicio web y una base de datos:

version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    deploy:
      resources:
        limits:
          cpus: '0.5' # 50% de un core
          memory: 128M # 128 Megabytes
        reservations:
          cpus: '0.25' # Garantiza 25% de un core
          memory: 64M # Garantiza 64 Megabytes

  database:
    image: postgres:14
    environment:
      POSTGRES_DB: mydatabase
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - db_data:/var/lib/postgresql/data
    deploy:
      resources:
        limits:
          cpus: '1.0' # 100% de un core
          memory: 512M # 512 Megabytes
        reservations:
          cpus: '0.5' # Garantiza 50% de un core
          memory: 256M # Garantiza 256 Megabytes

volumes:
  db_data:

En este bloque, limits establece el máximo de recursos que un contenedor puede usar, mientras que reservations define la cantidad mínima garantizada. Asegura un rendimiento base.

Impacto de no limitar los recursos de tus contenedores

No limitar los recursos genera inestabilidad. Un pico de tráfico en tu servicio web o una consulta compleja en tu base de datos pueden consumir todos los recursos disponibles, afectando al resto de servicios. He visto servidores de clientes quedarse completamente bloqueados por un solo contenedor sin límites.

La gestión de recursos marca la diferencia entre un entorno de desarrollo y producción. Lo que funciona de forma fluida en local con pocos datos, puede colapsar en producción bajo carga. Si tu código funciona en local y falla en producción, a menudo el problema no es el código, sino el entorno y cómo interactúa con los recursos. Para entender mejor este punto, te recomiendo leer Por qué tu código funciona en local y falla en producción.

Consideraciones al limitar recursos

Limitar los recursos de tus contenedores introduce sus propios desafíos. Como en cualquier decisión de arquitectura, hay que sopesar beneficios y complicaciones.

Lo que ganas:

Estabilidad del sistema: Un contenedor no puede agotar los recursos de todo el servidor, protegiendo al resto de servicios.
Rendimiento predecible: Al reservar recursos, aseguras que los servicios críticos siempre tendrán una base mínima de CPU y memoria.
Detección temprana de cuellos de botella: Si un contenedor alcanza constantemente sus límites, es una señal clara de que necesita más recursos o que la aplicación tiene un problema de optimización. Para optimizar el rendimiento, a veces la solución pasa por una buena estrategia de caché, como explico en Caché en aplicaciones web: cuándo ayuda y cuándo estorba.

Lo que complicas:

Configuración inicial: Requiere estimar los recursos necesarios para cada servicio, lo cual no siempre es trivial.
Monitorización constante: Los límites deben ajustarse si los patrones de uso cambian. No basta con configurarlos una vez.
Posible infradimensionamiento: Si los límites son demasiado restrictivos, puedes estrangular el rendimiento de un servicio, incluso si el servidor tiene recursos disponibles.

Mi regla es empezar con límites conservadores y ajustarlos al alza según las métricas de uso. Es preferible que un servicio se ralentice o reinicie por falta de recursos a que arrastre a todo el servidor.

Monitorización y ajuste de límites

Una vez que has implementado los límites, la tarea no termina. Necesitas monitorizar el uso real de CPU y memoria de tus contenedores. Herramientas como docker stats o sistemas de monitorización más avanzados te darán la visibilidad que necesitas.

docker stats

Este comando te muestra en tiempo real el consumo de CPU, memoria, red y E/S de disco de tus contenedores. Es tu principal aliado para identificar si los límites son adecuados o si algún servicio necesita un ajuste. Si un contenedor está constantemente cerca de su límite de CPU o memoria, es momento de revisar la configuración o el código de la aplicación.

Si utilizas Docker Compose profiles para entornos distintos, puedes incluso definir límites diferentes para desarrollo y producción. Además, es fundamental que tengas una estrategia clara sobre cómo persisten los datos, por ejemplo, entendiendo la diferencia entre volúmenes Docker vs bind mounts. Y si tu aplicación crece hasta el punto de necesitar más que un solo servidor, es importante saber cuándo escalar verticalmente y cuándo añadir otro VPS.