Unificar el entorno de desarrollo con la configuración global del demonio Docker

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

Ya sea que trabajes localmente o en un servidor, al usar Docker a menudo terminamos copiando y pegando la misma configuración en el docker-compose.yml de cada proyecto.

• Configurar siempre los DNS a 1.1.1.1, 8.8.8.8
• Fijar el driver de logs a json-file + max-size=10m
• Proxy, registro inseguro, rango de red por defecto, etc.

Estos ajustes son mucho más fáciles de manejar si los sacas de la configuración individual de cada contenedor y los colocas como valores por defecto de todo el host. El responsable de esto es la configuración global del demonio Docker (daemon.json).

En lo que sigue:

• ¿Qué archivo usar?
• ¿Dónde colocarlo?
• ¿Cómo escribirlo?
• ¿Para quién y en qué situaciones es útil?

1. Dos formas de configurar el demonio Docker

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

1. Archivo JSON (daemon.json) ← recomendado
2. Bandera de línea de comandos al iniciar dockerd

Se pueden mezclar, pero si la misma opción se define en ambos lugares, el demonio no arrancará. Por ejemplo, si se especifica --log-driver tanto en la bandera como en daemon.json, Docker fallará al iniciar.

Para lograr una coherencia en el entorno del equipo o del servidor, normalmente se recomienda:

“Reúne la mayor parte de la configuración en daemon.json y limita el uso de banderas”.

2. Ubicación de daemon.json

A continuación se muestra una tabla con las ubicaciones por defecto según el sistema operativo y el método de instalación:

• Este archivo puede no existir por defecto; si no está, simplemente créalo.
• Cuando se trata de estándares de equipo/servidor, la práctica habitual es usar la ruta de Linux /etc/docker/daemon.json.

3. Patrón típico: “Crear archivo → Reiniciar demonio”

En Linux, el flujo de trabajo más frecuente es el siguiente:

1. Crear o editar daemon.json

{
  "dns": ["1.1.1.1", "8.8.8.8"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

2. Validar la sintaxis

sudo dockerd --validate --config-file=/etc/docker/daemon.json
# Si aparece "configuration OK" significa que está bien

3. Reiniciar el demonio

sudo systemctl restart docker

A partir de ahora, cualquier contenedor nuevo heredará estos valores por defecto a menos que se especifique lo contrario.

4. Ejemplo 1 – Fijar servidores DNS globalmente

4.1 ¿Por qué DNS global?

Si los contenedores tienen problemas como “no puede encontrar API externa” o “no resuelve dominios internos”, suele deberse a la configuración de DNS del host.

Ejemplos:

• Todo el equipo quiere usar Cloudflare DNS (1.1.1.1)
• Hay endpoints que solo se resuelven a través del DNS interno de la empresa

En lugar de añadir dns: en cada docker-compose.yml, es más sencillo establecerlo a nivel del demonio.

4.2 Configuración (daemon.json)

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

Si ya existe un daemon.json, simplemente añade la clave "dns": [...] dentro del objeto raíz.

⚠️ Importante: La configuración de DNS se refleja en /etc/resolv.conf dentro del contenedor. No afecta a contenedores ya en ejecución; solo a los nuevos.

4.3 ¿Para quién es útil?

• Desarrolladores con proxy interno o DNS corporativo
• Equipos que operan en entornos multi‑cloud y necesitan un DNS fijo
• Desarrolladores locales que cambian entre VPNs

5. Ejemplo 2 – Driver de logs y opciones globales

Los logs de los contenedores se guardan por defecto con el driver json-file en /var/lib/docker/containers/.... Cambiarlos globalmente permite aplicar una política de logs a todos los contenedores.

5.1 Driver json-file con rotación

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

Con esto:

• Cada archivo de log no excederá 10 MB
• Se mantendrán hasta 5 archivos por contenedor
• Los archivos antiguos se eliminarán automáticamente

5.2 Driver para recolección centralizada (fluentd, journald, etc.)

Para equipos que envían logs a un sistema central, por ejemplo Fluentd:

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

Con esto, sin necesidad de docker run --log-driver=..., todos los contenedores enviarán logs a Fluentd.

El driver journald también es una opción popular en entornos basados en systemd, ya que permite centralizar los logs de la aplicación y de Docker en un solo lugar.

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

Con journald puedes usar journalctl -t {container_name} para ver logs en tiempo real.

5.3 Relación con Compose / docker run

• El driver y las opciones globales actúan como valores por defecto.
• Si un contenedor especifica logging: (Compose) o --log-driver/--log-opt (CLI), esos valores sobrescribirán la configuración global.

Estrategia recomendada: Define los valores comunes en daemon.json y solo sobrescribe cuando sea necesario.

6. Ejemplo 3 – Proxy, registro inseguro y otras configuraciones de red

6.1 Proxy

Para entornos que solo pueden salir a Internet a través de un proxy interno:

{
  "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"
  }
}

Con esto, Docker usará el proxy al descargar imágenes o al construir.

6.2 Registro inseguro

Si necesitas usar un registro sin TLS (por ejemplo, un registro interno de desarrollo):

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

Usar esto con precaución; solo en entornos de prueba.

7. Ejemplo 4 – Rango de red por defecto, driver de almacenamiento, etc.

7.1 Rango de red por defecto

Para evitar colisiones con VPN o redes internas:

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

Esto hace que Docker use 10.20.x.0/24 para nuevas redes bridge.

7.2 Driver de almacenamiento

Si el equipo decide usar exclusivamente overlay2:

{
  "storage-driver": "overlay2"
}

Verifica la compatibilidad con tu sistema operativo y kernel.

8. ¿Para quién y cuándo es especialmente útil?

8.1 Desarrollador individual

• Usa los mismos ajustes en varios proyectos
• Cambia frecuentemente VPN o proxy
• Necesita gestionar logs y espacio en disco de forma sencilla

Con un solo daemon.json, puedes unificar el entorno y eliminar configuraciones repetitivas.

8.2 Equipos pequeños/medianos

• Evitar que “funciona en mi máquina” sea un problema
• Alinear configuraciones de CI con las de los desarrolladores locales
• Imponer DNS, proxy y registros internos de forma consistente

Definir un estándar en daemon.json y distribuirlo con Ansible, Chef, Terraform o Cloud‑Init simplifica la adopción.

8.3 Equipos de plataforma / DevOps / SRE

• Gestionar cientos de contenedores con políticas de logs, almacenamiento y red coherentes
• Centralizar la recolección de logs y la monitorización
• Establecer políticas de seguridad a nivel de host

En estos casos, daemon.json se convierte en el archivo de política del nodo Docker.

9. Consejos de depuración

1. Bandera vs. daemon.json - Revisa el archivo de unidad de systemd (/lib/systemd/system/docker.service) para ver si ya hay --log-driver u otras opciones. - Si la misma opción aparece en la bandera y en daemon.json, el demonio fallará.
2. Docker Desktop - La GUI de Docker Desktop modifica internamente ~/.docker/daemon.json. - Evita editar el archivo manualmente y luego usar la UI, ya que la UI puede sobrescribir tus cambios.

Resumen

• La configuración global de Docker se gestiona con daemon.json.
• Ubicaciones típicas: /etc/docker/daemon.json (Linux), C:\ProgramData\Docker\config\daemon.json (Windows), ~/.docker/daemon.json (Docker Desktop).
• Ejemplos comunes: DNS, driver de logs, proxy, registro inseguro, rango de red, driver de almacenamiento.
• Usar daemon.json aporta comodidad a desarrolladores individuales y coherencia a equipos y plataformas.
• Si ya estás añadiendo las mismas opciones en docker-compose.yml o docker run, considera migrar a daemon.json.