В даний час ми використовуємо набір інструментів 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, і використовую той самий хост для обох. Що мені не вистачає?
Висновок "show link 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
Назва veth вибирається автоматично LXC. Еквівалентна установка, що використовує libvirt-LXC з одним контейнером, виробляє по суті однаковий вихід, за винятком того, що згенерований ім'я veth0.
Інтерфейс virbr0-nic BTW створений libvirt і використовується з контейнерами libvirt-LXC і віртуальними машинами, які налаштовані на використання NAT замість мосту. Цікаво, що якщо я використовую NAT-адресацію з моїми контейнерами libvirt-LXC, то вони ведуть себе так само, як мої LXC-контейнери, які, як передбачається, використовують мостові мережі через br0. Це змушує мене задатися питанням, якщо насправді я якось використовую NAT адресації з моїми контейнерами LXC замість brdiged мереж.
vethінтерфейси, підключені до нього, чи не так? Де треба їхати? Хочете направити? Або перекрити його? Будь ласка, надайте вихідні даніbridge link show br0.