Docker contenedores que de repente utilizan 192.168.0.0.0/16 en lugar de 172.17.0.0/16: servicios perdidos
Mis aplicaciones Docker de repente no pudieron enviar correo utilizando el host Postfix MTA. Arreglé esto especificando un grupo de direcciones por defecto Docker , pero es mejor hacerlo antes de la implementación.
Tengo un servidor ISPConfig con aplicaciones Docker . Utilizan el agente de transferencia de correo del host Postfix (MTA) para entregar el correo al mundo exterior. Antes de utilizar la función de envío de correo tengo que comprobar si se puede acceder a Postfix . Esto funciona bien. Pero de repente no se envió el correo. El archivo de registro contenía mensajes de error como:
2019-11-26 17:31:56,758 ERROR MailMessage - send_mail: self.error_message = sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR MailSend - send during send, errors = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
2019-11-26 17:31:56,759 ERROR AddonContactForm - send_contact_form: mail_sender.get_errors() = send - sending message, e = {'joe@example.com': (554, b'5.7.1 <joe@example.com>: Relay access denied')}
¿Relevo de acceso denegado? Por qué? Entonces recordé que Postfix tiene un parámetro mynetworks en el archivo:
mynetworks = 127.0.0.0/8 [::1]/128 172.16.0.0/12
Esto me llevó a las direcciones IP asignadas por Docker a los contenedores:
systemctl status docker
con resultado:
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2019-10-16 21:26:07 CEST; 1 months 11 days ago
Docs: https://docs.docker.com
Main PID: 765 (dockerd)
Tasks: 28
Memory: 53.7M
CPU: 39min 54.387s
CGroup: /system.slice/docker.service
├─ 765 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
├─ 9784 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8001 -container-ip 192.168.32.2 -container-port 8001
└─18316 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8000 -container-ip 192.168.176.2 -container-port 8000
Los contenedores Docker de repente estaban utilizando la subred 192 en lugar de la subred 172. Yo (todavía) no entiendo por qué sucedió esto, pero tenía que ser resuelto. Después de algunas búsquedas encontré la solución para el problema. Desde el enlace de abajo:
... por diseño tenemos la siguiente gama de redes para redes de puentes.
"172.17.0.0/16", "172.18.0.0/16", "172.19.0.0/16", "172.20.0.0/14", "172.24.0.0/14" "172.28.0.0/14", "192.168.0.0/16"
Cuando creamos una red, comprobamos si la red está sobrecargada sólo dentro de las redes creadas por el acoplador. Hemos añadido soporte de grupo de direcciones por defecto para la red de bridge. Se puede configurar a través del archivo daemon.jason o del parámetro de entrada al iniciar el demonio Docker . De esta manera puede elegir la subred que desea que dockerD cree (pasarela o red por defecto).
He especificado los grupos de direcciones predeterminados para mis redes Docker creando el archivo (no estaba allí):
/etc/docker/daemon.json
con el contenido:
{
"default-address-pools":
[
{"base":"172.17.0.0/16","size":24}
]
}
Luego reinicié Docker:
systemctl restart docker
Los contenedores aún tenían 192 direcciones IP de subred. Luego lo hice para las aplicaciones Docker :
docker-compose .... down
docker-compose .... up -d
Ahora tenían 172 direcciones IP de subred otra vez y el correo estaba saliendo de nuevo! Para asegurarme, también reinicié el servidor y me alegró ver que todo estaba bien.
Algunos comandos para probar
Puede utilizar este método, véase también el enlace de abajo, para comprobar si se ha creado la red adecuada:
docker network create foo
docker network inspect foo | grep Subnet
Algunos otros comandos que utilicé en el proceso:
route -n
docker inspect <container>
docker network ls
docker network inspect <network>
Resumen
Todavía no sé qué causó este problema, pero afortunadamente se puede especificar una subred para la red por defecto. Esto realmente debería ser más enfatizado cuando empiece a usar Docker! También puede especificar subredes por defecto en docker-compose pero no lo he probado. De todos modos, resuelto.
Enlaces / créditos
Allow user to specify default address pools for docker networks #29376
https://github.com/moby/moby/pull/29376
Configuring Docker to not use the 172.17.0.0 range
https://serverfault.com/questions/916941/configuring-docker-to-not-use-the-172-17-0-0-range
Docker (compose?) suddenly creates bridge using 192.168.16.0/20 range #37823
https://github.com/moby/moby/issues/37823
How does compose chooses subnet for default network? #4336
https://github.com/docker/compose/issues/4336
networks
https://docs.docker.com/compose/compose-file/#networks
Leer más
Docker
Recientes
- Cómo ocultar las claves primarias de la base de datos UUID de su aplicación web
- Don't Repeat Yourself (DRY) con Jinja2
- SQLAlchemy, PostgreSQL, número máximo de filas por user
- Mostrar los valores en filtros dinámicos SQLAlchemy
- Transferencia de datos segura con cifrado de Public Key y pyNaCl
- rqlite: una alternativa de alta disponibilidad y dist distribuida SQLite
Más vistos
- Usando Python's pyOpenSSL para verificar los certificados SSL descargados de un host
- Usando UUIDs en lugar de Integer Autoincrement Primary Keys con SQLAlchemy y MariaDb
- Usando PyInstaller y Cython para crear un ejecutable de Python
- Conectarse a un servicio en un host Docker desde un contenedor Docker
- SQLAlchemy: Uso de Cascade Deletes para eliminar objetos relacionados
- Flask RESTful API validación de parámetros de solicitud con esquemas Marshmallow