Когда создаются сети Docker (например, с использованием docker network create или косвенно через docker-compose) без явного указания диапазона подсети, dockerd выделяет новую сеть /16, начиная с 172.N.0.0/16, где N - это числоэто увеличивается (например, N = 17, N = 18, N = 19, N = 20, ...).Заданное значение N пропускается, если в диапазоне уже есть докерская сеть: либо настраиваемая докерная сеть, либо док-мост по умолчанию.
При создании новой мостовой сети вы могли бы явно указать диапазон IP-адресов, который следует использовать, чтобы избежать конфликта.К сожалению, для этого потребуется изменить каждый файл docker-compose.yaml, с которым вы столкнетесь, - чтобы явно предоставить безопасный блок ip.Как правило, было бы желательно избегать включения специфичных для хоста вещей в файлы компоновки.
Вместо этого вы можете играть с сетями, которые Docker считает выделенными.Ниже я опишу 3 метода, которые позволят вам заставить dockerd «пропускать» подсети.
Метод № 1 - создание фиктивной сети-заполнителя
Вы можете предотвратить использование dockerd (* в будущих мостовых сетях) всего 172.17.0.0/16, создавочень маленькая сеть докеров где-нибудь внутри 172.17.0.0/16.
Найдите 4 последовательных IP-адреса в 172.17.*, которые, как вы знаете, не используются в вашей хост-сети, и пожертвуйте их в виде "надгробного" моста докера.Ниже я предполагаю, что ips 172.17.253.0, 172.17.253.1, 172.17.253.2, 172.17.253.3 (т.е. 172.17.253.0/30) не используются в вашей хост-сети.
docker network create --driver=bridge --subnet 172.17.253.0/30 tombstone
# created: c48327b0443dc67d1b727da3385e433fdfd8710ce1cc3afd44ed820d3ae009f5
Обратите внимание на /30суффикс здесь, который 4 разных IP.Теоретически, наименьшей допустимой сетевой подсетью должна быть /31, которая состоит из 2 IP-адресов (идентификатор сети + широковещательная рассылка).Docker запрашивает минимум /30, возможно, для учета хоста шлюза и другого контейнера.Я выбрал .253.0 произвольно, вы должны выбрать что-то, что не используется в вашей среде.Также обратите внимание, что идентификатор tombstone не является чем-то особенным, вы можете переименовать его во что угодно, что поможет вам вспомнить, почему оно есть, когда вы снова найдете его несколько месяцев спустя.
Если вы посмотрите на свою таблицу маршрутизации, выувидит запись для нового моста:
# 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
Примечание: мой докерский мост на 172.20.0.1 в моей настройке.Для этого я изменил bip в /etc/docker/daemon.json.См. эту страницу для получения более подробной информации.
Теперь, если мы создадим новые докерские сети, мы увидим, что оставшаяся часть 172.17.0.0/16 пропущена, поскольку диапазон не полностьюдоступно.
docker network create foo_test
# c9e1b01f70032b1eff08e48bac1d5e2039fdc009635bfe8ef1fd4ca60a6af143
docker network create bar_test
# 7ad5611bfa07bda462740c1dd00c5007a934b7fc77414b529d0ec2613924cc57
Полученная таблица маршрутизации:
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
Обратите внимание, что остальные IP-адреса в 172.17.0.0/16 не были использованы.Новые сети защищены .18. и .19..Отправка трафика на любой из ваших конфликтующих IP-адресов за пределами этой сети-захоронения будет проходить через вашу хост-сеть.
Вам придется хранить эту сеть-захоронение в докере, но не использовать ее в своих контейнерах.Это фиктивная сеть-заполнитель.
Метод № 2 - отключить конфликтующую мостовую сеть
Если вы хотите временно избежать конфликта IP-адресов, вы можете привести конфликтующийдокерский мост с использованием ip link: ip link set dev br-xxxxxxx down.Это приведет к удалению соответствующей записи маршрутизации моста в таблице маршрутизации без изменения каких-либо метаданных докера.
Возможно, это не так хорошо, как описанный выше метод, потому что вам придется отключитьинтерфейс, возможно, каждый раз, когда запускается dockerd, и он будет мешать работе вашего контейнера, если какой-либо контейнер будет использовать этот мост.
Если метод 1 перестанет работать в будущем (например, потому что docker пытается быть умнее и повторно использовать неиспользуемыйчасти блока ip), вы можете объединить оба подхода: например, создать большую сеть надгробий со всем /16, не использовать ее в каком-либо контейнере, а затем отключить соответствующее устройство br-x.
Метод № 3 - перенастроить ваш докерский мост так, чтобы он занимал часть конфликтующего / 16
В качестве небольшого изменения вышеприведенного, вы можете сделать перекрывающий мост по умолчанию перекрывающимся с областью 172.17.*.*, которая не используется в вашей хост-сети.Вы можете изменить подсеть стыковочного моста по умолчанию, изменив IP-адрес моста (т. Е. Ключ bip) в /etc/docker/daemon.json (подробнее см. на этой странице ).Просто сделайте его субрегионом вашего / 16, например, в / 24 или меньше.
Я не проверял это, но я предполагаю, что любая новая сеть докеров пропустит оставшуюся часть 172.17.0.0/16 и выделит полностьюразные /16 для каждого нового моста.
На будущее:
Я искал способ настроить dockerd с другим начальным диапазоном IP для новых сетевых мостов, но ничего не смог найти (начиная с версии 1.13.1).Надеюсь, что это изменится в будущем.Возможность указать диапазоны IP-адресов, которые нужно исключить, кажется приемлемой.