contexts
The group has N bases, and all bases use the same network segment, which is not a problem in itself! But Docker's default bridge network segment is also 172. If you don't modify the default docker configuration will lead to individual bases can't be accessed! List a few of the network segments used by the bases
al-Qaeda | network segment |
---|---|
Base A | 172. |
Base B | 172. |
Base C | 172. |
If you don't change the default docker configuration, it will always end up conflicting with one of the bases as more containers are created.
Refer to Expanded Knowledge: docker default subnet creation rules
I. Check the Docker network in the server
Checking docker's subnet configuration
utilizationifconfig docker
View docker's default assigned subnets
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.17.0.1 netmask 255.255.0.0 broadcast 172.17.255.255
inet6 fe80::42:f6ff:fee8:ad97 prefixlen 64 scopeid 0x20<link>
ether 02:42:f6:e8:ad:97 txqueuelen 0 (Ethernet)
RX packets 42355 bytes 67869451 (64.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 55344 bytes 9332802 (8.9 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Note: If shown here it means it is a hidden segment and needs to be changed.
Check the docker container's assigned subnets
utilizationdocker network inspect $(docker network ls -q) | grep Subnet
See if Docker has created a network
[root@yw_did_test ~]# docker network inspect $(docker network ls -q) | grep Subnet
"Subnet": "172.17.0.0/16",
"Subnet": "172.23.0.0/16",
"Subnet": "172.20.0.0/16",
If data is returned after the command is executed and the network segment is yes, it means that network has been created and a network segment with hidden problems has been assigned and needs to be changed.
Refer to Expanded Knowledge: docker default subnet creation rules
II. Modifying the default subnet
Scenario 1: New Docker installation (no running containers)
- Edit Configuration File
vi /etc/docker/
, add a new line of configuration
"bip":"192.22.0.1/24"
- Restarting docker and loading files
sudo systemctl daemon-reload && systemctl restart docker
- Then use
ifconfig docker
command to see if it takes effect, the effect is as follows:
[root@op-manager-center-prod ~]# ifconfig docker
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.22.0.1 netmask 255.255.255.0 broadcast 192.22.0.255
ether 02:42:9d:8d:d8:92 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Scenario 2: Modifying the original Docker (with running containers)
Note: If you do not manually specify a subnet when docker run, it will automatically create a subnet according to the default rules, and the changes will not take effect even if they are made according to scenario 1. For more information, see: docker default subnet creation rules.
Solution ideas and steps:
- Stop container
- Modify the default subnet according to scenario 1
- Delete the network of an existing container
- Manually associating a container's network
- Restart the container
Docker-Compose Auto-created Bridge Conflicts with LAN Solution - Know ()
Third, docker-compose modification mode
Note: docker-compose runs differently from the default docker network mode, which means that even if you modify the default subnet, docker-compose up -d is still used by default, if docker-compose can not modify the above network
Solution: Specify the network
#se version, backward compatible, I chose the highest version
version: "3.3"
# Define services
services.
# omit
network: default-network
- default-network
default-network: default-network: default-network: default-network: default-network
default-network.
driver: bridge
default-network: driver: bridge
config: subnet: 192.22.1.0/24
- subnet: 192.22.1.0/24
Expanding Knowledge
- docker default subnet creation rules
When you use the default bridged network mode (bridge), Docker creates a separate subnet for each container and assigns each subnet a CIDR address range. By default, Docker uses the 172.17.0.0/16 CIDR address range to create these subnets.
Each time you create a container, Docker selects an unused subnet from this CIDR address range and assigns the container to an IP address in that subnet.
Let's say you have 10 containers running and each container is on a separate subnet. The IP range for each subnet is /16, which means that each subnet has approximately 65,534 available IP addresses (excluding network and broadcast addresses).
By default, Docker assigns the IP addresses of the subnets sequentially, with the IP ranges for each subnet as shown below:
Subnet 1: 172.17.0.1 - 172.17.255.254
Subnet 2: 172.18.0.1 - 172.18.255.254
Subnet 3: 172.19.0.1 - 172.19.255.254
Subnet 4: 172.20.0.1 - 172.20.255.254
Subnet 5: 172.21.0.1 - 172.21.255.254
Subnet 6: 172.22.0.1 - 172.22.255.254
Subnet 7: 172.23.0.1 - 172.23.255.254
Subnet 8: 172.24.0.1 - 172.24.255.254
Subnet 9: 172.25.0.1 - 172.25.255.254
Subnet 10: 172.26.0.1 - 172.26.255.254