angle-uparrow-clockwisearrow-counterclockwisearrow-down-uparrow-leftatcalendarcard-listchatcheckenvelopefolderhouseinfo-circlepencilpeoplepersonperson-fillperson-plusphoneplusquestion-circlesearchtagtrashx

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.

27 noviembre 2019
En Docker
post main image
https://unsplash.com/@mmintel

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

Deje un comentario

Comente de forma anónima o inicie sesión para comentar.

Comentarios

Deje una respuesta.

Responda de forma anónima o inicie sesión para responder.