Description on pit

docker run -d --network=host image

This command is a very simple command to run the image. The only difference is that the network uses the host mode.

Example:

docker run -d \
  --privileged=true \
  --network host \
  --name myredis \
  redis redis-server \
  --appendonly yes  
Copy the code

Surprisingly, the container is running, and the redis service is actually running, but you can’t access the redis service from the host using 127.0.0.1 or localhost.

Opponents! This is a bit of a puzzle.

But, I found that on Linux machines it is accessible through the host’s IP.

Emmm…… Is there any difference between Mac and Linux?

Docker Desktop principle

In fact, the official website states that host mode only works on Linux and is not supported on Mac and Windows.

Why not? We need to understand how Docker for Mac works.

As we all know, the core of Docker is to use Namespace and Cgroups of Linux to realize resource isolation and restriction, and containers share the host kernel. In short, Docker was originally a tailored product based on Linux. So the Mac itself can’t run Docker containers.

However, in another way, we can run Virtual machines. Before Docker for Mac, we could directly create a Linux Virtual machine in a Virtual Box or VMWare by using docker-machine. Then use the Docker Client on the host to operate the Docker Server in the VIRTUAL machine.

Therefore, Docker for Mac is essentially running a local VIRTUAL machine to run Docker, but the Hypervisor uses Xhyve.

This is why we don’t see a Docker0 bridge on macOS, because the interface is actually in the virtual machine.

Talk about the Docker network

Such confusion about this problem is actually due to our unfamiliarity with Docker network.

Most companies have their own set of mature CICD platforms. In actual business scenarios, developers only need to know how to operate packaging and release on the platform interface. In case of failure in packaging and release operation, students can provide off-site support. So the principle of the container itself is less likely to touch, let alone the container network.

In the spirit of endless learning, Xiao Nian decided to take you to redefine the container network this piece of knowledge.

Docker Network isolation is implemented based on Linux Network Namespace, and different Network modes are closely associated with Network Namespace.

Docker container network has four modes:

1. host

Use the host’s default network namespace and share a network stack. Simply put, it is to share the IP and port of the host.

As mentioned above, Docker Desktop For Mac is implemented by virtual machine itself, so the host mode is not effective For Mac and Windows.

2. Bridge (default)

Docker creates a docker0 virtual bridge by default. Docker containers started on this host will connect to this virtual bridge if no network mode is specified.

On Linux, you can run the BRCTL show command to view the docker0 configuration. The Mac does not have the BRCTL command. You can also view the docker0 configuration through ifconfig.

3. none

In None mode, Docker containers have their own Network Namespace, but do not do any Network configuration for Docker containers. That is, the Docker container has no network card, IP, routing, etc. We need to add network cards and configure IP for Docker containers by ourselves.

4. container

This pattern specifies that newly created containers share a Network Namespace with an existing container, rather than with the host. A newly created container does not create its own network adapter or configure its own IP address. Instead, it shares IP address and port range with a specified container. Also, the two containers are isolated from each other except for the network aspects, such as file systems, process lists, and so on.

By using the Docker network ls command, we can see that Docker itself supports three network models by default, and the network model can be specified by –network when creating containers.

[root@server1 ~]# docker network ls NETWORK ID NAME DRIVER SCOPE bc1bf3817c35 bridge bridge local bde8994f7873 host host  local 66bd8d3ad9f2 none null localCopy the code

We focus on the Bridge mode. The underlying implementation of the Bridge mode is actually implemented with the help of a virtual network device called bridge (network bridge). As the default network mode, there must be a reason for it.

So, let’s start with virtual network devices

Virtual network devices vs physical network devices

In the Linux kernel, there is a network device management layer that stands between the network device drivers and the protocol stack and is responsible for bridging the data interaction between them. The driver does not need to know the details of the protocol stack, and the protocol stack does not need to know the details of the device driver.

For a network device, like a pipe, there are two ends, and data received from one end will be sent from the other.

For example, eth0, a physical nic, is connected to the kernel protocol stack (through indirect communication between the kernel device management module) and the external physical network. Data received from the physical network is forwarded to the kernel protocol stack, and data sent from the application stack is sent out through the physical network.

Virtual network devices are no different from physical network devices. They are both network devices that can be configured with IP addresses and are managed by the network device management module of the kernel.

One end of the virtual network device is also the protocol stack, and what the other end is depends on the virtual network device’s driver implementation.

tun/tap

The TUN/TAP virtual network device connects one end to the protocol stack and the other end to user-space applications.

That is, packets sent by the protocol stack to Tun/TAP can be read by the application. Of course, the application can send packets directly to Tun/TAP.

Assume that the IP address of eth0 is 10.32.0.11, that of TUN0 is a Tun /tap device, and that of 192.168.3.11.

  1. Application A passesSocket AA packet is sent, assuming the destination IP address of the packet is192.168.3.1
  2. Socket A throws the packet to the network protocol stack
  3. Protocol stack According to the packet local routing rules and destination IP address, the matched packet should be sent out by TUN0, so the packet is discarded to Tun0
  4. Tun0 receives the packet and drops it to application B
  5. After receiving the packet, application B constructs a new packet, inserts the original packet into the new packet, and forwards the packet through Socket B. In this case, the source address of the new packet becomes the eth0 address, and the destination IP address becomes another address, such as 10.33.0.1.
  6. Socket B throws packets to the protocol stack
  7. The protocol stack delivers packets to eth0 according to local routing rules
  8. Eth0 sends packets over the physical network

To summarize, network packets intended for application A are forwarded by TUN0 to application B for processing and then forward out.

Therefore, Tun/TAP can forward the packets in the protocol stack to application B, and application B can customize the packets, such as data compression and encryption. The familiar and common scenario is VPN.

Tun and Tap

  • The Tun device is a virtual end-to-end IP layer device, which means that the user program receiving and receiving the Tun device can only read and write IP network packets (Layer 3).
  • The TAP device is a virtual link-layer device. The user program receiving and receiving the TAP device can read and write link-layer data packets (Layer 2).

veth

Veth devices come in pairs, with one end connected to the kernel protocol stack and two devices connected to each other at the other end. When a device receives a request for sending data from the protocol stack, it sends the data to another device.

Because of this characteristic, it is often used to construct virtual network topology. For example, connect two different network namespaces (NetNs), connect docker containers, connect Bridges, etc. One of the most common cases is that OpenStack Neutron base uses it to build very complex network topology.

bridge

Bridge. Like other virtual network devices, Bridges can be configured with IP and MAC addresses.

In addition, unlike other network devices, the Bridge is also a virtual switch that has similar functions as a physical switch.

With normal network devices, there are only two ends, with data going in and out at one end. A Bridge has multiple ports, and data can go in and out of multiple ports.

One end of the bridge is connected to the protocol stack, and the other end has multiple ports. Data packets are forwarded between ports based on MAC addresses.

Common real-world scenarios

The virtual machine

In a typical VM network, the TUN/TAP is used to connect the NETWORK interface card (NIC) in a VM to the BR0 of the host. Data packets sent from the VM first pass through br0 and then are sent to eth0. Data packets do not need to pass through the protocol stack of the host, achieving the effect of a real switch with high efficiency.

The container

Ahem… Key content, knock on the blackboard!! Make notes

As mentioned above, the core of Docker is to use Namespace and Cgroups of Linux to realize resource isolation and restriction, while Network Namespace is used to realize isolation between containers. In bridge mode, the default networking mode, each container has its own network protocol stack, which communicates similar to the above virtual machine, but in a Veth-pair manner.

So, one might ask, how can you find the veth on the host and the eth0 in the container?

Here are some tips from xiao Nian:

Step 1: Run the IP link show eth0 command in the container

You can then see 13813: eth0@if13814, where 13813 is the index of eth0 and 13814 is the index of its veth pair.

Step 2: the host machine to perform IP link show | grep 13814, so you can find the corresponding container veth – pair relationship.

The solution

Method is always more than difficult, this problem has been encountered very early, online gods also provide some solutions, the specific operation here will not be expanded, if interested, please refer to the following link:

PJW. IO/articles / 20…

Docs.docker.com/desktop/mac…

reference

Blog.51cto.com/ganbing/208…

Morven. Life/posts/netwo…

Segmentfault.com/a/119000000…

Segmentfault.com/a/119000000…

Ordinary change, will change ordinary

I am a house xiaonian, a low-key young man in the Internet

Follow the public account “Zexiannian” and personal blog 📖 edisonz.cn to read more shared articles