Per impostazione predefinita, i container possono utilizzare risorse host illimitate — il che comporta il rischio che un container esaurisca le risorse degli altri o faccia crash dell'host. Docker ti consente di impostare limiti di risorse (CPU, memoria) per controllare il consumo, importante per la stabilità e la condivisione equa delle risorse in produzione.
Il problema: utilizzo di risorse senza limiti
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.
Impostazione dei limiti di memoria e CPU
# 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)
# 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
I limiti di memoria (-m) limitano l'utilizzo (il container viene terminato per OOM se supera il limite fisso); i limiti di CPU (--cpus) limitano l'utilizzo della CPU. Le riserve garantiscono un minimo.
Monitoraggio e ottimizzazione
✓ 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
Perché è importante
Comprendere la gestione delle risorse dei container è importante per eseguire i container in modo affidabile in produzione, quindi rappresenta una conoscenza operativa preziosa.
Il problema fondamentale — per impostazione predefinita, i container possono consumare tutte le risorse host disponibili — è un rischio reale: un singolo container difettoso o occupato (con una memory leak o un processo in fuga) può privare gli altri container di risorse o causare il crash dell'intero host (esaurimento della memoria), rendendo l'host instabile.
Impostare limiti di risorse (memoria e CPU) previene questo isolando il consumo di risorse dei container, assicurando che un container non possa disabilitare gli altri o l'host — essenziale per la stabilità quando si eseguono più container per host (la norma in produzione).
Comprendere come impostare limiti di memoria (con il container terminato per OOM se supera il limite fisso) e limiti di CPU, più riserve (garantendo i minimi), è il meccanismo pratico per controllare e condividere equamente le risorse.
Sapere come monitorare e ottimizzare — utilizzando docker stats per osservare l'utilizzo effettivo e dimensionare i limiti in modo appropriato, riconoscendo OOMKilled (un container che raggiunge il suo limite di memoria) per diagnosticare i problemi — è importante per impostare limiti appropriati in base alle esigenze reali.
Questo si collega anche all'orchestrazione: Kubernetes utilizza richieste/limiti di risorse simili che sono essenziali per la pianificazione e la stabilità, quindi la comprensione del concetto si trasferisce agli ambienti orchestrati.
Poiché l'esecuzione affidabile di più container richiede di prevenire la contesa di risorse e il consumo incontrollato, e poiché i limiti di risorse (limiti di memoria e CPU, riserve, monitoraggio) sono il meccanismo per isolare i container e proteggere la stabilità dell'host, comprendere la gestione delle risorse dei container è una conoscenza preziosa e praticamente importante per i deployment di container in produzione — necessaria per host multi-container stabili e un concetto che si estende direttamente agli ambienti orchestrati come Kubernetes, dove la specifica delle risorse è fondamentale.