Ответ 1

EDIT: Это решение теперь бесполезно. Начиная с версии 1.12, Docker предоставляет два сетевых драйвера: macvlan и ipvlan. Они позволяют назначать статический IP-адрес из локальной сети. См. Ниже .

После поиска людей, которые имеют одинаковую проблему, мы перешли к обходному пути:

Сумма:

• (V) LAN - 192.168.1.0/24
• Шлюз по умолчанию (= маршрутизатор) - 192.168.1.1
• Несколько хостов докеров
• Примечание. У нас есть два сетевых адаптера: eth0 и eth1 (который посвящен Docker).

Что нам нужно:

Мы хотим иметь контейнеры с ip в сети 192.168.1.0/24 (например, компьютеры) без каких-либо NAT/PAT/translation/port-forwarding/etc...

Проблема

При этом:

network create --subnet 192.168.1.0/24 --gateway 192.168.1.1 homenet

мы можем предоставить контейнеры для IP-адреса, который мы хотим, , но. Мост, созданный docker (br-[a-z0-9]+), будет иметь IP 192.168.1.1, который является нашим маршрутизатором.

Решение

1. Настройка сети Docker

Используйте параметр DefaultGatewayIPv4:

docker network create --subnet 192.168.1.0/24 --aux-address "DefaultGatewayIPv4=192.168.1.1" homenet

По умолчанию Docker предоставит интерфейсу моста (br-[a-z0-9]+) первый IP-адрес, который может быть уже занят другой машиной. Решение заключается в использовании параметра --gateway, чтобы сообщить докеру назначить произвольный IP-адрес (который доступен):

docker network create --subnet 192.168.1.0/24 --aux-address "DefaultGatewayIPv4=192.168.1.1" --gateway=192.168.1.200 homenet

Мы можем указать имя моста, добавив -o com.docker.network.bridge.name=br-home-net к предыдущей команде.

2. Мостовой мост!

Теперь у нас есть мост (br-[a-z0-9]+), созданный Docker. Нам нужно подключить его к физическому интерфейсу (в моем случае у меня есть NIC, поэтому я использую eth1 для этого):

brctl addif br-home-net eth1

3. Удалить мост IP

Теперь мы можем удалить IP-адрес с моста, поскольку нам не нужен он:

ip a del 192.168.1.200/24 dev br-home-net

IP 192.168.1.200 может использоваться как мост на множестве узлов докеров, поскольку мы его не используем, и мы удаляем его.

Ответ 2

Использовать официальный драйвер Docker:

Начиная с Docker v1.12.0-rc2, новый драйвер MACVLAN теперь доступен в официальной версии Docker:

• Драйвер MacVlan вышел из экспериментального # 23524

Эти новые драйверы были хорошо документированы авторами (-ами) с примерами использования.

В конце дня он должен обеспечивать аналогичную функциональность, быть проще в настройке и с меньшим количеством ошибок/других причуд.

Просмотр контейнеров на хосте Docker:

Только оговорка с новым официальным драйвером macvlan заключается в том, что хост-компьютер докера не может видеть/связываться с его собственными контейнерами. Что может быть желательно или нет, в зависимости от вашей конкретной ситуации.

Эта проблема может быть решена, если у вас более 1 сетевой адаптер на хост-машине докера. И оба сетевых адаптера подключены к вашей локальной сети. Затем можно либо A) выделить 1 из ваших докеров-хостов 2 nics для эксклюзивного докера. И используйте оставшийся nic для хоста для доступа к локальной сети.

Или B), добавив определенные маршруты только к тем контейнерам, которые вам нужно получить через 2-й сетевой адаптер. Например:

sudo route add -host $container_ip gw $lan_router_ip $if_device_nic2

Метод A) полезен, если вы хотите получить доступ ко всем вашим контейнерам с хоста докеров и у вас есть несколько проводных ссылок.

Wheras method B) полезен, если вам нужен только доступ к нескольким конкретным контейнерам с хоста docker. Или, если ваша вторая сетевая карта является Wi-Fi-картой и будет намного медленнее для обработки всего вашего сетевого трафика. Например, на портативном компьютере.

Установка:

Если не удается просмотреть предварительный выпуск -rc2 кандидата на ubuntu 16.04, временно добавьте или измените эту строку на ваш /etc/apt/sources.list, чтобы сказать:

deb https://apt.dockerproject.org/repo ubuntu-xenial testing

вместо main (который является стабильным выпуском).

Ответ 3

Теперь Docker поддерживает сетевые драйверы Macvlan и IPvlan. Документацию Docker для обоих сетевых драйверов можно найти здесь.

С обоими драйверами вы можете реализовать желаемый сценарий (настройте контейнер, чтобы он вел себя как виртуальная машина в режиме моста):

• Macvlan: позволяет одному физическому сетевому интерфейсу (мастер-устройству) иметь произвольное количество подчиненных устройств, каждое из которых имеет собственные MAC-адреса.

  Требуется ядро ​​Linux v3.9-3.19 или 4.0 +.

• IPvlan. Позволяет создать произвольное количество подчиненных устройств для вашего основного устройства, все из которых имеют один и тот же MAC-адрес.

  Требуется Linux kernel v4.2 + (поддержка предыдущих ядер существует, но является ошибкой).

  Подробнее см. kernel.org IPVLAN Driver HOWTO.

Контейнерное соединение достигается путем помещения одного из подчиненных устройств в пространство имен сети для сконфигурированного контейнера. Ведущие устройства остаются в операционной системе хоста (пространство имен по умолчанию).

Как правило, вы должны использовать драйвер IPvlan, если хост Linux, подключенный к внешнему коммутатору/маршрутизатору, имеет настроенную политику, которая позволяет использовать только один MAC на порт. Это часто случается в средах VMWare ESXi!

Еще одна важная вещь для запоминания (Macvlan и IPvlan): Трафик на ведущее устройство и с него не может быть отправлен на подчиненные устройства и с него. Если вам нужно включить связь между ведущими и ведомыми, см. Раздел "Связь с хостом (по умолчанию-ns)" в документе "IPVLAN - начало", опубликованном одним из авторов IPvlan (Mahesh Bandewar).

Ответ 4

Я больше не рекомендую это решение. Поэтому он был удален. Это было с использованием драйвера моста и brctrl.

Сейчас есть лучший и официальный драйвер. См. Другой ответ на этой странице: fooobar.com/questions/313720/...

Ответ 5

Возможно отображение физического интерфейса в контейнер через pipework.

Подключить контейнер к локальному физическому интерфейсу

pipework eth2 $(docker run -d hipache /usr/sbin/hipache) 50.19.169.157/24
pipework eth3 $(docker run -d hipache /usr/sbin/hipache) 107.22.140.5/24

Теперь может быть родной путь, но я не рассматривал это для выпуска 1.10.