Unifica el entorno de desarrollo de tu equipo con la configuración global del demonio Docker

Cuando trabajamos con Docker, ya sea en local o en servidores, es habitual copiar y pegar las mismas configuraciones en el docker-compose.yml de cada proyecto.

  • Por ejemplo, ajustar siempre el DNS a 1.1.1.1, 8.8.8.8.
  • Fijar el controlador de logs a json-file + max-size=10m.
  • Configurar un proxy, un registro inseguro, rangos de red por defecto, etc.

Es mucho más sencillo si estas configuraciones, en lugar de ser ajustes individuales de cada contenedor, se establecen como "valores predeterminados para todo el host". Esto se logra mediante la configuración global del demonio Docker (daemon.json).

A continuación, explicaremos:

  • Qué archivo usar
  • Dónde crearlo
  • Cómo configurarlo
  • En qué situaciones es más útil para diferentes desarrolladores o equipos


1. Dos maneras de configurar el demonio Docker

El demonio Docker (dockerd) se puede configurar principalmente de dos maneras:

  1. Uso del archivo de configuración JSON (daemon.json) ← Recomendado
  2. Pasar opciones como flags de CLI al ejecutar dockerd.

Aunque se pueden combinar, si especificas la misma opción en ambos, el demonio simplemente no arrancará. Por ejemplo, si configuras el controlador de logs tanto con el flag --log-driver como en daemon.json, Docker fallará al iniciar.

Para unificar los entornos de equipo o servidor, lo recomendable suele ser:

“Reunir la mayor cantidad de configuraciones en daemon.json y usar los flags solo para lo mínimo indispensable”

2. Ubicación del archivo daemon.json

La ubicación del archivo es /etc/docker/daemon.json. Esto, por supuesto, es para Linux.

Aunque no estoy seguro de cuánta gente usa Docker fuera de Linux (ya que yo solo lo utilizo en este sistema operativo y no conozco bien otros), he preparado una tabla con las ubicaciones por defecto para cada OS:

Entorno Ruta predeterminada Notas
Linux (instalación estándar) /etc/docker/daemon.json El caso más común
Linux (Docker instalado con snap) /var/snap/docker/current/config/daemon.json Paquete snap de Ubuntu
Windows Server / Docker Engine C:\ProgramData\Docker\config\daemon.json
Docker Desktop (Mac / Windows) ~/.docker/daemon.json
  • Este archivo puede no existir por defecto, por lo que si no lo encuentras, puedes crearlo y usarlo.

3. Patrón de uso básico: “Crear archivo → Reiniciar demonio”

El flujo de trabajo habitual en Linux es el siguiente:

  1. Crear/Modificar daemon.json
{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}
  1. Validar previamente la configuración.
sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Si aparece "configuration OK", es correcto.
  1. Reiniciar el demonio Docker.
sudo systemctl restart docker

A partir de este momento, los nuevos contenedores heredarán estas configuraciones globales como valores predeterminados, salvo que se les apliquen ajustes específicos.

4. Configuración principal: Fijar el servidor DNS globalmente

4.1 ¿Por qué DNS globalmente?

Si tus contenedores tienen problemas para “encontrar una API externa” o “resolver un dominio interno”, es muy probable que se deba a una dependencia de la configuración DNS del host.

Por ejemplo:

  • Todo el equipo desea usar Cloudflare DNS (1.1.1.1).
  • Existe un endpoint que solo se puede acceder a través del servidor DNS interno de la empresa.

En estos casos, en lugar de añadir dns: en el docker-compose.yml de cada proyecto, es mucho más práctico unificarlo directamente a nivel del demonio Docker.

4.2 Ejemplo de configuración (daemon.json)

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Si ya tienes un daemon.json existente, simplemente añade la entrada "dns": [...] dentro del objeto raíz { ... }.

⚠️ Advertencia: La configuración DNS se refleja en /etc/resolv.conf dentro del contenedor. No se aplica de inmediato a los contenedores ya en ejecución, sino que solo afectará a los nuevos contenedores que inicies.

5. Configuración principal 2 – Controlador de logs y opciones globales

Por defecto, los logs de los contenedores se guardan a través del controlador json-file en /var/lib/docker/containers/.... Si modificas esto globalmente, podrás aplicar el formato, la ubicación y la política de rotación de logs de forma masiva a todos los contenedores.

5.1 Controlador json-file predeterminado + rotación

El patrón más común es “usar json-file con una configuración de rotación para evitar que el disco se sature”.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "5"
  }
}

Así configurado, se asegura que:

  • El tamaño máximo del archivo de log por contenedor sea de 10MB.
  • Se mantengan un máximo de 5 archivos.
  • Los archivos excedentes se eliminen automáticamente.

5.2 Controladores para la recolección centralizada de logs (fluentd, journald, etc.)

Si eres parte de un equipo de plataforma o infraestructura, a menudo querrás enviar los logs de todos los contenedores a un sistema de logging centralizado.

Por ejemplo, si utilizas Fluentd:

{
  "log-driver": "fluentd",
  "log-opts": {
    "fluentd-address": "localhost:24224",
    "tag": "{{.Name}}"
  }
}

Con esta configuración, los logs de todos los contenedores se enviarán automáticamente a Fluentd sin necesidad de un docker run --log-driver=... separado.

Personalmente, el controlador journald también me parece excelente. En entornos Linux basados en systemd, te permite consolidar los logs de aplicaciones y los de contenedores Docker en un solo lugar (journald), unificando la consulta, el filtrado y las políticas de retención usando únicamente journalctl.

Si deseas usar journald como controlador de logs global, puedes configurarlo, por ejemplo, de esta manera:

{
  "log-driver": "journald",
  "log-opts": {
    "tag": "{{.Name}}"
  }
}

Aquí, al usar el nombre del contenedor como tag:

  • Podrás revisar rápidamente los logs en tiempo real con journalctl -f | grep {container_name}.
  • También podrás ver solo los logs a partir de un momento específico combinando opciones como --since "10m ago".
  • O incluso filtrar logs de un contenedor en particular usando la opción -t (por tag/identificador), como journalctl -f -t {container_name}.

Si bien puedes ver los logs por unidad, como con journalctl -u docker.service, filtrar por nombre de contenedor es más intuitivo y requiere menos tecleo, lo que lo hace mucho más frecuente en la práctica.

5.3 Relación con Compose / docker run

  • El log-driver + log-opts global actúan como “valores predeterminados”.
  • Si se especifican logging: (Compose) o --log-driver, --log-opt (CLI) en contenedores individuales, solo ese contenedor anulará la configuración global.

Estratégicamente, se recomienda una configuración donde:

  • Los valores comunes residan en daemon.json.
  • Solo los servicios especiales apliquen anulaciones individuales.

6. Configuración principal 3 – Ajustes de red globales: proxy, registros inseguros y más

Hay otras opciones que se utilizan con frecuencia en la configuración global.

6.1 Configuración de proxy

Si el acceso a internet solo es posible a través de un proxy corporativo, en lugar de configurar variables de entorno en cada ocasión, puedes establecer el proxy a nivel del demonio.

{
  "proxies": {
    "http-proxy": "http://proxy.example.com:3128",
    "https-proxy": "http://proxy.example.com:3128",
    "no-proxy": "localhost,127.0.0.1,.corp.example.com"
  }
}

De esta manera, el demonio Docker seguirá esta configuración de proxy al extraer imágenes o al usar la red durante las compilaciones.

6.2 Registro inseguro

Si es absolutamente necesario usar un registro sin TLS (por ejemplo, para desarrollo interno):

{
  "insecure-registries": ["my-registry.local:5000"]
}

Esto puede suponer un riesgo de seguridad, por lo que es crucial utilizarlo solo en entornos de prueba internos.

7. Configuración principal 4 – Rango de red predeterminado, controlador de almacenamiento y más

7.1 Personalización del rango de la red bridge predeterminada

Cuando se desea evitar conflictos de IP con la VPN o la red interna de la empresa:

{
  "default-address-pools": [
    {
      "base": "10.20.0.0/16",
      "size": 24
    }
  ]
}

De esta manera, Docker utilizará el rango 10.20.x.0/24 al crear nuevas redes bridge.

7.2 Forzar el controlador de almacenamiento

El controlador de almacenamiento predeterminado puede variar según la distribución de Linux. Si el equipo ha decidido usar solo overlay2:

{
  "storage-driver": "overlay2"
}

Los controladores de almacenamiento compatibles varían según el sistema operativo y el kernel, por lo que es fundamental consultar la documentación de dockerd y las guías de tu distribución.

8. Si experimentas este 'déjà vu', ¡es hora de implementarlo!

No necesitas ser un experto en infraestructuras complejas. Si recientemente te has encontrado con alguna de estas situaciones, es el momento perfecto para empezar a usar daemon.json.

  • Cada vez que empiezas un nuevo proyecto, te encuentras buscando y copiando/pegando la configuración de logs en docker-compose.yml: Si estás recuperando los ajustes de max-size y max-file de un código anterior para volver a pegarlos, estás desperdiciando un tiempo precioso. Configúralo globalmente una vez y todos tus contenedores se iniciarán automáticamente en modo 'dieta'.
  • Un contenedor que funciona perfectamente en la oficina, pero pierde la conexión a internet en una cafetería o con VPN: Es el típico caso de '¡pero en mi máquina funciona!'. Si quieres que tus contenedores se comuniquen consistentemente con el exterior en cualquier entorno de red, sin depender de la configuración DNS del host, la solución es fijar el DNS globalmente.
  • Te sientes abrumado ajustando la configuración de innumerables nodos de servidor uno por uno: ¿Estás lidiando con 'bugs fantasma' que aparecen por sutiles diferencias en la configuración de Docker entre servidores? Con solo desplegar un archivo daemon.json, todos los servidores funcionarán bajo las mismas reglas.

Si las configuraciones repetitivas te resultan tediosas, o estás cansado de los problemas que surgen con cada cambio de entorno, este es el momento ideal para implementar esta configuración.

Resumen

  • Los valores predeterminados globales de Docker se gestionan en daemon.json.
  • La ubicación habitual es /etc/docker/daemon.json.
  • Ejemplos de configuraciones globales típicas:
    • DNS: "dns": ["1.1.1.1", "8.8.8.8"]
    • Controlador de logs: "log-driver": "json-file", "log-opts": {...}
    • Proxy, registro inseguro, rango de red predeterminado, controlador de almacenamiento…
  • La configuración global es útil para evitar configuraciones repetitivas y al desplegar muchos nodos en diversos entornos.

Si te encuentras utilizando las mismas opciones una y otra vez en docker-compose.yml o docker run, quizás sea el momento de consolidarlas en daemon.json.

Imagen de la configuración de daemon.json de Docker