Сети docker изнутри: как docker использует iptables и интерфейсы linux / хабр

Use an overlay network for standalone containers

This example demonstrates DNS container discovery — specifically, how to
communicate between standalone containers on different Docker daemons using an
overlay network. Steps are:

On , initialize the node as a swarm (manager).
On , join the node to the swarm (worker).
On , create an attachable overlay network ().
On , run an interactive alpine container () on .
On , run an interactive, and detached, alpine container () on .
On , from within a session of , ping .

Prerequisites

For this test, you need two different Docker hosts that can communicate with
each other. Each host must have the following ports open between the two Docker
hosts:

TCP port 2377
TCP and UDP port 7946
UDP port 4789

One easy way to set this up is to have two VMs (either local or on a cloud
provider like AWS), each with Docker installed and running. If you’re using AWS
or a similar cloud computing platform, the easiest configuration is to use a
security group that opens all incoming ports between the two hosts and the SSH
port from your client’s IP address.

This example refers to the two nodes in our swarm as and . This
example also uses Linux hosts, but the same commands work on Windows.

Walk-through

Set up the swarm.

a. On , initialize a swarm (and if prompted, use
to specify the IP address for the interface that communicates with other
hosts in the swarm, for instance, the private IP address on AWS):

b. On , join the swarm as instructed above:

If the node fails to join the swarm, the command times
out. To resolve, run on , verify your
network and firewall settings, and try again.
On , create an attachable overlay network called :
On , start an interactive () container () that connects to :
On , list the available networks — notice that does not yet exist:
On , start a detached () and interactive () container () that connects to :
On , verify that was created (and has the same NETWORK ID as on ):
On , ping within the interactive terminal of :

The two containers communicate with the overlay network connecting the two
hosts. If you run another alpine container on that is not detached,
you can ping from (and here we add the
for automatic container cleanup):
On , close the session (which also stops the container):
Clean up your containers and networks:

You must stop and remove the containers on each host independently because
Docker daemons operate independently and these are standalone containers.
You only have to remove the network on because when you stop
on , disappears.

a. On , stop , check that was removed, then remove :

a. On , remove and :

Обходные пути известных проблем в Windows Server 2016

Несмотря на то что мы продолжаем разрабатывать и добавлять новые функции, некоторые из них не будут перенесены на платформы предыдущих версий. Поэтому в этом случае пользователям лучше всего получить последние обновления для Windows 10 и Windows Server. В разделе ниже перечислены некоторые способы обхода известных проблем и оговорки, применимые к Windows Server 2016 и более ранним версиям Windows 10 (т. е. к версиям до обновления Creators Update 1704)

Несколько сетей NAT на узле контейнера WS2016

Разделы для новых сетей NAT должны быть созданы в префиксе более крупной внутренней сети NAT. Чтобы найти префикс, запустите следующую команду из PowerShell со ссылкой на поле InternalIPInterfaceAddressPrefix.

Например, внутренний префикс сети NAT узла может быть 172.16.0.0/16. В этом случае DOCKER можно использовать для создания дополнительных сетей NAT, если они являются подмножеством префикса 172.16.0.0/16. Например, можно создать две сети NAT с префиксами IP 172.16.1.0/24 (шлюз, 172.16.1.1) и 172.16.2.0/24 (шлюз, 172.16.2.1).

Созданные сети можно перечислить при помощи следующих элементов.

Docker Compose

Docker Compose можно использовать для определения и настройки сетей контейнера вместе с контейнерами и службами, которые будут использовать эти сети. Ключ «networks» Compose используется как ключ верхнего уровня при определении сетей, к которым будут подключены контейнеры. Например, в синтаксисе ниже определена существующая сеть NAT, создаваемая Docker в качестве сети по умолчанию для всех контейнеров и служб, определенных в указанном файле Compose.

Аналогично можно использовать следующий синтаксис для определения пользовательской сети NAT.

Более подробная информация об определении и настройке сетей контейнера при помощи Docker Compose см. в справочнике по файлам Compose.

Команды для работы с сетью в 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 удалит сети без подключенных контейнеров.

Communicate between a container and a swarm service

In this example, you start two different containers on the same Docker
host and do some tests to understand how they communicate with each other. You
need to have Docker installed and running.

Open a terminal window. List current networks before you do anything else.
Here’s what you should see if you’ve never added a network or initialized a
swarm on this Docker daemon. You may see different networks, but you should
at least see these (the network IDs will be different):

The default network is listed, along with and . The
latter two are not fully-fledged networks, but are used to start a container
connected directly to the Docker daemon host’s networking stack, or to start
a container with no network devices. This tutorial will connect two
containers to the network.
Start two containers running , which is Alpine’s default shell
rather than . The flags mean to start the container detached
(in the background), interactive (with the ability to type into it), and
with a TTY (so you can see the input and output). Since you are starting it
detached, you won’t be connected to the container right away. Instead, the
container’s ID will be printed. Because you have not specified any
flags, the containers connect to the default network.

Check that both containers are actually started:
Inspect the network to see what containers are connected to it.

Near the top, information about the network is listed, including
the IP address of the gateway between the Docker host and the
network (). Under the key, each connected container
is listed, along with information about its IP address ( for
and for ).
The containers are running in the background. Use the
command to connect to .

The prompt changes to to indicate that you are the user within
the container. Use the command to show the network interfaces
for as they look from within the container:

The first interface is the loopback device. Ignore it for now. Notice that
the second interface has the IP address , which is the same
address shown for in the previous step.
From within , make sure you can connect to the internet by
pinging . The flag limits the command two two
attempts.
Now try to ping the second container. First, ping it by its IP address,
:

This succeeds. Next, try pinging the container by container
name. This will fail.
Detach from without stopping it by using the detach sequence,
+ + (hold down and type followed by ).
If you wish, attach to and repeat steps 4, 5, and 6 there,
substituting for .
Stop and remove both containers.

Remember, the default network is not recommended for production. To
learn about user-defined bridge networks, continue to the
.

Определение службы приложений

Напомним, что эту команду вы использовали для определения контейнера приложения (замените в Windows PowerShell символы на символы ).

Сначала определите запись службы и образ для контейнера. Для службы можно выбрать любое имя. Имя будет автоматически преобразовано в сетевой псевдоним, что будет полезно при определении службы MySQL.
Как правило, команда будет похожа на определение , хотя для упорядочивания нет требований. Итак, добавьте это в файл.
Перенесите часть команды , определив параметры службы. Здесь мы будем использовать , но также доступен более подробный .
Затем перенесите рабочий каталог () и сопоставление томов () с помощью определений и . Для томов также существует и синтаксис.

Одним из преимуществ определений томов Docker Compose является использование относительных путей из текущего каталога.
Наконец, перенесите определения переменных среды с помощью ключа .

Определение службы MySQL

Теперь пора определить службу MySQL. Для этого контейнера использовалась следующая команда (замените в Windows PowerShell символы на символы ).

Сначала определите новую службу и назовите ее , чтобы она автоматически получила сетевой псевдоним. Укажите также используемый образ.
Затем определите сопоставление томов. При запуске контейнера с помощью команды именованный том создавался автоматически. Однако это не происходит при запуске через Compose. Необходимо определить том в разделе верхнего уровня , а затем указать точку подключения в конфигурации службы. Если указать только имя тома, будут использоваться параметры по умолчанию. Но есть и .
Наконец, осталось указать переменные среды.

На этом этапе полный файл должен выглядеть следующим образом.

Examples

Connect containers

When you start a container, use the flag to connect it to a network.
This example adds the container to the network:

If you want to add a container to a network after the container is already
running, use the subcommand.

You can connect multiple containers to the same network. Once connected, the
containers can communicate using only another container’s IP address or name.
For networks or custom plugins that support multi-host connectivity,
containers connected to the same multi-host network but launched from different
Engines can also communicate in this way.

You can disconnect a container from a network using the command.

Specify advanced options

When you create a network, Engine creates a non-overlapping subnetwork for the
network by default. This subnetwork is not a subdivision of an existing
network. It is purely for ip-addressing purposes. You can override this default
and specify subnetwork values directly using the option. On a
network you can only create a single subnet:

Additionally, you also specify the and
options.

If you omit the flag the Engine selects one for you from inside a
preferred pool. For networks and for network driver plugins that
support it you can create multiple subnetworks. This example uses two
subnet mask to adhere to the current guidance of not having more than 256 IPs in
a single overlay network. Each of the subnetworks has 126 usable addresses.

Be sure that your subnetworks do not overlap. If they do, the network create
fails and Engine returns an error.

Bridge driver options

When creating a custom network, the default network driver (i.e. ) has
additional options that can be passed. The following are those options and the
equivalent docker daemon flags used for docker0 bridge:

Option	Equivalent	Description
	—	Bridge name to be used when creating the Linux bridge
		Enable IP masquerading
		Enable or Disable Inter Container Connectivity
		Default IP when binding container ports
		Set the containers network MTU
	—	Set a custom prefix for container interfaces

The following arguments can be passed to for any
network driver, again with their approximate equivalents to .

Argument	Equivalent	Description
	—	IPv4 or IPv6 Gateway for the master subnet
		Allocate IPs from a range
	—	Restrict external access to the network
		Enable IPv6 networking
		Subnet for network

For example, let’s use or options to specify an IP address binding
when publishing ports:

Network internal mode

By default, when you connect a container to an network, Docker also
connects a bridge network to it to provide external connectivity. If you want
to create an externally isolated network, you can specify the
option.

Network ingress mode

You can create the network which will be used to provide the routing-mesh in the
swarm cluster. You do so by specifying when creating the network. Only
one ingress network can be created at the time. The network can be removed only
if no services depend on it. Any option available when creating an overlay network
is also available when creating the ingress network, besides the option.

IP address and hostname

By default, the container is assigned an IP address for every Docker network it
connects to. The IP address is assigned from the pool assigned to
the network, so the Docker daemon effectively acts as a DHCP server for each
container. Each network also has a default subnet mask and gateway.

When the container starts, it can only be connected to a single network, using
. However, you can connect a running container to multiple
networks using . When you start a container using the
flag, you can specify the IP address assigned to the container on
that network using the or flags.

When you connect an existing container to a different network using
, you can use the or flags on that
command to specify the container’s IP address on the additional network.

In the same way, a container’s hostname defaults to be the container’s ID in
Docker. You can override the hostname using . When connecting to an
existing network using , you can use the
flag to specify an additional network alias for the container on that network.

Основы сети Docker

Как мы уже говорили ранее, когда мы устанавливаем приложение docker, автоматически добавляется виртуальная сетевая карта docker 0. На основе сетевой карты docker0 для созданного контейнера предоставляются три дополнительных типа сети: мост (мост) и хост. (Хост), нет (нет внешней сети). По умолчанию используется режим моста, сетевая карта в контейнере соединяется с мостом Docker, и IP-адрес автоматически назначается через DHCP, который находится в том же сегменте сети, что и Docker0. Когда мы создаем контейнер, на хост-компьютере будет создана новая сетевая карта, соответствующая сетевой карте в контейнере, как показано на следующем рисунке. Структура межсетевого доступа в режиме моста контейнера показана на рисунке ниже Если вы хотите реализовать контейнеры на разных хостах, вы должны передать хост для пересылки по сети через хост. Это можно сделать, задав статический маршрут на хосте или изменив правила iptables. : Сегментом сети DHCP по умолчанию для всех служб контейнеров является 172.17.0.0/16. Если контейнер на узле 1 хочет получить прямой доступ к контейнеру на хост-машине узла 2, он будет напрямую использоваться как сегмент внутренней сети моста docker0. Текст не будет отправляться с сетевой карты eth0 хоста node1 и вообще не будет достигать хоста node2. В этом случае, независимо от того, как мы изменим правила iptables или правила маршрутизации, это не поможет. Поэтому мы хотим получить доступ к контейнерам между хостами. Сначала мы должны разделить контейнеры на разных хостах на разные сегменты сети, а затем мы можем перейти или перейти через правила маршрутизации или iptables.

Изменить сегмент сети докерной сети

Мы можем изменить файл конфигурации докера на каждом хост-компьютере, чтобы добиться того, чтобы док-контейнер каждого хост-компьютера находился в отдельном сегменте сети, и его можно было изменить следующим образом (не допуская влияния, сначала удалите все ранее созданные на каждом сервере). контейнер,）。

Изменить файл сценария запуска системыdocker.service

вДобавить в конце опции, Укажите сегмент сети 10.1.0.0/24, а затем выполните команду, чтобы перезагрузить файл конфигурации и перезапустить службу.

нота:Хотя конец сетевого сегмента записи равен 0, например, 10.1.0.0/24 в большей степени соответствует нашим привычкам, он сообщает об ошибках. Информация об ошибках выглядит следующим образом:

Вы также можете изменить файл daemon.json и добавить»bip»: «10.2.0.1/24», Как показано ниже (выше приведена моя ссылка на Alibaba Cloud Accelerator, зарегистрируйте учетную запись Alibaba и получите ее бесплатно,Предыдущая статьяДля подробного ознакомления вам нужно изменить на свой или удалить):

Файл daemon.json представляет собой формат данных json, вам необходимо соблюдать синтаксис json, не забудьте добавитьзапятая. Непосредственный перезапуск службы Docker для вступления в силу

В этот момент IP-адрес сетевой карты стал установленным нами сегментом сети, и созданный впоследствии сервер-контейнер автоматически получит IP-адрес в заданном нами сегменте сети.

Та же операция, установите сегмент сети docker0 на хосте node2 на 10.2.0.0/24

Изменить статический маршрут

Здесь ip сетевой карты eth0 узла 1 равен 192.168.32.19, ip сетевой карты eth0 узла 2 — 192.168.32.20, и два хоста могут подключаться друг к другу через сетевую карту eth0. Добавьте правила маршрутизации следующим образом: Добавить статический маршрут на узел 1

Добавить статический маршрут на node2

Изменить правила iptables

Если в качестве хоста используется centos7, нет необходимости изменять правила iptables, а если хост является системой Ubuntu, вам нужно добавить правила пересылки, чтобы отпустить его. Я внимательно посмотрел на правила iptables этих двух систем и обнаружил, что правила iptables, созданные docker в системе centosПо умолчанию, И пара iptables, созданная docker в системе UbuntuПо умолчанию После запуска контейнера на каждой стороне вы можете общаться или получать доступ друг к другу.

Что такое Docker

Docker (Докер) — программное обеспечение с открытым исходным кодом, применяемое для разработки, тестирования, доставки и запуска веб-приложений в средах с поддержкой контейнеризации. Он нужен для более эффективного использование системы и ресурсов, быстрого развертывания готовых программных продуктов, а также для их масштабирования и переноса в другие среды с гарантированным сохранением стабильной работы.

Разработка Docker была начата в 2008 году, а в 2013 году он был опубликован как свободно распространяемое ПО под лицензией Apache 2.0. В качестве тестового приложения Docker был включен в дистрибутив Red Hat Enterprise Linux 6.5. В 2017 году была выпущена коммерческая версия Docker с расширенными возможностями.

Docker работает в Linux, ядро которых поддерживает cgroups, а также изоляцию пространства имен. Для инсталляции и использования на платформах, отличных от Linux, существуют специальные утилиты Kitematic или Docker Machine.

Основной принцип работы Docker — контейнеризация приложений. Этот тип виртуализации позволяет упаковывать программное обеспечение по изолированным средам — контейнерам. Каждый из этих виртуальных блоков содержит все нужные элементы для работы приложения. Это дает возможность одновременного запуска большого количества контейнеров на одном хосте.

Docker-контейнеры работают в разных средах: локальном центре обработки информации, облаке, персональных компьютерах и т. д.

Extended description

Creates a new network. The accepts or which are the
built-in network drivers. If you have installed a third party or your own custom
network driver you can specify that here also. If you don’t specify the
option, the command automatically creates a network for you.
When you install Docker Engine it creates a network automatically. This
network corresponds to the bridge that Engine has traditionally relied
on. When you launch a new container with it automatically connects to
this bridge network. You cannot remove this default bridge network, but you can
create new ones using the command.

Bridge networks are isolated networks on a single Engine installation. If you
want to create a network that spans multiple Docker hosts each running an
Engine, you must create an network. Unlike networks, overlay
networks require some pre-existing conditions before you can create one. These
conditions are:

Access to a key-value store. Engine supports Consul, Etcd, and ZooKeeper (Distributed store) key-value stores.
A cluster of hosts with connectivity to the key-value store.
A properly configured Engine on each host in the cluster.

The options that support the network are:

To read more about these options and how to configure them, see “Get started
with multi-host network”.

While not required, it is a good idea to install Docker Swarm to
manage the cluster that makes up your network. Swarm provides sophisticated
discovery and server management tools that can assist your implementation.

Once you have prepared the network prerequisites you simply choose a
Docker host in the cluster and issue the following to create the network:

Network names must be unique. The Docker daemon attempts to identify naming
conflicts but this is not guaranteed. It is the user’s responsibility to avoid
name conflicts.

Overlay network limitations

You should create overlay networks with blocks (the default), which limits
you to 256 IP addresses, when you create networks using the default VIP-based
endpoint-mode. This recommendation addresses
limitations with swarm mode. If you
need more than 256 IP addresses, do not increase the IP block size. You can
either use endpoint mode with an external load balancer, or use multiple
smaller overlay networks. See

for more information about different endpoint modes.

For example uses of this command, refer to the below.

Known limitations, use cases, and workarounds

Following is a summary of current limitations on the Docker Desktop for Windows
networking stack, along with some ideas for workarounds.

There is no docker0 bridge on Windows

Because of the way networking is implemented in Docker Desktop for Windows, you cannot
see a interface on the host. This interface is actually within the
virtual machine.

I want to connect from a container to a service on the host

The host has a changing IP address (or none if you have no network access). We recommend that you connect to the special DNS name
which resolves to the internal IP address used by the
host. This is for development purpose and will not work in a production environment outside of Docker Desktop for Windows.

You can also reach the gateway using .

If you have installed Python on your machine, use the following instructions as an example to connect from a container to a service on the host:

Run the following command to start a simple HTTP server on port 8000.

If you have installed Python 2.x, run .
Now, run a container, install , and try to connect to the host using the following commands:

I want to connect to a container from Windows

Port forwarding works for ; , , or all work.
Ports exposed from Linux are forwarded to the host.

Our current recommendation is to publish a port, or to connect from another
container. This is what you need to do even on Linux if the container is on an
overlay network, not a bridge network, as these are not routed.

For example, to run an webserver:

To clarify the syntax, the following two commands both publish container’s port to host’s port :

To publish all ports, use the flag. For example, the following command
starts a container (in detached mode) and the flag publishes all exposed ports of the
container to random ports on the host.

See the run command for more details on
publish options used with .

windows, networking

Просмотр информации об используемых сетях

Чтобы узнать какие сети использует Docker:

Запросите список сетей:

docker network list

Пример ответа

NETWORK ID          NAME                          DRIVER              SCOPE
14a38927e118        bridge                        bridge              local
b91a38ed491b        dci_auth                      bridge              local
7bdf76184b18        docker_ipmi_proxy_v2_bridge   bridge              local
2d9237551d88        etc_default                   bridge              local
f67c6099ef24        host                          host                local
cbb6fb4096c5        none                          null                local

В ответе команды в столбце NAME будут отображены имена используемых сетей.

Запросите информацию об используемом адресном пространстве:

Пример команд с ответами

# docker network inspect etc_default | grep Subnet
"Subnet": "172.19.0.0/16",
# docker network inspect docker_ipmi_proxy_v2_bridge | grep Subnet
"Subnet": "172.26.0.0/16",
# docker network inspect bridge | grep Subnet
"Subnet": "172.17.0.0/16",
# docker network inspect dci_auth | grep Subnet
"Subnet": "172.25.0.0/16",

Подключение к MySQL

Теперь, когда вы умеете работать с MySQL, давайте использовать его! Но как? Если запущен другой контейнер в той же сети, как найти контейнер (помните, что каждый контейнер имеет свой собственный IP-адрес)?

Чтобы выяснить это, воспользуемся контейнером nicolaka/netshoot, который входит в состав многих средств, полезных для устранения неполадок или отладки сетевых проблем.

Запустите новый контейнер с помощью образа . Обязательно подключите его к той же сети.
В контейнере используйте команду , которая является полезным средством DNS. Найдите IP-адрес для имени узла .

И вы получите вывод, подобный этому…

В разделе «ANSWER SECTION» вы увидите запись для , которая разрешается в (ваш IP-адрес, скорее всего, будет иметь другое значение). Хотя не является допустимым именем узла, Docker удалось разрешить его IP-адресу контейнера, который имел этот сетевой псевдоним (вспомните флаг , который использовался ранее).

Это означает, что ваше приложение просто должно подключаться к узлу с именем и обращаться к базе данных. На самом деле нет ничего проще!

Сетевые топологии и IPAM

В следующей таблице показано, как сетевое подключение предоставляется для внутренних (контейнер-контейнер) и внешних подключений каждого сетевого драйвера.

Сетевые режимы и драйверы DOCKER

Сетевой драйвер Windows для Docker	Распространенные способы применения	Контейнер в контейнер (один узел)	Между контейнерами и внешними узлами (один узел и несколько узлов)	Контейнер в контейнер (с несколькими узлами)
NAT (по умолчанию)	Удобно для разработчиков	Одна подсеть: подключение с мостом через виртуальный коммутатор Hyper-V Перекрестная подсеть: не поддерживается (только один внутренний префикс NAT)	Маршрутизация через виртуальный сетевой адаптер управления (привязка к WinNAT)	Не поддерживается напрямую: требуется предоставление доступа к портам через узел
Прозрачный режим	Удобно для разработчиков и небольших развертываний	Одна подсеть: подключение с мостом через виртуальный коммутатор Hyper-V Подключение между подсетями: маршрутизация через узел контейнеров	Маршрутизация через узел контейнеров с прямым доступом к (физическому) сетевому адаптеру	Маршрутизация через узел контейнеров с прямым доступом к (физическому) сетевому адаптеру
Overlay	Подходит для нескольких узлов; требуется для DOCKER Swarm, доступно в Kubernetes	Одна подсеть: подключение с мостом через виртуальный коммутатор Hyper-V Подключение между подсетями: сетевой трафик инкапсулируется и маршрутизируется через виртуальный сетевой адаптер управления	не поддерживается напрямую. требуется вторая конечная точка контейнера, подключенная к сети nat в Windows Server 2016 или на правиле nat VFP на Windows сервере 2019.	Одна подсеть/подключение между подсетями: сетевой трафик инкапсулируется с помощью VXLAN и маршрутизируется через виртуальный сетевой адаптер управления
L2Bridge	Используется для Kubernetes и Microsoft SDN	Одна подсеть: подключение с мостом через виртуальный коммутатор Hyper-V Подключение между подсетями: MAC-адрес контейнера повторно записывается при входе и выходе и маршрутизируется	MAC-адрес контейнера повторно записывается при входе и выходе	Одна подсеть: подключение с мостом Перекрестная подсеть: направляется через vNIC для WSv1809 и более поздних версий
L2Tunnel	Только в Azure	Одна подсеть/подключение между подсетями: разворот пакетов на виртуальный коммутатор Hyper-V физического узла, к которому применяется политика	Трафик должен проходить через виртуальный сетевой шлюз Azure	Одна подсеть/подключение между подсетями: разворот пакетов на виртуальный коммутатор Hyper-V физического узла, к которому применяется политика

IPAM

IP-адреса распределяются и назначаются каждому сетевому драйверу по-разному. Windows использует сетевую службу узлов (HNS) для передачи IPAM драйверу «nat» и работает в режиме мелких объектов Docker (внутренняя служба KVS) для передачи IPAM драйверу «overlay». Все остальные сетевые драйверы используют внешнюю платформу IPAM.

Сетевой режим/драйвер	IPAM
NAT	Динамическое выделение и назначение IP-адресов службой Networking Service (HNS) от префикса внутренней подсети NAT
Прозрачный режим	Статическое или динамическое (с помощью внешнего DHCP-сервера) выделение и назначение IP-адресов из числа адресов в префиксе сети узла контейнеров
Наложение	Динамическое выделение IP-адресов из префиксов под управлением подсистемы Docker в режиме мелких объектов и их назначение через службу HNS
L2Bridge	Динамическое выделение и назначение IP-адресов службой Networking Service (HNS) из предоставленного префикса подсети
L2Tunnel	Только в Azure: динамическое выделение IP-адресов и их назначение через подключаемый модуль

Обнаружение служб

Обнаружение служб поддерживают только определенные сетевые драйверы Windows.

Имя драйвера	Локальное обнаружение служб	Глобальное обнаружение служб
NAT	YES	ДА, с помощью Docker EE
overlay	YES	да, с помощью docker EE или kube-dns
transparent	NO	NO
l2bridge	Да, с KUBE-DNS	Да, с KUBE-DNS

Launch a container on the default network

Docker includes support for networking containers through the use of network
drivers. By default, Docker provides two network drivers for you, the
and the drivers. You can also write a network driver plugin so
that you can create your own drivers but that is an advanced task.

Every installation of the Docker Engine automatically includes three default networks. You can list them:

The network named is a special network. Unless you tell it otherwise, Docker always launches your containers in this network. Try this now:

Inspecting the network is an easy way to find out the container’s IP address.

You can remove a container from a network by disconnecting the container. To do this, you supply both the network name and the container name. You can also use the container ID. In this example, though, the name is faster.

While you can disconnect a container from a network, you cannot remove the
builtin network named . Networks are natural ways to isolate
containers from other containers or other networks. So, as you get more
experienced with Docker, create your own networks.

Заключение

Docker является важным инструментом для каждого современного разработчика, как основа аппаратной виртуализации приложений. Эта технология обладает широким функционалом и возможностями для контроля процессов. Докер позволяет не только развертывать контейнеры, но и оперативно масштабировать их экземпляры, работать с многоконтейнерными приложениями (Docker Compose), а также объединять несколько Докер-хостов в единый кластер (Docker Swarm).

Докер характеризуется достаточно простым синтаксисом. Поэтому он довольно прост в освоении как для опытных IT-специалистов, так и для новичков. Программное обеспечение совместимо со всеми версиями операционных систем Linux и Windows, поэтому область применения Docker практически не ограничена.

Оцените материал: