A troubleshooting experience of centos Docker bridge mode unable to access the host Redis service

background:

I have done a project before, which requires accessing the Redis service provided by the host in the container (this is a common application scenario). The conventional solution is:

① Host network ( docker run --network=host ): fully apply the host network stack, and localhost in the container refers to the host machine

② docker run --network=bridge 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.

Docker will establish the docker0 bridge by default;

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

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

No fancy operations, just use 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/24 app_bridge

docker run --network=app_bridge --name ......

# The following is taken 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 newly created containers will join this bridge by default, so we need to create a bridge app_bridge dedicated to this program

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

To access the host machine's localhost:6379 service in bridge mode within the container, you must use the --add-host option provided by Docker (the corresponding configuration in docker-compose.yml is extra_host).

The --add-host option of docker run adds a line to the container's /etc/hosts file, making it easier for us to access other networks using that name.

docker run -it --add-host dockerhost:172.16.1.1 ubuntu cat /etc/hosts
172.17.0.22 09d03f76bf2c
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
172.16.1.1 dockerhost

Then you can use dockerhost:6379 in the program configuration file 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-----------------------------------------------------

A situation:

I used the above operations on the company's CentOS7 machine, and the container could not connect to the host machine (containers could still access each other normally).

Simplify the problem test: create a new container, and try to ping the docker0 gateway in the container. Oh my god, all four company machines cannot ping the docker0 gateway, but the external network can still access it normally.

Then the problem becomes: Using the default docker0 bridge, the docker0 gateway cannot be pinged from within the container, and the host machine cannot be accessed.

Oh my, it's most likely a configuration problem with the company's machines. . ~

After asking the company's operation and maintenance colleagues, I found that:

Chain INPUT (policy DROP)

The default policy of the above INPUT chain is discard: the INPUT chain rule for accessing the host from the container does not match any of the listed ones and will be discarded, so we will get stuck when pinging the docker0 gateway from the container and receive no results.

The default policy is to discard unless the listed INPUT chain rules are met.

There are also forwarding and OUTPUT chains that accept by default

The original intention of this strategy is server security (damn, it results in the container losing its basic ability to access the host machine!!!).

Operation and maintenance solution:

① Use sudo service iptables stop to shut down iptables

② Add the bridge network segment to be used to the INPUT chain

sudo iptables -I INPUT -s 172.17.0.0/16 -j ACCEPT

[Accept docker0 subnet 172.17.0.0/16 INPUT] Add rules, portal

OK, That's All. If you encounter the problem that you cannot ping the bridge gateway in the default bridge container in the company network and cannot access the host machine, you can refer to this article for troubleshooting.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.