Docker network single host network and use cases

preface

After summarizing the basics of Docker and Docker storage, today we are going to summarize 1 Docker single-host network. Without a doubt, the network is absolutely the core of any system, and it plays an important role in Docker.

1. Docker default network

Perform on the host on which docker was newly installed

docker network ls

You can see all the networks that docker installed by default, namely none, host, and bridge.

1.1 none network

The none network is nothing. The container hanging under this network does not have any network CARDS other than lo. When container run is used, you can specify that the container USES the none network by adding the --network=none parameter. So what's the use of having an lo only network? Here CloudMan points out:

none Network Application and Isolation scenario 1 none network can be used for applications with high security requirements and no networking.

For example, a container whose only purpose is to generate random passwords can be placed on the none network to avoid password theft.

I can understand that the none network is definitely used for quarantine, however I am curious how the generated random password is sent externally? How can it be called externally? This is a question I haven't thought through. Have the hope that knows generous grant instruction! Thank you very much!

1.2 host network

Containers connected to the host network share the network stack of the Docker host, that is, the network configuration of the container is exactly the same as that of the host host. You can specify that the container USES the host network by adding the --network=host parameter.

All the network CARDS for host can be seen in the container, and even hostname is host. What are the host network usage scenarios?

The biggest benefit of using the Docker host network directly is performance. host network can be selected if the container has high requirements for network transmission efficiency. The inconvenience, of course, is sacrificing a bit of flexibility, such as port conflicts, as the port already used on Docker host is no longer available.

Another use of Docker host is to allow containers to configure host networks directly. For example, some network solutions across host, which themselves run as containers, require network configuration.

It is equivalent to that the container has the network of host host, so the configuration of ip and so on is the same. It is equivalent to that there is a container in the host that is identical to the external 1 module 1, and the container can be accessed directly through the ip address of host.

1.3 bridge network

Containers created without specifying either the --network parameter or --network=bridge have a network type of bridge.

Docker creates a bridge called docker0 on the host during installation. The bridge is equivalent to a virtual switch, and run's container hangs on docker0 if you use either of the above methods.

The container and docker0 are connected via veth, which ACTS as a virtual network wire connecting the container to the virtual switch, thus allowing docker0 to communicate with the container.

2. Custom container network

In theory, having the three networks mentioned above is enough to meet the needs of ordinary users, but sometimes users may need to specify their own network to accommodate some configuration, such as ip address planning, etc.

2.1 Create a custom network

Docker offers three user-defined network drivers: bridge, overlay and macvlan. overlay and macvlan are used to create networks across hosts, described in the next article. So this article describes creating an bridge custom network. The order is as follows:

docker network create -d bridge --subnet 172.10.0.0/24 --gateway 172.10.0.1 my_net

-ES121en bridge represents the custom network driven by bridge, --subnet 172.10.0.0/24 --gateway 172.10.0.1 specify the network segment and gateway, respectively.

This creates an automatic 1 network, which can be viewed through the following command:

docker network inspect my_net

my_net is the name of the network you just created. For bridge, look at the default bridge created by docker.

Every time a custom network is created, a bridge is created in the host. (docker0 is the default bridge that is created, but the principle is one and the same.) . Name of br - < Network short ID > , you can view all bridge information through the brctl show command.

docker's custom network is basically the same as OpenStack's network information. Therefore, as long as docker is understood, all virtualization and even physical network will be basically clear.

2.2 Use a custom network

Specify a custom network for the container with the following command:

docker run -it --network my_net --ip 172.10.0.3 busybox

In fact, this is the same as using the docker default network as 1, both add -network parameter, here also added -ip parameter to specify the container's ip address.

3. Connectivity between containers

Containers under one network (default network or custom network) can be ping, but containers between different networks cannot be ping due to network independence requirements. The reason is that ES167en-ES168en DROP dropped the network between docker, which is roughly as follows:

-A DOCKER-ISOLATION -i docker0 -o br-ac4fe2d72b18 -j DROP
-A DOCKER-ISOLATION -i br-ac4fe2d72b18 -o docker0 -j DROP
-A DOCKER-ISOLATION -i br-62f17c363f02 -o br-ac4fe2d72b18 -j DROP
-A DOCKER-ISOLATION -i br-ac4fe2d72b18 -o br-62f17c363f02 -j DROP
-A DOCKER-ISOLATION -i br-62f17c363f02 -o docker0 -j DROP
-A DOCKER-ISOLATION -i docker0 -o br-62f17c363f02 -j DROP

So how do you get docker to communicate between different networks? Here are three ways to communicate between containers.

3.1 IP communication

IP communication is to communicate directly with IP address. According to the above analysis, it is necessary to ensure that the two containers are in the same network. How to deal with it if they are not in the same network?

If it's a physical machine, it's easy to understand. You just need to add a network card for one server to connect to another network. Similarly, you only need to add a network of one container to one container. Use the following command:

docker network connect my_net httpd

The connect command can add one more my_net network to the httpd container (assuming that httpd originally only had the default bridge network). The busybox container created above will then communicate with the httpd container for this connect.

3.2 Docker DNS Server

Accessing containers through IP, while satisfying the communication needs, is not flexible enough. Since we may not be able to determine IP before deploying the application, specifying which IP to access after deployment can be cumbersome. This problem can be solved through the DNS service that comes with docker.

Starting with Docker 1.10, docker daemon implemented a built-in DNS server, enabling containers to communicate directly via the "container name".

Simply name the container --name at startup.

The following command starts both containers bbox1 and bbox2:

docker run -it --network=my_net --name=bbox1 busybox
docker run -it --network=my_net --name=bbox2 busybox

bbox2 can then go directly from ping to bbox1, but using docker DNS has a limitation and can only be used on user-ES230en networks. The default bridge network is not available.

3.3 joined container

The joined container is another way to achieve communication between containers. The joined container is very special in that it enables two or more containers to share a network stack, share network CARDS and configuration information, and joined containers can communicate directly with each other through 127.0.0.1. host makes the container and host share the same network, while jointed makes two containers share the same network.

Here are some examples:

First create an httpd container with the name web1.

docker run -d -it --name=web1 httpd

Then create the busybox container and specify the jointed container as web1 through --network=container:web1:

docker run -it --network=container:web1 busybox

Thus, the mac addresses of busybox and web1 network CARDS are exactly the same as IP addresses, and they share the same network stack. busybox can directly access http services for web1 with 127.0.0.1.

It's also easy to understand that the previous --network parameter specifies the default network or custom network, whereas here it specifies a container, which of course means the network using the container. This is also similar to the Shared storage discussed in the previous article.

The joined container is ideal for the following scenarios:

Programs in different containers want to communicate efficiently and quickly through loopback, such as web server and app server.

You want to monitor network traffic from other containers, such as network monitors running in separate containers.

This is applied to a situation where the two container networks are required to be 1 height apart.

3.4 Connectivity between container and external network

3.4.1 The container accesses the external network

The container has access to the external network by default. Through NAT, docker realized the container external network (here the external network is not necessarily the Internet) access.

3.4.2 External network access container

The external network access container is achieved through port mapping, that is, the container's port is mapped to the external port through the -ES296en parameter.

conclusion