Как правильно настроить сеть для серверов (сервисов) в контейнерах?

Question

[dinegnet]

Вводная:

Имеется сервер в датацентре.
На нем необходимо взвести несколько независимых веб-серверов, принадлежащих разным владельцам.

Для надежности изоляции предполагается использовать контейнерную технологию
LXC для Linux варианта и Jails для FreeBSD варианта "материнского" сервера

Сервер будет иметь один реальный "белый" адрес
Следовательно, нельзя напрямую в контейнеры простым образом пробрасывать этот реальный адрес, ведь http-порт № 80 общий для всех серверов.

Предполагается что 80 порт будет заходить в nginx, который уже по по имени будет определять на какой из внутренних серверов передавать.

Рецепты из интернета выглядят по разному

Кто то рекомендут создать фиктивный дополнительный сетевой интерфейс локального типа (тот же самый что и 127.0.0.1|) и навешать на него адреса 192.168.0.х, соответственно один адрес = одному веб-серверу внутри контейнера.

Кто то рекомендует навешивать адрес 192.168.0.x изнутри контейнера на ровно тот же самый интерфейс, на который навешан снаружи реальный внешний белый адрес.

Но и это еще не все.

Первый входящий nginx, который будет мультиплицировать запросы по внутренним серверам, также хочется засунуть в контейнер. То есть ему будет нужно сделать редирект

Но и это еще не все.

Контейнеры изнутри хочется чтобы иногда имели доступ к интернету прямой для обновлений,
а иногда доступа не имели (им не зачем, достаточно слушать локальный адрес на порту 80 для работы веб-сервера).
То есть нужен NAT внутрь контейнеров пробрасывающийся и отключаемый.

Какую бы принципиальную схему с интерфейсами внутри контейнеров, с адресами на них и каую бы свзь внутренних контейнеров с внешним интернетом и какую бы связь внутренних контейнеров с первым "входящим" главным nginx вы бы предложили?

Comments

[Tyranron]

One node Kubernetes

[dinegnet]

Tyranron:
Не годится.
Устанавливаемые сервера не совместимы с "12-ю факторами".

[dinegnet]

Tyranron: Поэтому там не Докер будет.

[dinegnet]

Tyranron:
В частности - могут писать данные куда попало, индивидуально разруливать это и выделять под изменяемые файлы Volume нет возможности.

[Tyranron]

dinegnet: получается, у Вас нет возможности перенастроить сервер полностью, а нужно лишь вклиниться в существующую инсталляцию? Или специфика прям вот совсем-совсем?
Если так, то приношу извинения за быстрый и невдумчивый совет.

[dinegnet]

Tyranron: сервер в смысле ОС - можно.
сервер внутри контейнера, то есть сервер в смысле прикладного ПО - ограничено.
в частности по причине не соответствия принципам 12 факторов - стандартные инструменты работы с контейнирами типа Kubernetes не помогут.

скажем как данность - имеется контейнер уже готовый. Контейнер не Docker, а голый LXC или Jails.
его нужно обеспечить сетью.

поменять внутри контейнера в прикладном ПО в настройках адрес или интерфейс на котором веб-сервер будет слушать внешний мир - возможно.

Answer 1

[Пума Тайланд]

один внутренный бридж в него роутить все что надо
ну на одну виртуалку пробросить 80 порт
ну а нат включать и выключать правилом фаервола

Comments

[dinegnet]

Например у меня снаружи интерфейсы
em0
lo0

Внутри должны быть те же
em0
lo0
и роутить на em0

Или, как в ряде рекомендаций:
плюс еще один
em0
lo0
lo1
и роутить на lo1

[Пума Тайланд]

dinegnet: бридж отдельный должен быть джейлы унылы как и фрибсд так что про них не подскажут

[dinegnet]

Пума Тайланд:
с сетью у Фряхи более чем нормально, и так было всегда.

[Пума Тайланд]

dinegnet: да фряха сама по себе унылое гавно ногами оставшееся в девяностых

[dinegnet]

Пума Тайланд:
мы все родом из девяностых

насчет рекомендации сочетать NAT и бридж непонятка.
это же избыточно? они же один и тот же функционал дают - передача между разными сетевыми разделами

[Пума Тайланд]

dinegnet: чем? Приватные айпи никак в инет не выйдут без Ната, ну а виртуалки логично вешать на отдельный бридж

Answer 2

[sisn]

FreeBSD:

файл /etc/rc.conf

cloned_interfaces="lo1"
ipv4_addrs="192.168.0.1/24"

firewall_enable="YES"
firewall_type="/etc/firewall"

файл /etc/firewall

add 1040 allow ip from any to any via lo1
nat 1 config log if em0 reset same_ports deny_in redirect_port tcp 192.168.0.2:80 80 redirect_port tcp 192.168.0.2:443 443 
add 10130 nat 1 ip from any to any via em0
add 65534 deny all from any to any

Здесь:

em0 - интерфейс, глядящий в интернет
lo1 - интерфейс, глядящий в сеть Jail`ов
192.168.0.1 - адрес внешней машины (хоста) на lo1
192.168.0.2 - адрес веб-сервера в Jail`е, также на lo1

Когда создаете Jail, не забывайте указывать, что ваш адрес будет именно на lo1
Например:

ezjail-admin create websrv 'lo1|192.168.0.2'

P.S
Параметр deny_in в конфигурировании nat закроет ваш сервер ото всех неизвестных входящих.
Если вам нужен ssh, не забудьте добавить его порт, например как redirect_port
Или до правила 10130 добавьте skip этого правила для порта 22.

Answer 3

[lagmalak]

Ответ sisn хорош только в случае, если вы доверяете контейнерам.
если внутри потенциальный зловред, который может занять адрес и порт чужого jail, то я бы положился на vnet в FreeBSD.

А это значит epair, а не lo1
epair - эмулирует прямой кабель, один конец которого подключен в jail, другой конец подключен в родительский хост.

Ну и без bridge тут вы не обойдетесь - ведь трафик же нужно куда-то дальше рулить.
shawndebnath.com/articles/2016/03/27/freebsd-jails...

Answer 4

[ralaton121]

FreeBSD

epair+bridge видится более правильным методом. однако в версии 10 он был точно не готов для production.
В 11-й версии вам придется перекомпилировать ядро, чтобы его включить.

В то время как метод с lo1 готов из горобки.