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

Docker conteneurs utilisant soudainement 192.168.0.0.0/16 au lieu de 172.17.0.0.0/16 : services perdus

Mes applications Docker n'ont soudainement plus pu envoyer de courrier en utilisant l'hôte Postfix MTA. J'ai corrigé cela en spécifiant un pool d'adresses par défaut Docker , mais il est préférable de le faire avant le déploiement.

27 novembre 2019
Dans Docker
post main image
https://unsplash.com/@mmintel

J'ai un serveur ISPConfig avec des applications Docker . Ils utilisent l'agent de transfert de courrier Postfix (MTA) pour livrer le courrier au monde extérieur. Avant d'utiliser la fonction d'envoi de mail, j'ai vérifié si Postfix est accessible. Cela fonctionne très bien. Mais soudain, le courrier n'a pas été envoyé. Le fichier journal contenait des messages d'erreur comme :

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')}

Accès au relais refusé ? Pourquoi ? Puis je me suis souvenu que Postfix a un paramètre mynetworks dans le fichier :

mynetworks  = 127.0.0.0/8 [::1]/128  172.16.0.0/12

Cela m'a conduit aux adresses IP attribuées par Docker aux conteneurs :

systemctl status docker

avec le résultat :

● 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

Les conteneurs Docker utilisaient soudainement le sous-réseau 192 au lieu de 172. Je ne comprends pas (encore) pourquoi cela s'est produit, mais il fallait le résoudre. Après quelques recherches, j'ai trouvé la solution au problème. Cliquez sur le lien ci-dessous :

... par conception, nous avons la gamme de réseaux suivante pour les réseaux de ponts.
"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"
Lorsque nous créons un réseau, nous vérifions s'il n'y a pas de chevauchement à l'intérieur des réseaux créés par les dockers. Nous avons ajouté la prise en charge du pool d'adresses par défaut pour le réseau Bridge. Vous pouvez le configurer via le fichier daemon.jason ou le paramètre d'entrée en démarrant Docker Daemon. De cette façon, vous pouvez choisir le sous-réseau que vous voulez que dockerD crée (passerelle ou réseau par défaut).

J'ai spécifié les pools d'adresses par défaut pour mes réseaux Docker en créant le fichier (il n'était pas là) :

/etc/docker/daemon.json

avec le contenu :

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

Puis j'ai redémarré Docker :

systemctl restart docker

Les conteneurs avaient encore 192 adresses IP de sous-réseau. Puis je l'ai fait pour les applications Docker :

docker-compose  .... down
docker-compose  .... up -d

Maintenant ils avaient à nouveau 172 adresses IP de sous-réseau et le courrier sortait à nouveau ! Pour être sûr, j'ai aussi redémarré le serveur et j'étais content de voir que tout allait bien.

Quelques commandes pour tester

Vous pouvez utiliser cette méthode, voir aussi le lien ci-dessous, pour vérifier si le réseau approprié est créé :

docker network create foo
docker network inspect foo | grep Subnet

D'autres commandes que j'ai utilisées dans le processus :

route -n

docker inspect <container> 

docker network ls

docker network inspect <network>

Résumé

Je ne sais toujours pas ce qui a causé ce problème mais heureusement vous pouvez spécifier un sous-réseau pour le réseau par défaut. Ceci devrait vraiment être plus accentué quand vous commencez à utiliser Docker ! Vous pouvez aussi spécifier des sous-réseaux par défaut dans docker-compose mais je n'ai pas testé cela. Quoi qu'il en soit, c'est résolu.

Liens / crédits

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

En savoir plus...

Docker

Laissez un commentaire

Commentez anonymement ou connectez-vous pour commenter.

Commentaires

Laissez une réponse

Répondez de manière anonyme ou connectez-vous pour répondre.