Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of single host Network of Docker Network

2025-01-28 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)06/01 Report--

This article will explain in detail the example analysis of the single host network of the Docker network. The editor thinks it is very practical, so I share it with you for reference. I hope you can get something after reading this article.

1. Docker default network

Execute on the host where docker is newly installed

Docker network ls

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

1.1 none network

The none network is a network with nothing. The container hanging under this network does not have any network card except lo. When a container run, you can specify that the container uses the none network by adding the-- network=none parameter. So what's the use of such a lo-only network? Here CloudMan points out:

None network applications and isolation scenarios, some applications that require high security and do not need to connect to the Internet can use none networks.

For example, the only purpose of a container is to generate random passwords, which can be put into the none network to prevent passwords from being stolen.

I can understand that none networks must be used for isolation, but I wonder how the generated random passwords are sent to the outside world. How can it be called externally? This is a question that I haven't figured out. Don't hesitate to give advice if you know! Thank you!

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.

You can see all the network cards of host in the container, and even hostname is host. What is the usage scenario of the host network?

The biggest advantage of using Docker host network directly is performance. If the container has higher requirements for network transmission efficiency, you can choose host network. Of course, the inconvenience is to sacrifice some flexibility, for example, to consider port conflicts, ports that are already in use on Docker host can no longer be used.

Another use of Docker host is to allow containers to configure host networks directly. For example, some cross-host network solutions run as containers themselves, and these solutions need to configure the network.

If the container has the network of the host host, its ip and other configurations are the same, which means that the host has a container exactly the same as the outside, and the container can be accessed directly through the ip address of host.

1.3 bridge network

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

When Docker is installed, it creates a bridge called docker0 on the host, which is equivalent to a virtual switch. If you use both of the above methods, the run container will be hung on the docker0.

The container and the docker0 are connected by veth, and the veth is equivalent to a virtual network cable, connecting the container and the virtual switch, so that the docker0 is connected to the container.

2. Custom container network

In theory, the above three kinds of networks are enough to meet the needs of ordinary users, but sometimes users may need to specify their own networks to adapt to some configurations, such as ip address planning and so on.

2.1 create a custom network

Docker provides three user-defined network drivers: bridge,overlay and macvlan. Overlay and macvlan are used to create networks across hosts, which will be described in the next article. So this article introduces you to creating a bridge custom network. The command is as follows:

Docker network create-d bridge-- subnet 172.10.0.0 my_net 24-- gateway 172.10.0.1

-d bridge indicates that the driver of the custom network is bridge,--subnet 172.10.0. Gateway 172.10.0.1 specifies the network segment and gateway, respectively.

In this way, you have created an automatic one network, and you can view the information about this network with the following command:

Docker network inspect my_net

You will get the configuration information for this network. My_net is the name of the network you just created. If you are bridge, you will view the default bridge network information created by docker.

Each time a custom network is created, a bridge is created in the host (docker0 is the default bridge created, but the principle is consistent and peer-to-peer. ). The name is br-, and you can view all the bridge information through the brctl show command.

The custom network of docker is basically the same as the network information in OpenStack. So know everything, as long as docker understand, all virtualization and even physical networks will be basically clear.

2.2 using 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 consistent with using the docker default network, adding the-- network parameter parameter, which is also added here to specify the ip address of the container.

3. Connectivity between different containers

Containers under the same network (default network or custom network) can communicate with each other by ping, but containers between different networks cannot be connected by ping due to the requirement of network independence. The reason is that iptables-save DROP has lost the network between docker, probably 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 to make docker communication between different networks? Next, we introduce three ways to communicate between containers.

3.1 IP Communication

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

If it is a physical machine, we can easily understand that we only need to add a network card for one of the servers to connect to the other network. Containers are the same, just add the network of the other container to one of the containers. Use the following command:

Docker network connect my_net httpd

The connect command adds another my_net network to the httpd container (assuming that httpd originally has only the default bridge network). This allows the busybox container created above to communicate with the httpd container of this connect.

3.2 Docker DNS Server

Although accessing the container through IP meets the needs of communication, it is still not flexible enough. Because we may not be able to determine the IP before deploying the application, it will be troublesome to specify the IP to be accessed after deployment. This problem can be solved through the DNS service that comes with docker.

Starting with Docker version 1.10, docker daemon implements an embedded DNS server that allows containers to communicate directly through the container name.

The method is simple, as long as you name the container with-- name at startup.

The following command starts two containers, bbox1 and bbox2:

Docker run-it-network=my_net-name=bbox1 busyboxdocker run-it-network=my_net-name=bbox2 busybox

Bbox2 can then ping directly to bbox1, but there is a limitation to using docker DNS, which can only be used in user-defined networks. The default bridge network is not available.

3.3 joined Container

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

Take a look at the following example:

First create a httpd container named web1.

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

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

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

In this way, the network card mac address of busybox and web1 is exactly the same as IP, and they share the same network stack. Busybox can access web1's http service directly with 127.0.0.1.

In fact, it is easy to understand that the previous-- network parameter specifies the default network or custom network, but here it specifies a container, which, of course, means the network that uses this container. This is also a bit similar to the shared storage mentioned 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 the network traffic of other containers, such as network monitoring programs that run in separate containers.

In fact, it is applied to scenarios that need to be independent and highly consistent between the two container networks.

3.4 Connectivity between containers and external networks

3.4.1 Container access to external network

The container can access the external network by default. Access to the container's external network (where the external network is not necessarily the Internet) is realized through NAT,docker.

3.4.2 external network access container

The external network access to the container is realized by port mapping, that is, the port of the container is mapped to the external port through the-p parameter.

This is the end of the article on "sample Analysis of Docker Network single host Network". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, please share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report