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

Background:

Previously, we made a project to access the Redis service provided by the host in the container (this is a common application scenario). General solution:

① host network (docker run-- network=host): the host network stack is fully applied. Localhost in the container points to the host.

② bridge network (docker run-- network=bridge): this is also the default network communication mode of the docker container. The localhost in the container points to the container itself. You cannot use localhost to access the Redis service hosted by localhost:6379 on the host machine.

Docker will build a docker0 bridge by default

The bridge has a gateway ip and a subnet segment; containers in the bridge determine the container ip (ip addr eth0) from the subnet segment, and the containers in the bridge can access each other through service name

The container inside the bridge can access the external network through docker0 Getway.

Instead of coquettish operation, follow the common ② bridge mode:

Step 1: customize the bridge and apply it

Docker network create-- gateway 172.16.1.1-- subnet 172.16.1.0 take 24 app_bridgedocker run-- network=app_bridge-- name. # the following is intercepted from the docker-compose.yml file. Networks: default: name: app_bridge external: true

Why not use the default docker0 bridge?

As mentioned at the beginning of this article: docker0 is the default bridge, and new containers will join this bridge by default, so we need to build a bridge app_bridge that belongs to this program.

Step 2: create an alias corresponding to the host in the container

In order to access the host localhost:6379 service in bridge mode in the container, it must be accompanied with the-add-host option provided by docker (the configuration corresponding to docker-compose.yml is extra_host).

The-add-host option of docker run adds line records to the container / etc/hosts file, making it easy for us to use that name to access other networks. Docker run-it-- add-host dockerhost:172.16.1.1 ubuntu cat / etc/hosts172.17.0.22 09d03f76bf2cfe00::0 ip6-localnetff00::0 ip6-mcastprefixff02::1 ip6-allnodesff02::2 ip6-allrouters127.0.0.1 localhost::1 localhost ip6-localhost ip6-loopback172.16.1.1 dockerhost

After that, dockerhost:6379 can be used in the configuration file of the program to access the host Redis service.

-- friends who are slightly familiar with the docker network model should be able to understand and complete the above operations.

One situation:

I use the above operation on the company CentOS7 machine, and the host can not be connected within the container (the container can still be accessed normally).

Simplify the problem test: create a new container, try the ping docker0 gateway in the container, beep the dog, 4 company machines ping can not access the docker0 gateway, the public network is still accessed normally.

Then the problem becomes: using the default docker0 bridge, you cannot ping the docker0 gateway in the container, thus unable to access the host.

Gee, it must be the configuration of the company's machine. ~

Questioning the operation and maintenance students of the company, I found that:

Chain INPUT (policy DROP)

The default policy of the above INPUT chain is to discard: the INPUT chain rules for accessing the host from the container do not match any of the rules listed in it, and will be discarded, so we will not receive the result from the container ping docker0 gateway.

Unless the listed INPUT chain rules are met, the default policy is to discard.

This is followed by forwarding and the OUTPUT chain is accepted by default

The original intention of this strategy is server security (Nima, which leads to the loss of the basic ability of the container to access the host! ).

Operation and maintenance plan:

① uses sudo service iptables stop to turn off iptables

② adds the bridge segment to be used in the INPUT chain

Sudo iptables-I INPUT-s 172.17.0.0 ACCEPT 16-j

[accept docker0 subnet segment 172.17.0.0 INPUT 16] add rules, portals

OK, That's All. If a friend encounters a default bridge container in the corporate network that cannot ping the bridge gateway and thus cannot access the host, please refer to this document to troubleshoot.

Summary

The above is the whole content of this article. I hope the content of this article has a certain reference and learning value for everyone's study or work. Thank you for your support.

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.