Administración del host de Docker Engine: daemon.json, uso de disco y live-restore

Objetivo

Configurar el comportamiento de logging y almacenamiento del daemon de Docker Engine, comprobar el uso de disco y recuperar espacio sin eliminar recursos que siguen en uso.

Requisitos previos

Acceso como root o pertenencia al grupo docker en el host. Pertenecer al grupo docker equivale a ser root en ese host, porque el daemon se ejecuta como root y el grupo puede indicarle que monte mediante bind-mount rutas arbitrarias del host; conviene tratar la pertenencia al grupo docker con el mismo cuidado que el acceso mediante sudo.

Pasos

1. El daemon lee /etc/docker/daemon.json (JSON) al arrancar; la referencia de dockerd documenta sus opciones de línea de comandos, la mayoría de las cuales tiene una clave JSON equivalente. Claves habituales a nivel de host:

{
  "data-root": "/var/lib/docker",
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" },
  "live-restore": true
}

2. data-root cambia la ubicación donde se almacenan imágenes, contenedores y volúmenes. Para moverlo hay que detener el daemon (docker.service y docker.socket; de lo contrario, la activación por socket lo vuelve a iniciar), copiar el directorio existente conservando propietarios, permisos y atributos extendidos, actualizar la clave y volver a iniciar el daemon. Esto detiene todos los contenedores, incluso con live-restore activado.
3. log-driver/log-opts establecen el driver de logging predeterminado para los contenedores nuevos. Sin max-size/max-file en el driver json-file, los logs de los contenedores pueden crecer sin límite en disco. Los contenedores existentes conservan su configuración de logs anterior hasta que se vuelvan a crear.
4. live-restore: true mantiene en ejecución los contenedores Linux independientes (standalone) mientras el daemon está detenido, falla o se actualiza a una versión de parche más reciente (YY.MM.x). No es compatible entre actualizaciones de versión mayor (YY.MM), no se aplica a los servicios de Swarm y puede fallar si cambiaron opciones del daemon como el storage driver o las direcciones del bridge. Mientras el daemon está caído, un contenedor que llene el búfer de 64K de su pipe de logs se bloquea al escribir su salida. Se activa con sudo systemctl reload docker (SIGHUP) en lugar de un reinicio, que detendría los contenedores en ejecución porque live-restore aún no estaría activo; se comprueba con docker info --format '{{.LiveRestore}}'.
5. Para aplicar los cambios de forma no interactiva: haga una copia de seguridad de daemon.json, valídelo con sudo dockerd --validate --config-file /etc/docker/daemon.json (Docker 23.0 y posteriores) y luego ejecute sudo systemctl restart docker (detiene los contenedores salvo que live-restore ya esté activado) o reload para las opciones recargables. Si un mismo ajuste se indica tanto en daemon.json como en un flag de la unidad del servicio (habitualmente hosts/-H), el daemon se niega a arrancar; revise journalctl -u docker --no-pager. Para deshacer los cambios, restaure la copia de seguridad.
6. Compruebe el uso de disco por categorías con docker system df (-v para el desglose por elemento, incluido el espacio recuperable).
7. Recupere espacio con cuidado: docker system prune elimina todos los contenedores detenidos, las redes que no usa ningún contenedor, las imágenes dangling y la cache de compilación no utilizada; -a elimina además todas las imágenes que no usa ningún contenedor, y --volumes elimina además los volúmenes anónimos que no usa ningún contenedor (los volúmenes con nombre se conservan). Pide confirmación; -f omite la pregunta en scripts. Ejecute antes docker system df y haga el prune sin -a/--volumes a menos que haya confirmado que nada necesario depende únicamente de un contenedor detenido.

Resultado esperado

docker info refleja los nuevos valores de data-root/live-restore; docker system df muestra menos espacio recuperable después de un prune, sin que se hayan tocado los contenedores activos ni sus imágenes.

Límites y base de verificación

El alcance exacto de docker system prune depende de sus flags y ha cambiado entre versiones (los motores más antiguos también eliminaban con --volumes los volúmenes con nombre sin usar). Ejecutarlo sin revisar antes docker system df puede borrar un contenedor detenido que todavía se necesita para una tarea programada.