Como você gerencia recursos de container (CPU e memória)?

Question

Accepted Answer

Por padrão, containers podem usar **recursos ilimitados do host** — o que arrisca um container consumir recursos dos outros ou derrubar o host. Docker permite que você defina **limites de recursos** (CPU, memória) para controlar o consumo, importante para estabilidade e compartilhamento justo de recursos em produção.

## O problema: uso ilimitado de recursos

```text
BY DEFAULT a container can consume ALL available host CPU and memory:
  → a buggy/busy container (memory leak, runaway loop) can starve other containers
    or crash the entire host (out of memory)
→ In production (multiple containers per host), LIMIT resources to isolate them.
```

## Definindo limites de memória e CPU

```bash
# memory limits
docker run -m 512m myapp              # hard limit: 512 MB (container killed if exceeded — OOM)
docker run -m 512m --memory-reservation 256m myapp   # soft limit + hard limit

# CPU limits
docker run --cpus="1.5" myapp         # limit to 1.5 CPU cores
docker run --cpu-shares=512 myapp     # relative weight (priority under contention)
```

```yaml
# in docker-compose.yml (or for orchestrators)
services:
  app:
    deploy:
      resources:
        limits:    { cpus: '1.5', memory: 512M }   # maximum
        reservations: { cpus: '0.5', memory: 256M } # guaranteed minimum
```

Limites de memória (`-m`) limitam o uso (o container é **morto por OOM** se exceder o limite rígido); limites de CPU (`--cpus`) limitam o uso de CPU. **Reservas** garantem um mínimo.

## Monitorando e ajustando

```text
✓ docker stats → live CPU/memory usage per container (to right-size limits)
✓ Set limits based on the app's actual needs (measure, then add headroom)
✓ OOMKilled (in docker inspect) → the container hit its memory limit → raise it or fix a leak
✓ Orchestrators (Kubernetes) use requests/limits similarly — essential for scheduling
```

## Por que isso importa

Entender o gerenciamento de recursos de container é importante para **executar containers de forma confiável em produção**, portanto é um conhecimento operacional valioso.

O problema central — por padrão, **containers podem consumir todos os recursos disponíveis do host** — é um risco real: um único container com erro ou sobrecarregado (com vazamento de memória ou processo descontrolado) pode **privar outros containers de recursos ou derrubar o host inteiro** (falta de memória), tornando o host instável.

Definir **limites de recursos** (memória e CPU) previne isso ao **isolar o consumo de recursos dos containers**, garantindo que um container não possa derrubar outros ou o host — essencial para estabilidade ao executar múltiplos containers por host (a norma em produção).

Entender como definir **limites de memória** (com o container sendo morto por OOM se exceder o limite rígido) e **limites de CPU**, além de **reservas** (garantindo mínimos), é o mecanismo prático para controlar e compartilhar recursos de forma justa.

Saber como **monitorar e ajustar** — usando `docker stats` para observar uso real e adequar limites, reconhecendo `OOMKilled` (um container atingindo seu limite de memória) para diagnosticar problemas — é importante para definir limites apropriados com base em necessidades reais.

Isso também se conecta à orquestração: **Kubernetes usa requisições/limites de recursos similares** que são essenciais para agendamento e estabilidade, então entender o conceito se transfere para ambientes orquestrados.

Já que executar múltiplos containers de forma confiável exige prevenir contenção de recursos e consumo descontrolado, e já que limites de recursos (limites de memória e CPU, reservas, monitoramento) são o mecanismo para isolar containers e proteger a estabilidade do host, entender o gerenciamento de recursos de container é um conhecimento valioso e praticamente importante para deployments de containers em produção — necessário para hosts multi-container estáveis e um conceito que se estende diretamente para ambientes orquestrados como Kubernetes, onde a especificação de recursos é fundamental.