Сейчас без преувеличения можно сказать, что контейнеризация прочно вошла в нашу жизнь. Контейнеры используются в различных программных продуктах, начиная от микросервисов и заканчивая решениями ИБ, такими как песочницы. Однако, контейнеры не были бы столь удобным инструментом построения распределенной архитектуры, если бы они не могли взаимодействовать между собой, а также обмениваться данными с внешними сетевыми ресурсами. В этой статье мы подробно рассмотрим механизмы, позволяющие контейнерам работать с сетями.
Сетевые драйверы в Docker
Для того, чтобы работать с сетью Docker необходимы драйверы. Имеется несколько драйверов по умолчанию, которые обеспечивают основной функционал по работе с сетью:
none: отключение всех сетевых ресурсов.
bridge: сетевой драйвер по умолчанию. По сути, это мост между контейнером и хостовой машиной. Мостовые сети обычно используются, когда приложения выполняются в автономных контейнерах, которые должны взаимодействовать друг с другом.
host: для автономных контейнеров устраняется сетевая изолированность между контейнером и хостом Docker и напрямую используются сетевые ресурсы хоста.
overlay: наложенные сети соединяют несколько демонов Docker.
macvlan: сети Macvlan позволяют присваивать контейнеру MAC-адрес, благодаря чему он выглядит как физическое устройство в сети.
Смотрим настройки
Для начала посмотрим, какие именно настройки сети у нас имеются. Сделать это можно с помощью следующей команды:
docker network ls
Как видно, Docker назначает сетям идентификаторы по аналогии с идентификаторами для контейнеров.
Если мы хотим посмотреть более подробную информацию о той или иной сети, мы можем прибегнуть к помощи следующей команды:
docker network inspect [OPTIONS] NETWORK [NETWORK...]
Подробнее мы можем посмотреть настройки для каждой сети.
$ docker network inspect none
$ docker network inspect bridge
$ docker network inspect host
Посмотрим пример для bridge:
Как видно, в настройках уже указаны подсеть, шлюз по умолчанию и другие параметры. Далее поговорим, о том, что из себя представляет каждый из драйверов.
Драйвер, которого нет
Иногда, контейнер должен функционировать в полностью изолированной среде. То есть, нам не требуется сетевой стек в контейнере. В таком случае, при запуске контейнера необходимо использовать флаг --network none. Результатом работы этой команды будет создание устройства loopback.
Посмотрим на примере:
Как видно, мы не можем выбраться за пределы контейнера и пропинговать внешние ресурсы.
Режим моста
Более интересным с практической точки зрения является использование режима моста. Для работы с драйвером Bridge необходимо предварительно установить необходимые плагины:
$ sudo apt-get update -y
$ sudo apt-get install bridge-utils
Мостовая сеть обеспечивает взаимодействие подключенных к ней контейнеров. Соответственно, устройство Bridge перенаправляет трафик между сегментами сети. При этом, важной особенностью мостовой сети является то, что здесь обеспечивается изоляция от контейнеров, которые не подключены к данной мостовой сети. Тем самым мы получаем выделенную сеть, внутри которой контейнеры могут функционировать беспрепятственно, но которые защищены от взаимодействия с внешними контейнерами. Для того, чтобы находиться в одной мостовой сети, контейнеры должны выполняться на одном и том же хосте демона Docker.
Однако, важно понимать, что сетевые параметры мостовой сети по умолчанию изменить нельзя. Запущенные контейнеры подключаются к мостовой сети bridge по умолчанию, если не указано иное. Это влечет за собой определенный риск, поскольку несвязанные стеки/сервисы/контейнеры могут начать взаимодействовать друг с другом.
Но пользователь может создать собственный мост. Вернее, пользователь может создать множество мостов, и эти мосты, определяемые пользователем, обеспечивают автоматическое определение DNS между контейнерами. Важным аспектом использования пользовательских мостов является их лучшая, по сравнению с мостами по умолчанию изолированность. При необходимости можно быстро подключать контейнеры к пользовательским сетям и отключать их от них. И для каждой пользовательской сети создается свой настраиваемый мост.
В течение жизни контейнера можно в процессе работы быстро подключать и отключать его от пользовательских сетей. Чтобы убрать контейнер из мостовой сети по умолчанию, необходимо остановить контейнер и создать его заново с другими сетевыми параметрами.
Посмотрим пример:
Здесь мы сначала создали несколько сетей с пользовательскими мостами, а затем запустили контейнеры, подключенные к этим сетям.
Драйвер Хост
Еще один сетевой драйвер Docker часто используемый в работе – это Хост. При использовании данного драйвера сетевой стек контейнера не изолирован от хоста Docker и контейнер не получает собственный выделенный IP-адрес. Такой режим работы полезен, когда контейнер содержит большое количество открытых портов, используемых в процессе работы, также, когда необходимо оптимизировать производительность. Мы можем оптимизировать производительность за счет отсутствия необходимости в использовании трансляции сетевых адресов (NAT).
Здесь существенным недостатком использования драйвера Хост является возможность его использования только на узлах под управлением Linux. Ни под Mac, ни под Windows мы не сможем использовать данный тип драйверов.
Драйвер Overlay
Драйвер Overlay на сегодняшний день распространен гораздо меньше, чем решения, описанные ранее. Наложенная сеть Overlay — это сетевой драйвер предназначенный для соединения несколько демонов Docker между собой. Такие соединения широко используются для взаимодействия docker-swarm служб. Оверлейные сети также можно использовать для взаимодействия между автономными контейнерами на разных Docker демонах. Благодаря использованию данных драйверов у нас отпадает необходимость в маршрутизации на уровне ОС между этими контейнерами.
Вот пример настройки сети Docker с использованием драйвера Overlay.
docker network create \
--driver overlay \
--ingress \
--subnet=10.11.0.0/16 \
--gateway=10.11.0.2 \
--opt com.docker.network.driver.mtu=1200 \
my-ingressДрайвер Macvlan
Сетевой драйвер, с помощью которого можно назначить MAC-адрес контейнеру, в результате чего он становится виден в сети как физическое устройство. Docker демон направляет трафик на контейнеры по их MAC-адресам. В некоторых случаях использование Macvlan позволяет работать с приложениями, которым необходимо прямое подключение к физической сети.
Заключение
В этой статье мы рассмотрели работу с сетью в Docker, и в частности, поговорили о том, какие драйверы имеются в этой среде виртуализации. В следующей статье мы рассмотрим работу с Docker Compose.
Рекомендую всем желающим посетить открытый урок, на котором рассмотрим основы инструмента Terraform и практику построения облачной инфраструктуры с применением подхода IaC. На этом уроке мы познакомимся с Terraform и научимся применять Terraform на практике (на примере Kubernetes).
Записаться на открытый урок можно на странице курса OTUS «DevOps практики и инструменты».