Docker Bridge en conflit avec le réseau hôte
Docker semble créer un pont après le démarrage d'un conteneur qui entre en conflit avec mon réseau hôte. Il ne s'agit pas du pont docker0 par défaut, mais plutôt d'un autre pont créé après le démarrage d'un conteneur. Je peux configurer le pont par défaut selon l'ancien lien du guide de l'utilisateur https://docs.docker.com/v17.09/engine/userguide/networking/default_network/custom-docker0/ , cependant , Je ne sais pas comment configurer cet autre pont pour qu'il n'entre pas en conflit avec 172.17.
Ce problème actuel est alors que mon conteneur ne peut pas accéder à d'autres systèmes sur le réseau hôte lorsque ce pont devient actif.
Des idées?
Version de docker:
Version 18.03.1-ce-mac65 (24312)
C'est le pont qui se crée. Parfois ce n'est pas 172.17, mais parfois c'est le cas.
br-f7b50f41d024 Link encap:Ethernet HWaddr 02:42:7D:1B:05:A3
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
Lorsque des réseaux de dockers sont créés (par exemple en utilisant docker network create ou indirectement via docker-compose) sans spécifier explicitement une plage de sous-réseaux, dockerd alloue un nouveau /16 réseau, à partir de 172.N.0.0/16, où N est un nombre incrémenté (par exemple N = 17, N = 18, N = 19, N = 20, ...). Un N donné est ignoré s'il y a déjà un réseau docker dans la plage: soit un réseau docker personnalisé, soit le pont docker par défaut.
Lors de la création d'un nouveau réseau de pont, vous pourrait spécifier explicitement la plage IP à utiliser pour éviter le conflit. Malheureusement, cela nécessiterait de modifier chaque fichier docker-compose.yaml que vous rencontrez - pour fournir explicitement un bloc IP sûr. Généralement, on voudrait éviter d'inclure des choses spécifiques à l'hôte dans les fichiers de composition.
Au lieu de cela, vous pouvez jouer avec les réseaux que Docker considère comme alloués. Je décris 3 méthodes ci-dessous, qui devraient vous permettre de forcer dockerd à "ignorer" les sous-réseaux.
Méthode # 1 - créer un réseau fictif d'espace réservé
Vous pouvez empêcher la totalité de 172.17.0.0/16 d'être utilisé par dockerd (dans les futurs réseaux de ponts) en créant un très petit réseau docker n'importe où à l'intérieur 172.17.0.0/16.
Trouvez 4 adresses IP consécutives dans 172.17.* dont vous savez qu'ils ne sont pas utilisés dans votre réseau hôte, et sacrifiez-les dans un ponton "tombstone". Ci-dessous, je suppose que l'ips 172.17.253.0, 172.17.253.1, 172.17.253.2, 172.17.253.3 (c'est à dire. 172.17.253.0/30) ne sont pas utilisés dans votre réseau hôte.
docker network create --driver=bridge --subnet 172.17.253.0/30 tombstone
# created: c48327b0443dc67d1b727da3385e433fdfd8710ce1cc3afd44ed820d3ae009f5
Noter la /30 suffixe ici, qui est 4 IP différentes. En théorie, le plus petit sous-réseau valide doit être un /31 qui se compose d'un total de 2 IP (identifiant réseau + diffusion). Docker demande un /30 minimum, probablement pour tenir compte d'un hôte de passerelle et d'un autre conteneur. J'ai choisi .253.0 arbitrairement, vous devez choisir quelque chose qui n'est pas utilisé dans votre environnement. Notez également que l'identifiant tombstone n'a rien de spécial, vous pouvez le renommer en tout ce qui vous aidera à vous rappeler pourquoi il est là lorsque vous le retrouverez plusieurs mois plus tard.
Si vous regardez votre table de routage, vous verrez l'entrée pour le nouveau pont:
# output of route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.5.1 0.0.0.0 UG 0 0 0 eth1
172.17.253.0 0.0.0.0 255.255.255.252 U 0 0 0 br-c48327b0443d
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Remarque: Mon pont Docker est sur 172.20.0.1 dans ma configuration. J'ai modifié bip dans /etc/docker/daemon.json pour ce faire. Voir cette page pour plus de détails.
Maintenant, si nous créons de nouveaux réseaux de dockers, nous pouvons voir que le reste de 172.17.0.0/16 est ignoré, car la plage n'est pas entièrement disponible.
docker network create foo_test
# c9e1b01f70032b1eff08e48bac1d5e2039fdc009635bfe8ef1fd4ca60a6af143
docker network create bar_test
# 7ad5611bfa07bda462740c1dd00c5007a934b7fc77414b529d0ec2613924cc57
La table de routage résultante:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.5.1 0.0.0.0 UG 0 0 0 eth1
172.17.253.0 0.0.0.0 255.255.255.252 U 0 0 0 br-c48327b0443d
172.18.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-c9e1b01f7003
172.19.0.0 0.0.0.0 255.255.0.0 U 0 0 0 br-7ad5611bfa07
172.20.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Notez que le reste des adresses IP dans 172.17.0.0/16 n'ont pas été utilisés. Les nouveaux réseaux réservés .18. et .19.. L'envoi de trafic vers l'une de vos adresses IP en conflit en dehors de ce réseau tombstone passerait par votre réseau hôte.
Vous devez conserver ce réseau de base dans Docker, mais ne pas l'utiliser dans vos conteneurs. C'est un faux réseau d'espaces réservés.
Méthode # 2 - faire tomber le réseau de ponts en conflit
Si vous souhaitez éviter temporairement le conflit IP, vous pouvez arrêter le pont Docker en conflit à l'aide de ip link: ip link set dev br-xxxxxxx down. Cela aura pour effet de supprimer l'entrée de routage de pont correspondante dans la table de routage, sans modifier aucune des métadonnées de docker.
Ce n'est sans doute pas aussi bon que la méthode ci-dessus, car vous devrez peut-être désactiver l'interface à chaque démarrage de dockerd, et cela interférerait avec la mise en réseau de vos conteneurs s'il y avait un conteneur utilisant ce pont.
Si la méthode 1 cesse de fonctionner à l'avenir (par exemple parce que le docker essaie d'être plus intelligent et de réutiliser les parties inutilisées d'un bloc ip), vous pouvez combiner les deux approches: par exemple créer un grand réseau de pierre tombale avec l'ensemble /16, ne l'utilisez dans aucun conteneur, puis arrêtez son périphérique br-x correspondant.
Méthode # 3 - reconfigurez votre docker bridge pour occuper une sous-partie du conflit/16
Comme légère variation de ce qui précède, vous pouvez faire chevaucher le pont Docker par défaut avec une région de 172.17.*.* qui n'est pas utilisé dans votre réseau hôte. Vous pouvez modifier le sous-réseau du pont Docker par défaut en modifiant l'adresse IP du pont (c'est-à-dire la clé bip) dans /etc/docker/daemon.json (Voir cette page pour plus de détails). Faites-en simplement une sous-région de votre/16, par ex. en a/24 ou plus petit.
Je n'ai pas testé cela, mais je présume que tout nouveau réseau docker ignorerait le reste de 172.17.0.0/16 et allouer un tout autre /16 pour chaque nouveau pont.
Pour l'avenir:
Je cherchais un moyen de configurer dockerd avec une plage IP de départ différente pour les nouveaux ponts réseau, mais je n'ai rien trouvé (à partir de la version 1.13.1). Espérons que cela change à l'avenir. Être en mesure de spécifier des plages d'adresses IP à exclure semble être une chose valide à vouloir.
Le pont a été créé à partir de docker-compose, qui peut être configuré dans le fichier de composition.
Réponse trouvée ici: Docker crée deux ponts qui corrompt mon accès Internet