t
А реализаций по типу как в OpenVZ никто не находил? Так чтобы все белые IP на контейнерах прятались за 1-м mac-адресов внешнего интерфейса?
это костыльный нат такой, на одном 10.0.х висит еще и приколоченный айпишник?
Size: a a a
2017 July 19
t
вроде все юзают для прода bridge т.к можно белые ip у контейнера иметь
поддерживаю.
RB
это костыльный нат такой, на одном 10.0.х висит еще и приколоченный айпишник?
Это далеко не нат. У тебя все IP летят на внешний интерфейс сервера, так как он своим mac адресом отвечает на IP всех своих контейнеров, а после этот трафик политиками роутинга попадает на контейнер. NAT же работает совсем не так.
AK
Это далеко не нат. У тебя все IP летят на внешний интерфейс сервера, так как он своим mac адресом отвечает на IP всех своих контейнеров, а после этот трафик политиками роутинга попадает на контейнер. NAT же работает совсем не так.
ты поднимаешь АЛиасы для интерфейса
AK
auto em1
iface em1 inet static
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.1
broadcast 192.168.1.1
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 192.168.1.1
auto em1:0
iface em1:0 inet static
address 192.168.1.2
netmask 255.255.255.0
auto em1:1
iface em1:1 inet static
address 192.168.1.3
netmask 255.255.255.0
AK
ты про это?
RB
не он про чисто openvz фичу судя по всему пишет
Да. Более всего что похоже, это ipvlan который в docker можно использовать
t
bridge (L2 interface configuration)
fan (configuration specific to the Ubuntu FAN overlay)
tunnel (cross-host tunneling configuration)
ipv4 (L3 IPv4 configuration)
ipv6 (L3 IPv6 configuration)
dns (DNS server and resolution configuration)
raw (raw configuration file content)
user (free form key/value for user metadata)
fan (configuration specific to the Ubuntu FAN overlay)
tunnel (cross-host tunneling configuration)
ipv4 (L3 IPv4 configuration)
ipv6 (L3 IPv6 configuration)
dns (DNS server and resolution configuration)
raw (raw configuration file content)
user (free form key/value for user metadata)
RB
https://github.com/lxc/lxd/issues/3273
$ lxc profile copy default webdev
$ lxc profile device set webdev eth0 nictype macvlan
$ lxc profile device set webdev eth0 parent eth0
$ lxc profile assign rpm webdev
$ lxc profile show webdev
config: {}
description: ""
devices:
eth0:
nictype: macvlan
parent: eth0
type: nic
root:
path: /
pool: default
type: disk
name: webdev
used_by:
- /1.0/containers/rpm
$ lxc profile copy default webdev
$ lxc profile device set webdev eth0 nictype macvlan
$ lxc profile device set webdev eth0 parent eth0
$ lxc profile assign rpm webdev
$ lxc profile show webdev
config: {}
description: ""
devices:
eth0:
nictype: macvlan
parent: eth0
type: nic
root:
path: /
pool: default
type: disk
name: webdev
used_by:
- /1.0/containers/rpm
RB
На просторах находил, что macvlan получше bridge
AK
На просторах находил, что macvlan получше bridge
смотря для чего
ну типо есть недоказаная теория что у него лучше пропускная способность
но общаться с хостом он не умеет
ну типо есть недоказаная теория что у него лучше пропускная способность
но общаться с хостом он не умеет
AK
в любом случае
пока у тебя нет стабильного канала 10gbs ты не заметишь прироста от macvlan
пока у тебя нет стабильного канала 10gbs ты не заметишь прироста от macvlan
RB
можно bridge+nat держать, можно через bridge kvm крутить
И сколько ты по PPS сможешь заNATить?
RB
Простой хостинг сайтов.