Visitors have accessed this post 2684 times.

Работа с сетью в Docker

8
0
2684
6 ноября 2020 11:06
Автор: Rebrain Me
Docker

Visitors have accessed this post 2684 times.

В Docker, как правило, работа с сетью не представляет из себя больших сложностей — она неплохо работает и по умолчанию. Но, как и в подавляющем большинстве случаев, полезно понимать, как все устроено «под капотом».

Разбираемся с сетью в Docker

Для начала давайте посмотрим, как настроена сетевая модель Docker по умолчанию. То есть, когда вы просто создаете контейнер, ему присваивается адрес и есть возможность для доступа в интернет без всяких дополнительных усилий с вашей стороны.

Для этого в Docker используется сетевой мост (bridge), обычно его имя в системе —  docker0. Для каждого контейнера создается свой виртуальный сетевой интерфейс, он и подключается к сети при помощи bridge.

На схеме подключение выглядит следующим образом:

| Приложение -> ethernet -> | -> virtual ethernet -> bridge -> ethernet/wifi interface |

| Контейнер                 | Хост                                                     |

Метод сетевого моста достаточно универсален для виртуальных машин, так как он простой и удобный.

Но в некоторых случаях вам могут понадобиться и другие методы для сетевого подключения или, иначе говоря, networking в docker.

В Docker по умолчанию представлены сетевые драйвера:

  • bridge — о нем мы говорили чуть ранее.
  • macvlan — контейнер подключается при помощи виртуального интерфейса, подключенного к физическому. При этом у каждого из них есть свой MAC-адрес.
  • host — как видно из названия, в этом случае подключение происходит к сети хоста. Это значит, что контейнер может общаться с сервисами, которые запущены на локальном интерфейсе так, как если бы он был запущен прямо на хосте.
  • none — означает, что сети нет.

Еще стоит отметить, что у Docker существуют дополнительные плагины, с которыми можно расширить этот список и его возможности.

Команды для работы с сетью в Docker

Для работы с сетью Docker используется команда network.

Чтобы просмотреть network в docker введите docker network ls. И вы сможете увидеть в форме списка все существующие сети  Docker.

Для получения расширенной информации о сети используется команда docker network inspect (инспектор network в Docker).

Если вам нужно создать сеть для нескольких приложений, чтобы они могли общаться с хостом и между собой, вам пригодится команда docker network create — чтобы создать network в Docker с нужным драйвером и параметрами.

Посмотрим на создание сети на примере:

docker network create -d bridge rbm

Здесь мы создаем сеть типа bridge и указываем драйвер при помощи параметра -d. Но в этом примере есть небольшой подвох. Как вы помните, драйвер bridge и так используется по умолчанию, поэтому указывать его дополнительно вовсе не обязательно. А вот если вы применяете другой драйвер — без -d вам не обойтись.

Чтобы подключить/Отключить контейнер(ы) к/от сети в Docker, вам будут нужны команды docker network connect (для подключения) и docker network disconnect (для отключения, соответственно). Также обязательно указать сеть и контейнер, с которыми будете взаимодействовать.

Ну и вы уже, конечно, догадались, как происходит удаление Network в Docker — docker network rm. А команда docker network prune удалит сети без подключенных контейнеров.

Взаимодействие контейнеров в сети

Давайте посмотрим, как происходит общение контейнеров по сети.

Для этого стоит

  • создать 2 контейнера (один из них — допустим, container1 — нужно запустить в интерактивном режиме);
  • узнать при помощи команды docker inspect IP-адрес контейнера, запущенного не в интерактивном режиме (container2);
  • проверить доступность container2 из оболочки container1 при помощи ping;
  • вы увидите, что между контейнерами происходит общение по IP-адресу.

Чтобы общение происходило через DNS, вам нужно создать новую сеть, имя которой будет отличаться от bridge, так как у сети по умолчанию bridge такой возможности не предусмотрено.

Чтобы обратиться к хосту из bridge, вам понадобится default gateway — его вы можете найти в inspect — это адрес, по которому происходит обращение к хосту.

Для обратного обращения — от хоста к контейнеру — можно пробросить порты, а можно воспользоваться тем же адресом, о котором мы говорили выше. Он доступен с хоста.

Заключение

Работа с сетью в Docker — это не самый сложный кейс. Но как и в большинстве случаев тут многое решает практика. Так что пробуйте и задавайте вопросы, если таковые будут.

От редакции

Если вам интересно посещать бесплатные онлайн-мероприятия по DevOps, Kubernetes, Docker, GitlabCI и др. и задавать вопросы в режиме реального времени, подключайтесь к каналу DevOps by REBRAIN

*Анонсы мероприятий каждую неделю

Практикумы для специалистов по инфраструктуре и разработчиков — https://rebrainme.com.

Наш Youtube-канал — https://www.youtube.com/channel/UC6uIx64IFKMVmj12gKtSgBQ.

Агентство Fevlake, проектируем и поддерживаем IT-инфраструктуры с 2012 года — https://fevlake.com.

Комментарии (3)
Введено символов из возможных
Не отвечать

Вам также может понравится

Утилита для удаленного обслуживания систем на базе ОС NixOS — nixops
array(1) { [0]=> object(WP_Term)#11785 (16) { ["term_id"]=> int(6) ["name"]=> string(5) "Linux" ["slug"]=> string(5) "linux" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(6) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(28) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(6) ["category_count"]=> int(28) ["category_description"]=> string(0) "" ["cat_name"]=> string(5) "Linux" ["category_nicename"]=> string(5) "linux" ["category_parent"]=> int(0) } } Linux

Автор - Юрий Изоркин

Сегодня давайте познакомимся с утилитой nixops для удаленного обслуживания систем на базе ОС NixOS. Также она поддерживает развертывание систем на VirtualBox VM, Amazon EC2, Google Compute Engine, Microsoft Azure, Hetzner physical machines, Digital Ocean, Libvirtd (Qemu), Datadog resources. Подробнее об этих возможностях...

1
2
18 декабря 2020
Чем HighLoad отличается от DevOps
array(1) { [0]=> object(WP_Term)#976 (16) { ["term_id"]=> int(9) ["name"]=> string(8) "HighLoad" ["slug"]=> string(8) "highload" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(9) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(3) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(9) ["category_count"]=> int(3) ["category_description"]=> string(0) "" ["cat_name"]=> string(8) "HighLoad" ["category_nicename"]=> string(8) "highload" ["category_parent"]=> int(0) } } HighLoad

Если вы зайдете на hh и напишите в поисковой строке HighLoad или «высокие нагрузки», результаты поиска вас удивят. «Чистых» вакансий по высоким нагрузкам практически нет. Как правило, задачи HighLoad упоминаются в обязанностях DevOps-инженеров (правда, чаще это матерые спецы уровня Senior) или backend-разработчиков. Поэтому очень часто происходит...

0
1
4 декабря 2020
HighLoad архитектура для веб-приложения – все ли тут просто и однозначно?
array(1) { [0]=> object(WP_Term)#11786 (16) { ["term_id"]=> int(9) ["name"]=> string(8) "HighLoad" ["slug"]=> string(8) "highload" ["term_group"]=> int(0) ["term_taxonomy_id"]=> int(9) ["taxonomy"]=> string(8) "category" ["description"]=> string(0) "" ["parent"]=> int(0) ["count"]=> int(3) ["filter"]=> string(3) "raw" ["cat_ID"]=> int(9) ["category_count"]=> int(3) ["category_description"]=> string(0) "" ["cat_name"]=> string(8) "HighLoad" ["category_nicename"]=> string(8) "highload" ["category_parent"]=> int(0) } } HighLoad

Тема высоких нагрузок будоражит умы не хуже тайны бермудского треугольника. Вроде все знают, что современные маркетплейсы, сайты объявлений, соцсети - это тот самый пресловутый HighLoad, но чего там, собственно, “под капотом” и как оно настраивается, - это уже совсем другой уровень абстракций.  

На hackernoon.com нам встретилась статья о...

0
0
9 октября 2020