07. Docker network communication mode

Table of contents

1 Introduction

2. Basic principles

3. Docker network configuration

3.1. View network configuration

3.2, 4 network modes

3.3, bridge mode

3.3.1, using the bridge network

3.3.2, custom bridge network

3.4, host mode

3.5, container mode

3.6, none mode

4. Summary


1 Introduction

Earlier we introduced the relevant content of the Docker container, and the Docker container runs on the virtual machine of the host machine. These virtual machines are independent of each other without any interface between each other, that is, the containers are logically isolated from each other. So, how to achieve mutual communication between containers? This is what we are going to talk about today.

2. Basic principles

Network interfaces in Docker containers are virtual interfaces by default. The biggest advantage of the virtual interface is that the forwarding efficiency is extremely high. This is because Linux implements data forwarding between virtual interfaces by duplicating data in the kernel, that is, data packets in the cache of the sending interface will be copied directly to the cache of the receiving interface without going through an external physical network device. exchange.

Docker's network makes good use of Linux virtual network technology. Create a virtual interface (veth) in the host's physical network card and container, and let them connect through the host's docker0 bridge. We put such a A pair of veths is called a veth pair.

3. Docker network configuration

3.1. View network configuration

We can view Docker's network configuration information with the following command.

docker network

Several network communication modes of Docker can be viewed through the following commands.

docker network ls

0

You can see that there are 3 modes: bridge, host, none. And the default is bridge.

Let's start a docker container randomly, the container name is myapp, and no network mode is specified:

docker run -d -p 18080:8899  myapp

0

After the startup is successful, we check the details of the network Bridge:

docker network inspect bridge

You can see that the Container contains our myapp container, which means that the myapp container we just started uses the bridge network mode by default.

0

And the default subnet address is "172.17.0.0/16". The container IP is 172.17.0.2, which is a subnet belonging to the bridge network.

3.2, 4 network modes

Docker provides a total of 4 network communication modes: bridge, container, host and none. In addition to the bridge, host, and none seen through the above docker network ls, there is also a container mode.

model

Whether to support multi-host

vertical communication mechanism

horizontal communication mechanism

bridge

no

Bind host port

Communicate via Linux bridge

container

no

Bind host port

Communicate over a Linux connection

host

yes

Communicate over the host network

Communicate over the host network

none

no

unable to communicate

Can only communicate over a Linux connection

Since Docker containers are logically isolated from each other, an isolated network environment is created in the container when Docker is installed. In an isolated network mode environment, each container running on the host has a completely independent network stack, and the network environment of the Docker container is isolated from the host. By using different network modes of Docker, Docker containers can share the network namespace of the host machine, and mutual access between Docker containers can also be realized.

3.3, bridge mode

As mentioned earlier, the bridge mode is the default network communication mode of Docker, and it is also the most commonly used mode by developers. In bridge mode, the Docker engine creates an independent network namespace. This ensures that the containers running in each namespace have independent network resources such as network cards.

Using the bridge mode, it is very convenient to realize network isolation between containers and between containers and hosts. By using the docker0 bridge on the host, the network communication between the Docker container and the host (or even the external network) can be realized.

Simply experiment:

3.3.1, using the bridge network

Create a container for the busybox image.

BusyBox is a software that integrates more than 300 most commonly used Linux commands and tools. BusyBox includes simple tools like ls, cat, echo, etc., and larger, more complex tools like grep, find, mount, and telnet.

docker run -it busybox /bin/sh

Use ifconfig to view network information:

You can see that the internal network ip of the container is 172.17.0.3.

3.3.2, custom bridge network

By default, the docker engine will automatically create a bridge network. But usually in the production environment, we will customize a bridge network. Of course, docker also supports our customization.

1) Create a custom bridge network.

Create a network mode named mybridge, the gateway ip is 172.19.0.1, and the subnet IP range is 172.19.0.0/24.

docker network create -d bridge  --ip-range=172.19.0.0/24 --gateway=172.19.0.1 --subnet=172.19.0.0/24 mybridge
  • -d: Specify the network communication mode, the default is bridge.
  • --ip-range: Subnet IP address range.
  • --gateway: The IP address of the gateway.
  • --subnet: The IP address of the subnet.
  • mybridge: custom bridge network name

2) View the Docker network.

docker network ls

You can see that there is an additional network communication mode of mybridge.

3) Create a container using mybridge.

docker run -it --network=mybridge --ip=172.19.0.33 busybox

  • --ip: Specifies the IP address of the container.
  • --network: The network communication mode used, where the newly created mybridge is specified.

4) Check the container IP.

5) Delete the custom network.

docker network rm mybridge

3.4, host mode

In host mode, the container and the host share the same network namespace, and the IP address of the container is the same as that of the host. If the host machine has a public IP address, the container also has this public IP address. That is, at this time, the container can directly use the IP address of the host machine to communicate with the outside world, and the port of the service in the container can also directly use the port of the host machine without any conversion.

Since the forwarding of the host machine is no longer required in the host mode, its performance has been greatly improved.

1) Create a container using host mode.

docker run -it --net=host busybox /bin/sh

2) Use ifconfig to see the network information.

Inside the container:

Host:

We can see that the network configuration of the container and the host are exactly the same, which means that the container and the host share the same network namespace.

If you use the host mode, we don't need -p to map the port when creating the container. If there is a mapped port, there will be a warning prompt when creating it. Because the IP and port at this time are shared with the host.

There are two problems when using host mode:

  1. Because the container uses the network environment of the host machine, the isolation function of the network environment is weakened, causing the host machine and the container to compete for network resources. The container itself no longer owns all network resources, but shares network resources with the host.
  2. The host and container use the same IP address, which is not conducive to network configuration and management.

3.5, container mode

In container mode, the network environment is shared between containers. That is, one container will use the network namespace of another container. Therefore, in this mode, containers can access each other through localhost or 127.0.0.1, which improves the efficiency of transmission.

The container mode saves network resources, but there is no network isolation for containers running in this mode. The isolation of the Container network is between the bridge network and the host network.

The container mode is very useful in some special scenarios. For example: when creating a Pod in Kubernetes, the base container of the Pod will be created first; while other containers in the Pod use the container mode to communicate with the base container. Each container in the Pod uses localhost or 127.0.0. to communicate, so that all containers in the Pod form a logical whole.

1) Create a container A, using the default network mode.

docker run -it busybox /bin/sh

View network information:

2) Create a container B, use the container mode, and point to the newly created container A.

View the containerId of container A: 0783212a7f4c.

Open container B.

docker run -it --net=container:0783212a7f4c busybox /bin/sh

View ifconfig:

It can be seen that the IP information of containers A and B are the same, indicating that container A and container B use the same network namespace.

Because when container B is created, the container mode is used, so that container B does not need to create its own network namespace, but directly uses container A.

3.6, none mode

In none mode, the container has an independent network namespace, but does not contain any network configuration, and the container can only be accessed through localhost or 127.0.0.1.

docker run -it --net=none busybox /bin/sh

Generally speaking, the none mode is used in some situations that require high security but do not require networking. Keep your own network in a closed space to exclude interference from other external networks.

4. Summary

Generally speaking, the bridge mode is most used in production. The container and host modes also have their own corresponding usage scenarios, which can be selected according to the actual situation. Understanding several different network communication modes can help us learn more about communication between different containers or between containers and hosts. Let's study together~

Guess you like

Origin blog.csdn.net/p793049488/article/details/132051774