В настоящее время мы используем набор инструментов CentOS libvirt-LXC для создания и управления контейнерами в CentOS 7.1. Однако этот набор инструментов устарел, поэтому мы планируем вместо этого изменить наши контейнеры для работы в рамках linuxcontainers.org. Я буду называть это просто LXC вместо libvirt-LXC.
В libvirt-LXC наши контейнеры настроены на использование мостового соединения хоста и поэтому подключены к сети хоста. Каждый контейнер имеет свой статический IP-адрес и отображается как физические машины в сети. Они могут видеть друг друга, а также другие системы, работающие в той же сети.
До сих пор я не мог заставить мосты хоста работать с LXC. Для LXC доступно достаточно информации о работе в сети, но многие, кажется, описывают немного разные способы настройки, и ничто из того, что я пробовал, не работает так, как я ожидал. Я могу заставить контейнеры видеть друг друга, но не смог заставить их видеть сеть хоста. Конфигурация, которую я использую для своих контейнеров, выглядит следующим образом:
lxc.utsname = test1
lxc.network.type = veth
lxc.network.link = br0
lxc.network.flags = up
Интерфейс br0 - это тот же мостовой интерфейс, который я настроил для использования с моими контейнерами libvirt-LXC. Некоторые сайты, с которыми я сталкивался, обсуждают настройку мостового соединения хоста для LXC, например, для настройки правил в iptables. Однако нам не нужны никакие такие правила с libvirt-LXC, и на самом деле iptables (или, точнее, firewalld под CentOS 7) даже не включен.
В дополнение к этой конфигурации, которую я использую, я также создал /etc /sysconfig /network-scripts /ifcfg-eth0 со следующими записями:
DEVICE=eth0
NM_CONTROLLED=no
ONBOOT=yes
BOOTPROTO=none
IPADDR=172.16.110.222
NETMASK=255.255.0.0
GATEWAY=172.16.0.1
Это точно такой же файл, который я использую для своих контейнеров на основе libvirt-LXC. Как я уже говорил, контейнеры могут видеть друг друга, но они не могут получить доступ к сети хоста. Они даже не могут пинговать своего хозяина. Таблица маршрутизации одинакова для обоих контейнеров LXC и libvirt-LXC:
# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 172.16.0.1 0.0.0.0 UG 0 0 0 eth0
link-local 0.0.0.0 255.255.0.0 U 1021 0 0 eth0
172.16.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
Я не уверен, какую магию LXC мне не хватает, чтобы открыть контейнеры до внешней сети. Я использую один и тот же шаблон для обоих тестов LXC и libvirt-LXC, и я использую один и тот же хост для обоих. Что мне не хватает?
Вывод "link link show br0" с одним запущенным контейнером:
# bridge link show br0
3: bond0 state UP : <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 19
6: virbr0-nic state DOWN : <BROADCAST,MULTICAST> mtu 1500 master virbr0 state disabled priority 32 cost 100
22: veth5BJDXU state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master virbr0 state forwarding priority 32 cost 2
Название ветки выбирается автоматически LXC. Эквивалентная установка с использованием libvirt-LXC с одним контейнером производит по существу тот же вывод, за исключением того, что сгенерированное имя - veth0.
BTW-интерфейс virbr0-nic создается libvirt и используется с контейнерами libvirt-LXC и виртуальными машинами, которые настроены на использование NAT вместо мостов. Интересно, что если я использую адресацию NAT с моими контейнерами libvirt-LXC, они ведут себя так же, как мои контейнеры LXC, которые, как предполагается, используют мостовую сеть через br0. Это заставляет меня задаться вопросом, действительно ли я как-то использую адресацию NAT с моими контейнерами LXC, а не с сетевыми настройками.