Synology Plus de possibilité de créer de projet, saturation de bridge?

patronize

Chevalier Jedi
Membre Confirmé
30 Octobre 2021
242
62
78
Bonjour,
J’expérimente beaucoup docker, à force d’accumule beaucoup de container, quand je crée un nouveau projet j’ai un message d’erreur au niveau du réseau (fenêtre manager container).
Pour y remédier je vois l’intégrer dans d’autre projet pour ne pas avoir de message d’erreur bloquant.

Pour le parefeu de synology j’utilise les fameuses 3 règles l’une pour docker, l’une pour le reverse proxy (80,443) et l’autre je bloque tout.

Je me pencherai pour une limitation dans la règle du parefeu de la 1ere.

modèle: DS1621+
DSM 7.2 (la dernière en date)
 
  • J'aime
Réactions: sypqys
Bonjour, quel est exactement le problème ?
Normalement dans le pare-feu tu peux mettre aussi une règle qui autorise tout sur le réseau local ( avant celle qui bloque tout)

Le pare-feu feu ne devrait pas t'empêcher de créer des Dockers.

Poste nous une capture d'écran du message d'erreur.
 
J’ai 30 bridge et 1 host après ça j’ai ce type de message si j’en rajoute un de plus.
Could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network
 
Je dirais que ça serait plus une limitation de dsm qui ne gère pas plus de 32 Vlan, mais rien d'indiquer sur la fiche technique de ton NAS.
 
le bridge doit avoir un masque sous réseau de 16 (172.17.0.0/16) ce qui fait que l'on peut utiliser les adresses de :

Adresse IPv4
CIDR
: 16
Masque de réseau : 255.255.0.0
Masque inverse : 0.0.255.255

En mode réseau :
Adresse de réseau
: 172.17.0.0
Première adresse : 172.17.0.1
Dernière adresse : 172.17.255.254
Adresse de broadcast : 172.17.255.255
Nombre d'adresses IP disponibles : 65534

En mode filtre :
Première adresse
: 172.17.0.0
Dernière adresse : 172.17.255.255
Nombre d'adresses IP disponibles : 65536



conclusion, vous devez avoir la même adresse ip avec deux paquet de docker différent, à vérifier de ce coté
 
@bliz, comment tu définis son IP et sous réseau?


Je me fais un tableau avec tous les containers pour voir lequel et sen conflit.
dès que je peux je vous fait un retour
 
Perso je crée les réseaux docker via le fichier docker compose.
Et moi aussi je tiens une liste de tous les réseaux docker créés et pour quel conteneur/stack.
 
  • J'aime
Réactions: sypqys
J’ai 30 bridge et 1 host après ça j’ai ce type de message si j’en rajoute un de plus.
Si c'est toujours comme sur DSM6, un bridge créer automatiquement via Docker DSM va se prendre une grosse plage d'adresse IP ( un gros "masque" ) et donc tu arrive vite a saturation.

Vérifie les masques de tes bridges.
 
comment tu définis son IP et sous réseau?
de quel ip tu parle de ceci :

lf5o.jpg


ou de celle-ci

cn77.jpg


vérifie aussi qu'il n'y ait pas les même ports ouvert sur différents container, je commencerais par là

édit : pour la saturation, tu ne sera pas saturé avant au moins 255 réseau créé, donc de ce côté, je ne pense pas que le problème viennent de là, mais pense plutôt à réunir tes réseau et supprimer ceux qui ne servent pas
 
Oui :
1693123140562.png

Ici on voit que tu as un bridge avec un masque en /16

Cela veut dire, que sur ce bridge, tu peux avoir des conteneurs avec l'ip de 172.17.0.1 a 172.17.255.254
Mais cela veut dire aussi que toutes ses IPs ne sont pas utilisable pour créer un autre bridge :)

Personnellement, je créer mes bridge avec un masque en /24, cela donne 254 possibilités d'ip dans un bridge, largement suffisant.
 
Dernière édition:
en même temps, le réseau privé de cette adresse en 172 est 172.16.0.0/12 soit 1 048 576 d'adresses :
En mode filtre :
Première adresse
: 172.16.0.0
Dernière adresse : 172.31.255.255

ce qui fait en configuration par défaut environ 16 containers

Message automatiquement fusionné :

PréfixePlage IPNombre d'adresses
10.0.0.0/8​
10.0.0.0 – 10.255.255.255​
232-8 = 16 777 216​
172.16.0.0/12​
172.16.0.0 – 172.31.255.255​
232-12 = 1 048 576​
192.168.0.0/16​
192.168.0.0 – 192.168.255.255​
232-16 = 65 536​
 
vérifier aussi les ports utilisés qui ne soient pas en double.

sinon, conseille, si vous le pouvez, réunissez les plusieurs contenairs dans un ou plisieurs brige, mais limitez vos bridges
 
sinon, conseille, si vous le pouvez, réunissez les plusieurs contenairs dans un ou plisieurs brige, mais limitez vos bridges
C'est un peu contraire a la politique Docker, dont le but est l'isolation des conteneurs :D Personnelemnet j'ai 1 bridge / conteneurs ou 1 bridge par "services". Une service étant plusieurs conteneurs dépendant l'un de l'autre ( par exemple nextcloud + mariadb )
 
on peut en réunir certains, par exemple un logiciel de téléchargement et wireshark par exemple, cela permet de surveiller le réseau pour ce container, mais de préférence, ce genr ede sniffer se met dans host pour récupérer tout le traffic. Tout dépend comment on s'en sert.

Par exemple, dans le même contexte, cela ne me dérange pas de mettre openspeedtest avec le container speedtest.

Mais ta solution de restreindre un peut plus le masque est une très bonne solution, cela dépend de ce que l'on veut ;)