Yota-inet.ru ## Расширение возможностей цифровой платформы X5 Group для поставщиков
## октября 2023 года, Москва
X5 Group, ведущая продуктовая розничная компания в России, расширяет возможности цифровой платформы для поставщиков Dialog.X5 и внедряет систему быстрого и удобного получения данных. X5 DataBridge позволит партнеру на собственных IT-ресурсах не только оперативно формировать все необходимые отчеты на основе аналитики Х5, но и совмещать это с данными других ритейлеров или data-платформ.
## Функциональность X5 DataBridge
На текущем этапе развития продукта пользователю доступны отчеты согласно выбранному модулю продукта Dialog.X5/Logistics или Dialog.X5/Insights. Х5 планирует дальнейшее наращивание функций X5 DataBridge. Удобный и интуитивно-понятный интерфейс позволяет смотреть за статусом работы, потоками данных и получать мгновенный доступ ко всему объему информации.
## Доступные отчеты и аналитика
Доступные отчеты содержат полный спектр данных, необходимых для анализа:
- Продажи и тренды категории покупательского поведения
- Полноту и время поставки
- Потребности в товарах у торговых сетей
- Наличие товара в торговых точках
- Изменения ассортиментных матриц
## Интеграция с другими провайдерами данных
Одной из киллер-фич X5 DataBridge является возможность быстрого подключения к инструменту других провайдеров данных, что фактически означает для них возможность начать монетизировать свои объемы информации с минимальными затратами.
## Развитие рынка данных для ритейла
Предлагая партнерам новый инструмент, X5 рассчитывает на развитие рынка данных для ритейла, а значит и на последующий рост аналитической зрелости, большей вовлеченности в осознанное использование big data.
## Комментарий директора по монетизации данных X5 Group
На рынке больших данных существует множество вариантов и каналов потребления аналитики и все больше компаний, которые применяют data—driven подход в своей операционной деятельности. Для сотен своих поставщиков и партнеров, которые активно используют данные, X5 Group разработала удобный и быстрый инструмент X5 DataBridge. По сути, это приложение, которое устанавливается на локальный компьютер или на сервер партнера, который получает автоматическую интеграцию из коробки с ключевыми аналитическими сервисами от X5, в первую очередь – с Insights и Logistics, флагманскими продуктами компании
- Дмитрий Прусов, директор по монетизации данных X5 Group
## Статус платформы
Платформа Dialog X5 и X5 DataBridge являются собственной разработкой Х5, система строится на единой системе аутентификации, архитектуре данных и интеграционной модели. Сегодня к цифровой платформе Dialog подключено более 300 поставщиков, а в рамках пилота X5 Data Bridge тестировало 10 партнеров. Все сервисы платформы отвечают требованиям информационной безопасности и условиям хранения данных.
Временами работа с контейнерами может казаться волшебством. В хорошем смысле для тех, кто понимает как устроено внутри, и в ужасающем – для тех, кто этого не понимает. К счастью, мы уже довольно давно изучаем технологию контейнеризации, и нам даже удалось выяснить, что контейнеры – это просто изолированные и ограниченные процессы Linux, что образы на самом деле не нужны для запуска контейнеров, и что, наоборот, для создания образа нам, возможно, потребуется запускать контейнеры.
Теперь пришло время заняться проблемой сети в контейнерах. Или, точнее, проблемой контейнерной сети с одним хостом. В этой статье мы собираемся ответить на следующие вопросы:
Отвечая на эти вопросы, мы создадим контейнерную сеть с одним хостом с нуля, используя стандартные инструменты Linux. В результате станет очевидным, что магия контейнерных сетей возникает из сочетания гораздо более базовых возможностей Linux.:
Предварительные требования
Предполагается базовое знание сценариев bash и командной строки Linux, но навыков программирования не требуется. Примеры в этом руководстве были протестированы на Ubuntu 22.04, и они, вероятно, будут работать и на других современных дистрибутивах Linux. Рекомендуется использовать изолированную и одноразовую среду "песочницы".
⚠️ ОСТОРОЖНО: выполнение приведенных ниже команд непосредственно в операционной системе вашего компьютера может привести к проблемам.
Основные компоненты сетевой среды (устройства, таблицы маршрутизации, правила брандмауэра)
Что представляет собой сетевое окружение Linux, также известное как сетевой контекст? Ну, очевидно, набор сетевых устройств. Что еще? Вероятно, какие-то правила маршрутизации. И, конечно, не стоит забывать – перехваты netfilter, в том числе те, которые определены правилами iptables. Есть и другие компоненты, но приведенного выше должно быть достаточно для наших целей в этом руководстве.
Мы можем быстро создать (не полный) скрипт для проверки сетевой среды:
Однако перед ее запуском давайте добавим новую цепочку iptables, чтобы сделать набор правил более узнаваемым:
💡 Предполагается, что все команды в этом руководстве должны выполняться как root или с префиксом sudo.
iptables –new-chain MY_CUSTOM_CHAIN
После этого выполнение скрипта inspect на моей машине выдает следующий результат: Если мы запустим скрипт на обычной машине Linux, мы получим результат, аналогичный следующему:
Зачем нам нужно проверять сетевое окружение? Потому что мы собираемся начать создавать контейнеры в ближайшее время, и мы хотим убедиться, что каждый из них получит свой собственный сетевой контекст, полностью изолированный от среды хоста и других контейнеров. Для этого нам нужно привыкнуть к перечислению сетевых устройств, маршрутизации и правил iptables.
Создание первого контейнера с использованием сетевого пространства имен (netns)
Для простоты, вместо создания полноценных контейнеров, использующих все возможные пространства имен Linux, в этом руководстве мы ограничим область виртуализации только сетевым контекстом. Таким образом, пространство имен контейнера и сети, приведенное ниже, будут использоваться взаимозаменяемо.
Вы, вероятно, уже слышали, что одно из пространств имен Linux, используемых для создания контейнеров, называется netns или сетевое пространство имен. От man ip-netns, пространство имен network логически является еще одной копией сетевого стека со своими собственными маршрутами, правилами брандмауэра и сетевыми устройствами.
Один из способов создать сетевое пространство имен в Linux – использовать ip netns add команду (где ip утилита берется из де-факто стандартной коллекции iproute2):
ip netns add netns0
Чтобы проверить, добавлено ли в систему новое пространство имен, выполните следующую команду:
ip netns list
Как начать использовать только что созданное пространство имен? Есть еще одна удобная утилита Linux под названием nsenter. Она входит в одно или несколько указанных пространств имен, а затем выполняет в нем заданную программу. Например, вот как мы можем запустить новый сеанс командной строки внутри netns0 пространства имен:
nsenter --net=/run/netns/netns0 bash
Недавно созданный bash процесс теперь находится в netns0 пространстве имен. Если мы запустим наш скрипт inspect в этой новой оболочке, мы получим следующий результат.
Приведенный выше вывод ясно показывает, что bash процесс, который выполняется в netns0 пространстве имен, имеет совершенно другую сетевую среду – здесь вообще нет правил маршрутизации, нет MY_CUSTOM_CHAIN цепочки iptables и только одно сетевое устройство, loopback. Пока все хорошо!
Подключение контейнеров к хостингу с помощью виртуальных устройств Ethernet (veth)
Новая изолированная сетевая среда была бы не так полезна, если бы мы не могли взаимодействовать с ней. К счастью, Linux предоставляет специальное средство для подключения сетевых пространств имен – виртуальное устройство Ethernet или veth. От man veth, устройства veth – это виртуальные устройства Ethernet. Они могут действовать как туннели между сетевыми пространствами имен для создания моста к физическому сетевому устройству в другом пространстве имен, но также могут использоваться как автономные сетевые устройства.
Виртуальные устройства Ethernet всегда работают парами. Не беспокойтесь, если это звучит немного запутанно, это станет ясно, когда мы посмотрим на пример использования.
⚠️ nsenter Команда, которую мы использовали выше, запустила вложенный сеанс командной оболочки в netns0 пространстве имен network. Не забудьте сделать exit или открыть новую вкладку терминала , прежде чем переходить к следующим шагам.
Из пространства имен корневой сети давайте создадим пару виртуальных устройств Ethernet:
ip link add veth0 type veth peer name ceth0
## Виртуализация сетей Linux: создание и связывание виртуальных устройств Ethernet
С помощью этой единственной команды мы только что создали пару взаимосвязанных виртуальных устройств Ethernet. Имена veth0 и ceth0 были выбраны произвольно:
```bash
ip link list
Как veth0, так и ceth0 после создания находятся в сетевом контексте хоста, то есть в пространстве имен корневой сети. Чтобы соединить корневое пространство имен с netns0 пространством имен, которое мы создали ранее, нам нужно сохранить одно из устройств в корневом пространстве имен и переместить другое в netns0:
ip link set ceth0 netns netns0
Давайте убедимся, что одно из устройств исчезло из корневого сетевого контекста:
ip link list
Настройка подключений
Давайте начнем с корневого пространства имен:
ip link set veth0 up
ip addr add 172.18.0.11/16 dev veth0
В новом сеансе оболочки, который выполняется в netns0 пространстве имен, нам нужно включить устройство обратной связи:
ip link set lo up
Теперь настроим ceth0 устройство:
ip link set ceth0 up
ip addr add 172.18.0.10/16 dev ceth0
Проверка соединения
Для проверки подключения пропингуем veth0 устройство из netns0 пространства имен:
ping -c 2 172.18.0.11
После успешного пинга вернемся к корневому пространству имен и пропингуем ceth0 устройство:
ping -c 2 172.18.0.10
Проверка доступности других адресов
Если попытаемся связаться с другим адресом из netns0 пространства имен, мы получим сообщение об ошибке:
ip addr show dev eth0
ping: connect: Network is unreachable
Решение проблемы
Проблема возникает из-за отсутствия маршрутизации. Мы можем решить эту проблему, добавив маршрут в netns0 и корневое пространство имен:
ip route list
Заключение
Теперь мы знаем, как виртуализировать и соединять сетевые среды Linux. Мы также научились решать проблемы с маршрутизацией для доступа к другим сетям.
Создаем второй контейнер, повторяя те же шаги
Идея контейнеризации возникла потому, что людям нужен был лучший способ совместного использования компьютерных ресурсов. Вместо использования одного сервера только для одного приложения контейнеры позволяют запускать множество (изолированных друг от друга) процессов на одном сервере. Таким образом, вы максимально используете возможности сервера.
Давайте посмотрим, что произойдет, если мы разместим несколько контейнеров на одном хосте, используя veth трюк, описанный выше.
Из корневого пространства имен добавляем еще один "контейнер":
ip netns add netns1 ip link add veth1 type veth peer name ceth1 ip link set veth1 up ip addr add 172.18.0.21/16 dev veth1 ip link set ceth1 netns netns1
nsenter --net=/run/netns/netns1 bash
ip link set lo up ip link set ceth1 up ip addr add 172.18.0.20/16 dev ceth1
Хорошо, теперь начинается наша любимая часть - проверка подключения (из netns1 пространства имен):
ping -c 2 172.18.0.21
PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data. --- 172.18.0.21 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1023ms
172.18.0.0/16 dev ceth1 proto kernel scope link src 172.18.0.20
Есть даже маршрут! Так почему же он не работает?
Что, если мы попытаемся пропинговать ceth1 устройство из корневого пространства имен?
ping -c 2 172.18.0.20
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. From 172.18.0.11 icmp\_seq=1 Destination Host Unreachable From 172.18.0.11 icmp\_seq=2 Destination Host Unreachable --- 172.18.0.20 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1014ms pipe 2
В то же время из нашего первого контейнера (netns0) мы МОЖЕМ добраться до конца хоста нового контейнера (veth1):
PING 172.18.0.21 (172.18.0.21) 56(84) bytes of data. 64 bytes from 172.18.0.21: icmp\_seq=1 ttl=64 time=0.037 ms 64 bytes from 172.18.0.21: icmp\_seq=2 ttl=64 time=0.046 ms --- 172.18.0.21 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 33ms rtt min/avg/max/mdev = 0.037/0.041/0.046/0.007 ms
Но мы все еще не можем достичь netns1:
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. From 172.18.0.10 icmp\_seq=1 Destination Host Unreachable From 172.18.0.10 icmp\_seq=2 Destination Host Unreachable --- 172.18.0.20 ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 63ms pipe 2
Что ж, мне потребовалось некоторое время, чтобы разобраться в этом, но, очевидно, мы столкнулись с конфликтом маршрутов. Давайте проверим таблицу маршрутизации в корневом пространстве имен:
Несмотря на то, что после добавления второй veth пары таблица маршрутизации root получила новый 172.18.0.0/16 dev veth1 proto kernel scope link src 172.18.0.21 маршрут, уже существовал маршрут для точно такой же 172.18.0.0/16 сети. Когда второй контейнер пытается выполнить пинг veth1 устройства, выбирается первый маршрут, и это прерывает подключение. Если бы мы удалили первый маршрут (ip route delete 172.18.0.0/16 dev veth0 proto kernel scope link src 172.18.0.11) и перепроверили подключение, ситуация была бы обратной - netns0 были бы в подвешенном состоянии и netns1 могли бы пинговать veth0 устройство хоста.
### Объединение контейнеров с помощью виртуального сетевого коммутатора (bridge)
К счастью, в Linux есть решение вышеупомянутой проблемы, и это еще одно средство виртуализации сети под названием bridge.
Изображение из Bridge vs. Switch: что я узнал из экскурсии по центру обработки данных.
Давайте попробуем поиграть с нашей новой игрушкой. Но сначала нам нужно очистить существующую настройку, потому что некоторые конфигурационные изменения, которые мы внесли до сих пор, на самом деле больше не нужны. Удаления сетевых пространств имен должно быть достаточно:
ip netns delete netns0 ip netns delete netns1
Однако, если у вас все еще остались какие-то недоделки, вы можете удалить их вручную:
ip link delete veth0 ip link delete ceth0 ip link delete veth1 ip link delete ceth1
Чтобы подготовить почву для нового эксперимента, давайте быстро воссоздадим два контейнера.
Первый контейнерИз корневого пространства имен:ip netns add netns0 ip link add veth0 type veth peer name ceth0 ip link set veth0 up ip link set ceth0 netns netns0Продолжаем с netns0пространства имен:nsenter --net=/run/netns/netns0 baship link set lo up ip link set ceth0 up ip addr add 172.18.0.10/16 dev ceth0exitВторой контейнерИз корневого пространства имен:ip netns add netns1 ip link add veth1 type veth peer name ceth1 ip link set veth1 up ip link set ceth1 netns netns1Продолжаем с netns1пространства имен:nsenter --net=/run/netns/netns1 baship link set lo up ip link set ceth1 up ip addr add 172.18.0.20/16 dev ceth1exit
Убедитесь, что на хосте нет новых маршрутов:
default via 172.16.0.1 dev eth0 172.16.0.0/16 dev eth0 proto kernel scope link src 172.16.0.2
Теперь мы готовы создать мостовое устройство:
ip link add br0 type bridge ip link set br0 up
Когда мост создан, нам нужно подключить к нему контейнеры, прикрепив концы хоста (veth0 и veth1) их veth пар:
ip link set veth0 master br0 ip link set veth1 master br0
Пришло время еще раз проверить подключение!
От первого контейнера ко второму:
nsenter --net=/run/netns/netns0 ping -c 2 172.18.0.20
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 64 bytes from 172.18.0.20: icmp\_seq=1 ttl=64 time=0.295 ms 64 bytes from 172.18.0.20: icmp\_seq=2 ttl=64 time=0.053 ms --- 172.18.0.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 0.053/0.174/0.295/0.121 ms
От второго контейнера к первому:
nsenter --net=/run/netns/netns1 ping -c 2 172.18.0.10
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 64 bytes from 172.18.0.10: icmp\_seq=1 ttl=64 time=0.052 ms 64 bytes from 172.18.0.10: icmp\_seq=2 ttl=64 time=0.103 ms --- 172.18.0.10 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1019ms rtt min/avg/max/mdev = 0.052/0.077/0.103/0.025 ms
nsenter --net=/run/netns/netns0 ip neigh
172.18.0.20 dev ceth0 lladdr 3e:f2:8f:03:c8:1c REACHABLE
nsenter --net=/run/netns/netns1 ip neigh
172.18.0.10 dev ceth1 lladdr 4e:ff:98:90:d5:ea REACHABLE
Поздравляем! 🎉 Мы только что узнали, как превратить контейнеры в дружелюбных соседей и научить их общаться друг с другом.
### Выход на внешний мир (маршрутизация IP и маскировка)
Наши контейнеры могут взаимодействовать друг с другом, но могут ли они взаимодействовать с хостом, то есть корневым пространством имен?
nsenter --net=/run/netns/netns0 ping -c 2 172.16.0.2 # host's eth0 address
Это отчасти очевидно, для этого просто нет маршрута в netns0:
nsenter --net=/run/netns/netns0 ip route list
Корневое пространство имен также не может взаимодействовать с контейнерами:
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. --- 172.18.0.10 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1007ms
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. --- 172.18.0.20 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1016ms
ip addr add 172.18.0.1/16 dev br0
Теперь корневое пространство имен должно иметь возможность пинговать контейнеры.
Корневое пространство имен для первого контейнера:
PING 172.18.0.10 (172.18.0.10) 56(84) bytes of data. 64 bytes from 172.18.0.10: icmp\_seq=1 ttl=64 time=0.141 ms 64 bytes from 172.18.0.10: icmp\_seq=2 ttl=64 time=0.081 ms --- 172.18.0.10 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1020ms rtt min/avg/max/mdev = 0.081/0.111/0.141/0.030 ms
Корневое пространство имен для второго контейнера:
PING 172.18.0.20 (172.18.0.20) 56(84) bytes of data. 64 bytes from 172.18.0.20: icmp\_seq=1 ttl=64 time=0.048 ms 64 bytes from 172.18.0.20: icmp\_seq=2 ttl=64 time=0.083 ms --- 172.18.0.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1030ms rtt min/avg/max/mdev = 0.048/0.065/0.083/0.017 ms
Контейнер, вероятно, также получил возможность пинговать интерфейс моста, но они по-прежнему не могут связаться с хостом eth0\. Для этого нам нужно добавить маршрут по умолчанию в таблицы маршрутизации контейнеров:
nsenter --net=/run/netns/netns0 ip route add default via 172.18.0.1 # i.e. via the bridge interface
nsenter --net=/run/netns/netns1 ip route add default via 172.18.0.1 # i.e. via the bridge interface
Подтверждение подключения контейнеров к хостингу:
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data. 64 bytes from 172.16.0.2: icmp\_seq=1 ttl=64 time=0.035 ms 64 bytes from 172.16.0.2: icmp\_seq=2 ttl=64 time=0.036 ms --- 172.16.0.2 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1009ms rtt min/avg/max/mdev = 0.035/0.035/0.036/0.000 ms
Идеально! Мы можем переходить от контейнеров к хосту и обратно.
Теперь давайте попробуем подключить контейнеры к внешнему миру. По умолчанию пересылка пакетов (то есть функциональность маршрутизатора) в Linux отключена. Нам нужно включить ее (из корневого пространства имен):
Это изменение фактически превратило хост-машину в маршрутизатор, а интерфейс bridge стал шлюзом по умолчанию для контейнеров. Проверка подключения контейнеров к Интернету.:
nsenter --net=/run/netns/netns0 ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. --- 8.8.8.8 ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 1018ms
iptables -t nat -A POSTROUTING -s 172.18.0.0/16 ! -o br0 -j MASQUERADE
Команда довольно проста, если вы знаете, как iptables работать - мы добавили новое правило в nat таблицу POSTROUTING цепочки с просьбой маскировать все пакеты, отправленные в 172.18.0.0/16 сеть, за исключением тех, которые отправляются в bridge интерфейс.
Еще раз проверяем подключение:
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp\_seq=1 ttl=115 time=9.29 ms 64 bytes from 8.8.8.8: icmp\_seq=2 ttl=115 time=7.72 ms --- 8.8.8.8 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 7.718/8.505/9.293/0.787 ms
⚠️ Помните, что мы следуем стратегии "по умолчанию - разрешить", которая может быть довольно опасной в реальных условиях. Политика iptables хоста по умолчанию - ACCEPT для каждой цепочки:
\-P INPUT ACCEPT-P FORWARD ACCEPT-P OUTPUT ACCEPT
В качестве хорошей практики Docker, например, ограничивает все по умолчанию, а затем включает маршрутизацию только для известных путей.
Хорошо, давайте посмотрим, сможете ли вы применить свои новые знания в следующей задаче!
### Предоставление внешнему миру доступа к контейнерам (публикация портов)
Хорошо известна практика публикации портов контейнера для некоторых (или всех) интерфейсов хоста. Но что на самом деле делает публикация портов?
Представьте, что у нас есть сервер, работающий внутри контейнера:
nsenter --net=/run/netns/netns0 python3 -m http.server --bind 172.18.0.10 5000
Если мы попытаемся отправить HTTP-запрос этому серверному процессу с хоста, все будет работать - ну, есть связь между корневым пространством имен и всеми интерфейсами контейнера, почему бы и нет?
Попробуйте сами (из корневого пространства имен в отдельной вкладке терминала):
curl: (7) Failed to connect to 172.16.0.2 port 5000 after 0 ms: Connection refused
Таким образом, нам нужно найти способ пересылать любые пакеты, поступающие на порт 5000 в eth0 интерфейсе хоста, в 172.18.0.10:5000 пункт назначения. Или, другими словами, нам нужно опубликовать порт контейнера 5000 в eth0 интерфейсе хоста. Еще раз, iptables приходят на помощь!
Публикацию портов для внешнего трафика можно выполнить с помощью следующей команды (из корневого пространства имен):
iptables -t nat -A PREROUTING -d 172.16.0.2 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000
Публикация для локального трафика выглядит немного иначе (поскольку она не проходит цепочку предварительной маршрутизации):
iptables -t nat -A OUTPUT -d 172.16.0.2 -p tcp -m tcp --dport 5000 -j DNAT --to-destination 172.18.0.10:5000
Кроме того, нам необходимо включить iptables, перехватывающие трафик по мостовым сетям:
Идеально! Вы хорошо подготовлены к следующему испытанию!
### Понимание типов сетей Docker
Хорошо, что мы можем сделать со всеми этими бесполезными знаниями?
Например, мы могли бы попытаться понять некоторые из сетевых режимов Docker!
Давайте начнем с --network host режима. Используя Docker playground, попробуйте сравнить результаты следующих команд:
ip link list # from the Docker host
docker run -it --rm --network host alpine ip link list
Сюрприз, сюрприз, они совершенно одинаковые! Т.е. в режиме host Docker просто не использует изоляцию сетевого пространства имен, а контейнеры работают в корневом пространстве имен сети и совместно используют сетевой контекст с хост-машиной.
Следующий режим для проверки - --network none. Выходные данные docker run -it --rm --network none alpine ip link команды покажут только один сетевой интерфейс с обратной связью. Это соответствует наблюдениям, которые мы сделали сразу после создания нового сетевого пространства имен в начале нашего путешествия.
И последнее, но не менее важное: --network bridge (режим по умолчанию). Что ж, это именно то, что мы пытались воспроизвести во всем этом руководстве!
Кроме того, многие дистрибутивы Kubernetes также используют bridge сеть для соединения модулей, работающих на одном узле. Итак, понимание того, как это работает, является хорошей отправной точкой для погружения в высокоуровневые CNI Kubernetes, такие как Flannel или Calico.
### Заключение
Сегодня мы узнали, как виртуализировать сетевые среды, подключить несколько контейнеров Linux с помощью veth пар и устройств Linux bridge, и даже попытались настроить IP-маршрутизацию и NAT, чтобы обеспечить связь между контейнерами и внешним миром. Самое главное, мы попытались соединить точки между используемыми методами и сетевыми режимами Docker, надеюсь, немного прояснив их. Эти знания помогут вам стать опытным пользователем Docker, а также заложат хорошую основу для понимания высокоуровневых сетевых концепций, используемых в Kubernetes. Удачи вам!
#### Материалы, использованные при написании этой статьи
Можно ли использовать другой прокси-сервер, кроме ESET Bridge?
Как это влияет на производительность сервера ESET PROTECT?
Когда следует использовать решение ESET Bridge в качестве прокси-сервера?
Как узнать, на каком компьютере запущено решение ESET Bridge?
Как просмотреть примененную конфигурацию ESET Bridge?
Как настроить ESET Bridge с ESET PROTECT с пользовательским именем хоста или портом?
Можно ли вернуться к использованию Apache HTTP Proxy?
Агент ESET Management можно использовать с любым прокси-сервером, который соответствует следующим условиям.
Может перенаправлять SSL-соединение
Поддерживает HTTP CONNECT
Не использует имя пользователя и пароль.
## Как это влияет на производительность сервера ESET PROTECT?
Использование решения ESET Bridge практически не влияет на производительность сервера ESET PROTECT Server.
## Когда следует использовать решение ESET Bridge в качестве прокси-сервера?
Рекомендуем использовать решение ESET Bridge в качестве прокси-сервера, если ваша инфраструктура соответствует хотя бы одному из следующих условий.
Управляемые компьютеры (компьютеры, на которых работает агент ESET Management) не могут напрямую подключиться к серверу ESET PROTECT Server.
У вас есть удаленное расположение или филиал, и вы желаете использовать прокси-сервер для обмена данными между:
сервером ESET PROTECT и решением ESET Bridge (в качестве прокси-сервера);
решением ESET Bridge (в качестве прокси-сервера) и клиентскими компьютерами в удаленном расположении.
## Как узнать, на каком компьютере запущено решение ESET Bridge?
В разделе веб-консоли ESET PROTECT рядом с именем компьютера, на котором запущено решение ESET Bridge, отображается значок
## Как просмотреть примененную конфигурацию ESET Bridge?
Откройте веб-консоль ESET PROTECT в веб-браузере и авторизуйтесь.
Дождитесь создания конфигурации и ее доставки в веб-консоль.
## Как настроить ESET Bridge с ESET PROTECT с пользовательским именем хоста или портом?
Чтобы вернуться к использованию Apache HTTP Proxy, выполните следующие действия.
Прекратите использовать и удалите решение ESET Bridge.
Установите Apache HTTP Proxy.
Конфигурировать Apache HTTP Proxy.
## Просмотр файлов и папок
Для перемещения между файлами и папками можно выполнить одно из следующих действий.
## Отображение содержимого вложенных папок
Adobe Bridge может отображать папки и вложенные папки в непрерывном («плоском») виде. «Плоский» вид позволяет просмотреть все ее содержимое, не перемещаясь по вложенным папкам.
Если вы больше не хотите просматривать содержимое вложенных папок, выполните следующие действия.
## Открытие файлов в Adobe Bridge
Adobe Bridge позволяет открывать даже файлы, созданные не в программах Adobe. При открытии файла в Adobe Bridge используется исходное приложение или приложение, указанное пользователем. Adobe Bridge позволяет также помещать файлы в документе, открытом в любом из приложений Adobe.
Выберите файл и выполните одно из следующих действий.
Узнайте подробнее об импорте с устройства под управлением Mac OS 10.11.x.
## Изменение связей типов файлов
Приложение, выбранное для открытия файлов определенного типа, будет запускаться только для файлов, открываемых с помощью Adobe Bridge, и имеет больший приоритет, чем настройки ОС.
Когда вы просматриваете и выбираете приложение для открытия файла, Bridge позволяет вам выбрать, хотите ли вы открывать файл с помощью этого приложения только один раз или всегда. При выборе параметра задается связь для этого типа файлов.
## Помещение файлов в другое приложение
Adobe Bridge позволяет искать файлы по нескольким сочетаниям критериев поиска. Можно сохранить критерии поиска в виде смарт-коллекции, обновляемой за счет файлов, отвечающих критериям.
## Быстрый поиск
Используйте поле на панели приложения для поиска файлов и папок в Adobe Bridge. осуществляется с помощью поискового механизма Adobe Bridge либо с помощью механизма Windows Desktop Search (Windows) или Spotlight (Mac OS). Поисковый механизм Adobe Bridge выполняет поиск имен файлов и ключевых слов. Механизмы ОС позволяют выполнять поиск по имени файла или папки и ключевым словам в названиях изображений. Поисковый механизм Adobe Bridge выполняет поиск в текущей папке, а также во всех вложенных папках, включая папки (Windows) и Computer (Mac OS). Поисковый механизм ОС выполняет поиск в папке, выбранной в настоящий момент, или в папках (Windows) и Computer (Mac OS).
## Разметка файлов и назначение им рейтинга
Например, при просмотре большого количества импортированных изображений в Adobe Bridge. При просмотре новых изображений можно пометить каждое изображение, которое нужно сохранить. По завершении этого первого этапа можно воспользоваться командой «Сортировать», чтобы показать и обработать файлы, ранее помеченные тем или иным цветом.
Вы можете добавлять метки и оценки к папкам и файлам.
Имена меток можно задать в разделе установок . При назначении метки ее имя вносится в метаданные файла. При изменении имен меток в разделе установок все файлы со старыми метками помечаются метками белого цвета на .
При просмотре папок Adobe Bridge отображает файлы как с ярлыками, так и без них, пока не будет выбран другой режим.
## Сортировка файлов
По умолчанию Adobe Bridge сортирует файлы, отображаемые на панели «Содержимое», по имени. Порядок сортировки файлов можно изменить с помощью команды «Сортировка» или кнопки на панели приложения.