Docker Learning < four >

Docker Network

The three networks of bridge, host, none are automatically created on the host when Docker is installed, and can be viewed with the Docker Network LS command

None Network

None Network is any network, hanging in the network of containers in addition to Lo, there is no other network card, the creation of containers can be--network=none to specify the use of the None network. A none network is available for applications that have high security requirements and do not require networking. In addition, we want to implement centralized control of the container can also use the None network, for example, to make the network created by the control of the SDN network, you can start the container with a none network, and then connect the network to the OvS bridge, so that it is controlled by the SDN controller

Host Network

A container connected to the host network shares the network stack of the Docker host, and the container's NIC configuration is exactly the same as the host, which can be specified using the host network via--network=host. The biggest benefit of a network that uses Docker host directly is performance, if the container is more efficient than the network, the host network is available, but it is less flexible, for example, to consider port conflicts, ports that are already used on the Docker host can no longer be used. Another use of this is to allow the container to directly configure the host network, such as some cross-host networks

Bridge Network

The Docker installation creates a Linux bridge named Docker0, and if you do not specify--network, the container you create is hung to Docker0 by default and you can use the Docker network inspect Bridge to view the configuration information for the network. When the container is created, Docker automatically assigns an IP from the 172.17.0.0/16, where a 16-bit mask guarantees enough IP to be used by the container

user-defined Network

Docker offers three user-defined network drives: Bridge, overlay, and Macvlan. Where overlay and Macvlan are used to create cross-host networks

You can create a bridge network similar to the one in front by bridge driver, where the 172.18.0.0/16 is a docker auto-assigned IP network segment

You can also specify the IP segment yourself, just specify the--subnet and--gateway parameters when creating the network segment, below to create a new bridge network Mynet1, the network segment is 172.22.16.0/24, the gateway is 172.22.16.1

Using the created Mynet1 network to start a container and view its IP address, you can see that the container has been assigned to IP as 172.22.16.2

When Docker creates a container, it automatically assigns IP from the subnet, and we can assign a static IP to the container, using the--IP parameter to implement the

It is important to note that only the network created with--subnet can specify a static IP, the previous creation of the MyNet network is not used--subnet, if you use the MyNet network to specify a static IP, an error occurs

If we no longer need to customize the created network, you can also delete them

Next to verify the connectivity between the host, because the above created more hosts, and each host may be under different network types, in order to more intuitively see the network between the host, here is a simple network topology diagram

Host3 and Host4 Two containers are hung on the mynet1, can communicate with each other, the following to verify the connectivity between them. It can be seen from the results that the containers and gateways in the same network can communicate with each other.

Mynet1 and Docker0 belong to different bridges and should not communicate directly between them. Below to verify the connectivity between Host3 and HOST5. It turns out that they really can't communicate with each other

Different networks can communicate if you add a route. Use IP r to view the routing table on the host

The routing table shows that the routes for the 172.17.0.0/16 and 172.22.16.0/24 two networks are all defined.

View IP Forwarding

IP forwarding has also been started

Although the conditions have been met, but the different networks are still unable to communicate, the next view iptables

sudo iptables-save

Here's why: Iptables dropped the two-way traffic between the bridge Docker0 and BR-305C071332D6. From the naming of the rules, docker-isolation that Docker is designed to isolate different network

To implement communication between HOST3 and HOST5, you can use the following method: Add a Mynet1 nic to the HOST5 container and implement it via the Docker Network Connect command

View network configuration in HOST5

You can see the addition of a network card in the container eth1, assigned the MYNET1 IP 172.22.16.3, now HOST3 and HOST5 can communicate with each other, the following to verify their connectivity

Three methods of communication between containers

IP Communication

Two containers to be able to communicate, you must have a network card belonging to the same networks, to meet this condition, you can interact through the IP. This is accomplished by specifying the appropriate network through--network when the container is created, or by adding the existing container to the specified network via Docker Network Connect

Docker DNS Server

IP communication is not flexible, because IP may not be determined before deploying the application, and specifying the IP to be accessed after deployment is cumbersome, and the solution to this problem is through the DNS service that comes with Docker. Starting with the Docker1.10 version, Docker daemon implements an embedded DNS server that allows containers to communicate directly through the container name, simply by naming the container with--name when you start the container.

There is a limit to using Docker DNS: only in the user-defined network, the default bridge network is unable to use DNS, see an example below

joined Container

The joined container allows two or more containers to share a network stack, share network cards and configuration information, and joined can communicate directly between containers via 127.0.0.1

Joined containers are suitable for the following scenarios

1. Applications in different containers want to communicate efficiently and quickly through loopback, such as Web server and app server

2. Want to monitor network traffic from other containers, such as network monitoring programs running in separate containers

External Network access container

Docker maps the port from which the container is serviced to a port on the host, and the extranet accesses the container through that port. The port is mapped by the-p parameter when the container starts

After the container is started, you can view the port of the host map through Docker PS or Docker port. In the example above, the 80 port of the WEB2 container is mapped to 32768 on host, which allows access to the container's Web service via

In addition to mapping dynamic ports, you can specify a map to a specific port on the host in-P. For example, the 80 port can be mapped to the 8080 port of host

Each mapped port, host initiates a docker-proxy process to handle traffic that accesses the container

Taking 0.0.0.0:32768->80/tcp as an example to analyze the whole process

1. Docker-proxy Monitor host's 32768 port

2. When curl accesses 127.0.0.1:32768, docker-proxy forwards it to the container 172.17.0.5:80

3. HTTPd the container responds to the request and returns the result

Docker Learning < four >