06-Docker: Сети в докер. Network: bridge, host, none, macvlan, ipvlan

ruticker 04.03.2025 23:47:58

Текст распознан YouScriptor с канала RomNero

распознано с видео на ютубе сервисом YouScriptor.com, читайте дальше по ссылке 06-Docker: Сети в докер. Network: bridge, host, none, macvlan, ipvlan

и мы продолжаем. Сейчас мы рассмотрим одну из самых интересных и сложных тем, которые касаются Docker. Это будет **Docker Network** — сети в Docker. Я думал, что это будет маленькая короткая тема, но нет, она оказалась довольно обширной и интересной. На данном видео не будет много слайдов, но будет много стрелок и прямоугольников. И давайте мы начнем. У нас есть сервер, на котором работает Docker, там работает какой-то Linux, и мы запустили Docker. Мы сразу же получаем новый интерфейс. Я думаю, вы все знаете, когда запустили Docker, мы получаем интерфейс `docker0`. При создании Docker, при запуске, мы получаем несколько типов сетей по умолчанию, которые уже есть. Docker их предоставляет. Это типы сети: **Bridge**, **Host** и **None**. ### Типы сетей - **Bridge** — это тип сети по умолчанию при запуске контейнеров обычным способом `docker run`. В названии образа он попадает в сеть Bridge. Это сеть по умолчанию. Она имеет зачастую по умолчанию сеть `172.17.0.0/16`. Это стоит запомнить, потому что постоянно, когда вы запускаете Docker для теста или чего-то еще, контейнеры все попадают в эту сеть. Контейнеры, которые в этой сети находятся, имеют сразу же доступ наружу, то есть они могут подключаться к другим серверам, могут подключаться к интернету. Также мы можем подключиться к контейнерам локально. Чтобы нам подключиться извне к контейнеру, нам нужно сделать так называемый мостик (Bridge). Поэтому называется это Bridge. Он соединяет сам контейнер, IP-адрес контейнера с IP-адресом сервера. Чтобы нам подключиться к контейнеру, который работает в сети Bridge, нам нужно создать мостик, и этот мостик создается с помощью параметра `-p`, то есть порт mapping, которым мы изучили до этого. Что происходит? У нас получается, мы соединяем порт 80 хоста с портом 80 контейнера. Но это случай, если запускается другая программа, которая имеет графическую оболочку или что-то еще, то порты могут изменяться. Суть в том, что мы создаем так называемый мостик Bridge, и таким образом мы сможем подключиться именно к нашему контейнеру. Если же мы хотим запустить контейнер в сети Host, то нам нужно указать параметр `--network` и указать тип сети Host. Когда контейнеры здесь создаются, они получают IP-адрес именно хоста. Да, они отличаются портами и так далее, но тем не менее, они получают IP-адрес хоста. Эти контейнеры также могут подключаться наружу, выходить в интернет, скачивать что-то еще, передавать какие-то данные. Мы можем к ним подключаться локально, и чтобы нам подключиться к контейнеру, допустим, просто указать IP-адрес самого хоста и указать порт, либо порт не указан, если мы в браузере, то браузер по умолчанию идет на 80 либо 443. Но если нам какой-то контейнер другим портом, то нам стоит указать именно IP-адрес самого сервера. Следующий тип сети — это **None**. Если мы хотим создать контейнеры в сети None, то нам нужно соответственно указать параметр `--network` и тип сети. Но в данном случае мы никак не сможем подключиться к контейнеру извне, то есть у него нет доступа, у него нет IP-адреса. Мы не сможем подключиться к контейнеру локально, потому что также нет у него своего IP-адреса. Но мы сможем зайти на контейнер, подключиться непосредственно к самому контейнеру, не через IP-адрес, не через порт какой-то, посмотреть там, допустим, логи и запустить какие-то программы. Это три основных типа сетей, которые создаются с Docker автоматически. Мы это увидим на практике, но, наверное, было бы довольно просто, если было всего лишь три типа. Поэтому давайте добавим еще следующий тип сети — это **Macvlan** и **IPvlan**. Эти два типа мы рассмотрим немножко позже, я их пока что опущу. Еще один тип — **Overlay**. Он используется, когда Docker запускается в кластере, как кластер. Допустим, используется только Swarm. Этот тип сети я рассматривать не буду, так как мы не будем рассматривать только Swarm, и как бы это немножечко уходит в прошлое. Но тем не менее, стоит знать, если кто-то хочет очень просто использовать кластер, только в кластере, то, конечно, да, только Swarm это прощает много раз. ### Рассмотрим типы сетей Итак, переходим к **Bridge**. Что у нас происходит? У нас есть сервер, где работает Docker, и у нас есть, как я говорил, уже по умолчанию один Bridge — дефолтная сеть, сеть по умолчанию. Если мы запускаем контейнеры, как я уже говорил, обычным образом `docker run` и название образа, создаем контейнер, то он попадает именно в эту сеть, в дефолт. Мы создаем один контейнер, второй контейнер. Как я говорил, эти контейнеры могут выходить наружу, можно к ним подключаться и так далее, создавать мостики такие. Кроме того, данные контейнеры могут общаться между собой. Они получают IP-адреса, какие-то рандомные IP-адреса в этой сети. Они могут общаться именно по IP-адресам между собой, но они не могут общаться между собой, используя свои имена, то есть как бы доменные имена, которые получают они при создании контейнера. Наш сервер также может подключиться к данным контейнерам, и как бы ничего страшного. Но что делать, когда мы убиваем контейнер, заново создаем? Они получают какие-то рандомные снова IP-адреса. Нам было бы удобно использовать именно доменные имена. Нам нужно создать новую сеть. Допустим, создаем тип сети Bridge. Это я за следующим образом: `docker network create`, мы создаем сеть новую, указываем `driver bridge` и указываем имя, которое мы хотим дать нашей сети. Если мы не указываем этот параметр `driver`, то сеть создается автоматически типа Bridge, то есть данная вещь можно опустить. Допустим, мы хотим создать имя `my_net1`. Мы создали новую сеть и хотим запустить контейнер. Чтобы запустить контейнер именно в этой сети, не просто `docker run`, и он запустится в дефолтной сети, а именно в нашей новой сети, нам нужно указать параметр `--net` или `--network` и указать `my_net1` и указать название образа, который мы хотим запустить, допустим, `nginx`. Мы запустили два контейнера, то в этой сети уже эти контейнеры могут общаться между собой. Допустим, этот контейнер — приложение Nginx, а вторая база данных. Допустим, так как контейнер в этой сети получает свои IP-адреса, там `172.17` и так далее, они могут общаться по адресам и также могут общаться по DNS именам. Это те имена, которые мы указываем, допустим, в параметре `--name` и название контейнера, либо если мы этого не делаем, то Docker присваивает какое-то имя контейнеру. Таким образом, мы можем использовать это имя для подключения к контейнерам и также можем подключаться к этим контейнерам локально. Но мы можем между ними общаться. Но две сети — дефолтная сеть и наша сеть — они между собой общаться не могут. Давайте посмотрим, если мы создадим еще одну сеть, также свою дефолтную, назовем ее `my_net2`. Создадим там два контейнера, то в этом случае мы также, к сожалению, сможем соединить две сети `my_net1` и `my_net2`. Это хорошо тем, что мы можем изолировать два приложения полностью, добавляя какую-то безопасность этим контейнерам. ### Сеть Host Мы тоже можем локально. В следующую сеть — сеть Host. Она создается также, указывается драйвер Host на и название сети. Что здесь происходит? Если мы создали данную сеть, у нас есть сервер с Docker, мы создадим два контейнера, то эти контейнеры могут общаться между собой, и также сервер можно к ним подключаться непосредственно. Эти контейнеры, которые здесь создаются, получают свои IP-адреса, они используют IP-адрес именно самого хоста, поэтому называется сеть Host. Если мы хотим подключиться к какому-то из контейнеров извне, то нам нужно указывать именно IP-адрес нашего сервера. Следующий тип сети — это None. Это довольно-таки самый простой тип, который в принципе редко очень используется. Он создается с помощью драйвера None. Что происходит? У нас есть сервер с Docker, и сотни два контейнера. Как картинки уже можно понять, что эти контейнеры изолированы сами по себе. Да, мы не можем непосредственно подключиться к ним, то есть по IP-адресам, к портам, но мы можем запустить на них какие-то команды локально и так далее. Я думаю, это более-менее понятно с контейнерами. Это три основных типа, в основном используемых, наверное, в 95% случаев. Используется тип Bridge, иногда используется тип Host. Также существуют два типа, которые очень интересные именно со стороны сетей — это **Macvlan** и **IPvlan**. Давайте представим, у нас есть сервер Docker Host, и как и все сервера, у нас есть IP-адрес, у нас есть сетевая карточка 0 с таким IP-адресом. Если мы уже говорим о IPvlan, то приходит на ум, что это что-то сети связано именно с VLAN. Когда мы говорим о сети, то стоит отобразить сетевое оборудование. Я отображу здесь Switch. Так, им на Switch работает с VLAN, и понятно дело, что через Switch идет подключение к нашему серверу. Давайте мы запустим два контейнера именно в сети Macvlan. Что происходит? Данные контейнеры получают свои сетевые карточки и также, соответственно, свои IP-адреса. Вот, и мы уже непосредственно можем подключиться сразу же по IP-адресу без указания портов. Ну или указывать порты, если это нужно, но тем не менее, можно непосредственно подключиться именно к контейнерам. При создании контейнеров сети происходит следующее: сервер имеет свою сетевую карточку, карта имеет свой MAC-адрес, допустим, он у сервера вот такой. Контейнеры в этой сети получают свои MAC-адреса, что упрощает намного маршрутизацию. На свитче он знает уже непосредственно, где находится какой адрес и так далее, и идет подключением непосредственно к контейнерам. Что происходит с типом сети IPvlan? У нас также есть сервер с IP-адресом, также контейнеры в этой сети получают свои IP-адреса, но MAC-адрес остается без изменений, то есть контейнеры получают и на сетевые карты контейнера получают те же MAC-адреса, что и наш сервер. Вот, и подключение происходит таким же обычным образом. ### Практика Вот так мы разобрали все типы сети, которые используются в Docker. Давайте перейдем к практике, посмотрим, как это все работает, создадим пару сетей и что будет делать именно контейнер. Переходим на сервер, именно на сервере, где работает Docker. Давайте посмотрим на сервере, какие сетевые интерфейсы у нас есть. Пишем `ip a` и видим, что у нас есть интерфейс `ens18` — это сетевая карточка виртуальной машины, да, и с локальным IP-адресом. И также сетевая карточка Docker как виртуальная карточка. У нас есть в Docker также IP-адрес, и указывается маска сети. Хорошо, давайте посмотрим. У нас есть типы сетей в Docker. Пишем `docker network ls`, и мы видим, у нас есть три типа сетей: это Bridge, Host и None. Понятно, это стандартные все вещи, которые создаются при установке Docker. Создадим свою собственную сеть. Итак, пишем `docker network create`, мы хотим создавать сеть, поэтому `network create`, пишем дальше `my_net01`, допустим. Хорошо, давайте посмотрим, что у нас появилось. `docker network ls`, и у нас наша новая сеть появилась с драйвером Bridge. Как я говорил, что сеть, если вы создаете без каких-либо параметров, без указания драйвера, она появляется сразу автоматически с драйвером Bridge. А что будет, если мы создадим драйвером Host? Давайте попробуем. `docker network create --driver host my_net_host`. И видите, сейчас что получится? Вот, мы не можем создавать больше одной сети типа Host, потому что все контейнеры, которые создаются на сервере в этой сети, они создаются как бы как будто вы установите программу на сам сервер. То есть этот контейнер будет использовать вот этот интерфейс. Вот поэтому только один возможный. Хорошо, поехали дальше. Теперь давайте создадим драйвер None, то есть не Null, а None, то есть пустота. `docker network create --driver none my_net_none`. Вот так, и мы видим, что также мы не можем создать больше одной сети типа None, потому что все контейнеры в этой сети, они также ничего не спустят, не пустят, не используют. То есть мы просто контейнеры и не создаются без ничего пустые. Хорошо, мы создали какую-то сеть, она как-то работает. Хорошо, давайте немножечко посмотрим. Вот, допустим, на сервере у нас есть какая-то сеть, мы ничего не знаем, как нам быть, как нам узнать информацию об этом. Пишем `docker network inspect` и указываем либо имя сети, либо Network ID, нажимаем Enter, и мы видим здесь как бы настройка самой сети, как она будет настраивать `172.19.0.0/16`. Ну и небольшой информации еще о сети самой. Вот таким образом вы сможете узнать, не запуская контейнеров, какая сети здесь настроена, с какими параметрами. Это такая вот маленькая информация. Далее давайте начнем мы создавать контейнеры и пробовать, как-нибудь работать. Но перед этим давайте мы создадим какую-то не дефолтную сеть, то есть мы создали просто, мы создали сеть, которая типа Bridge, но мы хотим указать, какие IP-адреса мы хотим именно использовать. Как это можно сделать? Давайте сделаем. Пишем `docker network create --driver bridge --subnet 192.168.10.0/24 --gateway 192.168.10.1 my_net192`. Вот как по названию наш момент. Отлично, сеть осталась. Мы можем уже сами указывать, что мы хотим создавать. Это прекрасно, вообще очень удобно. Пишем `docker network inspect my_net192`, и вот наша сеть. Таким образом, мы создаем свои собственные сети. Хорошо, допустим, мы насоздавали этих сетей очень большое количество, создавали контейнеры и так далее, и видим, что нам эти сети вообще не нужны абсолютно, вот эти вот локальные такие маленькие сети. Как нам быть? Просто их можем удалить. Для этого стоит только `docker network rm` и далее указать название сети, либо также `docker network prune`, и все, они удалились. У нас этого больше ничего нет. Все прекрасно. Давайте теперь перейдем все же к анализу, как нам делать контейнеры, чтобы они правильно корректно все работали. Итак, давайте для этого в основном определенные контейнеры, чтобы могли анализировать. Почему нельзя взять обычный контейнер, допустим, Ubuntu, либо Nginx, либо какой-либо другой? Потому что основа контейнеров Docker — это как можно маленький контейнер иметь, как можно маленький образ. То есть он уже работает только с одной программой, для которой он предназначен. Поэтому возьмем контейнер, который предназначен для анализа сетей, то есть в нем уже есть все утилиты, которые делают это возможно. Я нашел два контейнера, в которых уже есть предусмотрены все утилиты для анализа сети — это `nmap` и второй — это `netshoot`. Ну давайте будем использовать `netshoot`, так как здесь больше всего скачиваний — 50+ миллионов, а в этом контейнере 100 тысяч плюс. Ну как бы оба они хороши, и нам будет достаточно любого из них. Возьмем `netshoot`, и если снизу посмотреть, как он запускается, то вот такими вот командами мы можем запускать наши контейнеры. Так, если мы сделаем просто `docker run` и наш контейнер, сейчас и вставим наш контейнер, запустим наш контейнер, только бы у нас ничего интересного получилось. Он работать не будет, потому что в нем не работает никакая программа. Посмотрим, это проверим. Ничего не работает. Вот, то есть он сразу же останется, он запустился и остановился. Нам это не нужно. Давайте его удалим. Хорошо, и давайте теперь все-таки запустим правильно. Так, давайте пишем `docker run -it --name container1 nicolaka/netshoot`. Мы должны его запустить в интерактивном режиме, чтобы сразу в нем войти и можно в нем работать было. Далее укажем ему имя, чтобы не путаться, допустим, `container1`. Ну и теперь указываем наш контейнер, то есть наш, который хотим запустить. При этом подключимся, это будет `nicolaka/netshoot`. Если мы запустим контейнер, то у нас запустился контейнер, который для анализа нашей сети. Если мы введем команду `ip a`, то мы посмотрим IP-адреса, которые уже есть в контейнере, и мы видим, у нас есть IP-адрес `172.17.0.2`. Также можно попробовать сделать `ping google.com`, и мы видим, что пинг у нас также работает отлично. Но для анализа сети между контейнерами нам хорошо бы использовать второй контейнер. Поэтому давайте сейчас я расстелю экран, и чтобы нам было сразу видно оба контейнера, так будет удобно. Давайте запустим второй контейнер. Будем использовать такую же команду, как и до этого. Копируем ее, вставляем и давайте немножко изменим, чтобы был имя контейнера номер два. Так, запускаем второй контейнер, посмотрим, какой адрес у нас есть. У нас в конце тройка, здесь у нас двойка. И давайте посмотрим, сможем ли мы сделать с одного сервера на второй. Давайте попробуем. Здесь пишем `ping 172.17.0.3`. Отлично, пинг у нас работает. И можно сработает DNS, то есть можем ли мы сделать пинг именно не по IP-адресу, а подключиться непосредственно к самому контейнеру, сделать пинг по его имени, как минимум, если контейнер называется `container2`. Давайте посмотрим. Делаем `ping container2`. К сожалению, мы это сделать не можем. Дома можем подключаться между контейнерами по их адресам, это прекрасно. Хорошо, давайте еще проанализируем, в какой сети они находятся. То есть если вы, допустим, не знаете, в какой сети находится какой-то контейнер. Давайте с одного мы выйдем, посмотрим, какие контейнеры у нас работают. У нас есть один контейнер, но как мы видим, здесь не указывается нигде IP-адрес. Как нам в этом случае быть? Пишем `docker inspect` и уже указываем имя контейнера, либо ID, ну в основном контейнер. Хорошо, мы зашли на сам контейнер, и давайте здесь сразу видно, у нас IP-адрес контейнера, его Gateway и так далее. То есть так мы можем проанализировать, в какой сети находится тот либо другой контейнер. Хорошо, мы сейчас выяснили, что у нас не работает привязка по DNS. Как нам в этом случае быть? Мы можем создать свою собственную сеть и потом добавить туда контейнеры, либо еще проще, еще изначально создавать сеть, а потом уже запускать контейнеры уже в нужной сети. Давайте сделаем сеть `docker network create my_net01`. Хорошо, она создала сеть. Можно проверить `docker network ls`, она создала сеть `my_net01` и драйвер Bridge. Давайте запустим те же контейнеры, только уже в этой сети. Давайте возьмем наш контейнер, имя контейнера у нас был `container1`, далее укажем `--net` и далее указываем имя сети, где мы хотим запустить его. Все, запускаем. `docker run -it --name container1 --net my_net01 nicolaka/netshoot`. Отлично, контейнер работает. Посмотрим, вот у нас видите, уже не `172.17`, здесь, а уже `172.20.0.2`. И здесь мы сделаем то же самое, только контейнер `container2` назовем. Это один контейнер, `container2`. Готово. Посмотрим действие адреса, все есть, мы в одинаковой сети находимся. Попробуем сделать пинг. Это работает. Также будет здесь тоже самое работать. Все есть. А теперь сможем ли мы сделать пинг по имени? `ping container2`, и у нас тоже это все работает. Вот так очень легко связать контейнеры, что не нужно указывать какой IP-адрес сейчас какого-то контейнера есть, просто запускаете, ни о чем не думайте, и все, можно по имени к нему подключаться. Все хорошо, это прекрасно работает. Что будет, если мы запустили контейнеры, они уже работают, мы не хотим их там убивать, как-то перебивать и так далее, как на них переместить в другую сеть? Ну давайте попробуем сделать. Давайте убьем этот контейнер, и давайте его запустим без указания какой-либо сети. Хорошо, посмотрим IP-адрес. У нас IP-адрес, и снова `172.17`. Проверим, что мы не можем к нему подключиться. Да, у вас нет к нему доступа. Но нам хочется этот контейнер переместить в ту же сеть, где находится этот контейнер. Как нам быть? Допустим, у нас это веб-сервер, это у нас база данных. Давайте попробуем сделать. Нам нужно сейчас убить будет один контейнер. Ну ладно, допустим, он будет работать дальше, мы будем снимать контейнер. Остается работать вот этот вот верхний, то как `ping`. И вот вы видите, наш контейнер 2, который мы запускали сверху. Что ж, дальше пишем `docker network connect my_net01 container2`, то есть мы хотим подключить к нашей сети, которая у нас указывалась `my_net01`, и мы хотим подключить контейнер `container2`. Все, посмотрим, Docker у нас контейнер также работает по-прежнему. Посмотрим здесь IP-адреса, и мы видим, что мы находимся сейчас в двух сетях. Это тоже неплохо, но от старости мы хотим отключиться. Давайте посмотрим, если мы сделаем `docker inspect` нашего контейнера, то мы здесь увидим Network ID. Это вот новая сеть, в которой мы находимся, вот `172.20`, и сверху будет наша старая сеть, то есть мы можем использовать именно вот этот Network ID для того, чтобы отключиться от сети. И мы здесь выше видим, у нас тип Bridge. То есть у нас две сети — вот первая сеть типа Bridge и вот вторая сеть типа Bridge, но у нее название есть `my_net01`. Что ж, мы отключимся от этой сети. Нам нужно для этого `docker network disconnect` и указываем Network ID. Давайте уберем так и название контейнера. Прекрасно, ошибок нет. Хорошо, посмотрим, какие IP-адреса у нас теперь остались, и у нас есть только один IP-адрес. Вот так мы можем передвигать контейнеры с одной сети в другую, и при этом они остаются работать. Может, в один контейнер мы можем получить ко многим сетям, очень многим. Это очень удобно, когда, допустим, у нас работает прокси-сервер, и у нас также есть много сетей, много маленьких контейнеров, которые находятся за прокси, и мы просто прокси получаем к каждому, к каждой сети, где работает маленький контейнер. Это повышает намного безопасность. Сами контейнеры между собой разговаривать не могут, естественно, не могут через прокси выходить, тем не менее, они могут непосредственно друг с другом работать. Это намного лучше, чем они находились просто в одной сети. Я думаю, сами будет понятно. Давайте посмотрим на схему, которую мы видели. У нас есть, мы это рассмотрели, у нас из контейнеров в сети по умолчанию, где мы могли делать пинг, но у нас не было DNS. DNS у нас не работал. Здесь также мы создали нашу одну сеть, и давайте сейчас создадим еще одну сеть и посмотрим, сможем ли мы между собой это все запускать. Думаю, вы же тогда, что мы этого делать не сможем, но давайте попробуем. Давайте снова создадим `my_net02`, то есть мы не собьем изначально некую сеть, мы просто указываем в команде при запуске контейнера, какую сеть мы хотим поместить. Наш новый контейнер создаст ли Docker нам новую сеть? Нет, увы, это так не работает, у нас вышла ошибка. Поэтому будем создавать `docker network create` и создадим вторую сеть. Все, сеть создалась. `docker network ls`, и у нас есть `my_net01`, `my_net02` и также типа Bridge. Хорошо, теперь давайте возьмем снова нашу команду и запустим. Посмотрим, IP-адрес у нас IP-адрес совершенно другой контейнер. Соответственно, мы не сможем никак сделать пинг. Ну давайте посмотрим, вдруг маршрутизация сработает. `ping`? Нет, это не работает. Это что доказывает, что стоит каждое приложение запускать в отдельно для него сети, чтобы все приложения, все контейнеры работали отдельно друг от друга. Это довольно-таки важно. Ну и давайте для наглядности просто запустим теперь контейнеры в разных сетях. Мы сейчас тип Host и тип None, то есть без сети. Посмотрим, что будет. Выходим с этих контейнеров, они удаляются сразу же. Давайте посмотрим на сети. Есть `docker network ls`, и запустим тип Host. Давайте воспользуемся нашей предыдущей командой `docker run -it --network host --name container_host nicolaka/netshoot`. Хорошо, посмотрим, что у нас есть, и я вам сейчас покажу, что это такое. Вот, как бы мы видим сейчас много интерфейсов. Мы видим также интерфейс нашего хоста. Мы сейчас находимся на самом хосте. Давайте посмотрим, какие интерфейсы там есть, и как бы мы видим, что у нас то же самое, если в контейнере. Вот, ведь еще у нас показывается сеть, которую мы создавали, наши кастомные сети `172.20`, где были созданы контейнеры, вот `172.17` по умолчанию, вот `my_net02`, наш который мы создавали, и также мы видим в этом контейнере, который мы запускали, именно сетевую карточку самого хоста. Давайте запустим еще два контейнера также в сети Host. Итак, мы продолжаем. Давайте подытожим, что мы узнали о сетях в Docker. Мы рассмотрели основные типы сетей: **Bridge**, **Host**, **None**, а также более сложные типы, такие как **Macvlan** и **IPvlan**. ### Основные типы сетей 1. **Bridge** — сеть по умолчанию, которая позволяет контейнерам общаться друг с другом и с внешним миром через NAT. 2. **Host** — контейнеры используют сетевой стек хоста, что позволяет им работать как локальные приложения. 3. **None** — контейнеры не имеют сетевого интерфейса и не могут общаться ни с чем. 4. **Macvlan** — позволяет контейнерам иметь свои собственные MAC-адреса и IP-адреса, что упрощает маршрутизацию. 5. **IPvlan** — контейнеры получают IP-адреса, но используют MAC-адреса хоста. ### Практическое использование Мы создали несколько сетей, используя команды Docker, и запускали контейнеры в этих сетях. Мы также узнали, как управлять сетями, подключать и отключать контейнеры от сетей, а также как настраивать IP-адреса для контейнеров. ### Пример создания сети Macvlan ```bash docker network create --driver macvlan \ --subnet=192.168.100.0/24 \ --gateway=192.168.100.1 \ --ip-range=192.168.100.99/32 \ -o parent=ens18 my_macvlan ``` После создания сети мы запустили контейнеры с конкретными IP-адресами, что позволяет нам управлять сетевыми настройками более гибко. ### Проверка работы Мы проверили, что контейнеры могут пинговать друг друга и что IP-адреса назначаются корректно. Это позволяет нам использовать Docker для создания сложных сетевых приложений, таких как фаерволы и прокси-серверы. ### Заключение Сети в Docker — это мощный инструмент для управления сетевыми взаимодействиями между контейнерами. Мы рассмотрели основные типы сетей и их применение, а также научились настраивать сети под свои нужды. Теперь вы можете экспериментировать с созданием и управлением сетями в Docker, чтобы лучше понять, как они работают. Спасибо за внимание, продолжаем!

Назад

Залогинтесь, что бы оставить свой комментарий