Docker binding fixed IP/cross-host container mutual access operation

Preface

Previously, static IPs assigned using pipework were temporary and would become invalid after a reboot. In addition, the IPs of physical machines, virtual machines, and Docker containers bound using pipework were all in the same network segment, which was very difficult in a production environment. Now, we use Docker's own network to implement fixed IP allocation, which will not disappear after a reboot.

Environment Introduction

Binding Steps

First operate the 192.168.1.105 virtual machine

Step 1: Create a custom network

docker network create --subnet=172.172.0.0/24 docker-br0

Note: The 172.172.0.0 network segment is selected here, and you can also specify any other free network segment. docker-br0 is the name of the custom bridge, which can be named arbitrarily.

Note: The subnet mask here should be 255.255.255.0, which is the 24 after the IP, because I will use iptables to configure the routing table later. I used 255.255.0.0 before and it couldn't be configured. So I configured it to 24 here.

After creating the bridge, use ifconfig to view an additional bridge, which will be automatically displayed after Docker is started or restarted. Permanently, you can use docker network rm docker-br0 to remove the bridge.

Step 2: Select any IP address in your custom network segment as the IP address you want to start the container

docker run -i -d --net docker-br0 --ip 172.172.0.10 --name nginx -v /usr/local/software/:/mnt/software/ 3bee3060bfc8 /bin/bash

Note: When creating the container, 172.172.0.10 was selected as the static IP address in the network segment created in the first step. And start with the docker-br0 bridge. -v is mount, indicating which local directory needs to be mounted into the container. 3bee3060bfc8 is the image ID

Use docker exec -it nginx /bin/bash to enter the started container, use yum install net-tools to download iptables and then use ifconfig to view the container IP

Step 3: Test whether the local machine and the container can ping each other

#Test ping Baidu [root@e98109ef9fd6 /]# ping www.baidu.com
PING www.a.shifen.com (119.75.213.61) 56(84) bytes of data.
64 bytes from 119.75.213.61 (119.75.213.61): icmp_seq=1 ttl=56 time=10.1 ms
64 bytes from 119.75.213.61 (119.75.213.61): icmp_seq=2 ttl=56 time=8.26 ms
 
#Test host [root@e98109ef9fd6 /]# ping 192.168.1.105
PING 192.168.1.105 (192.168.1.105) 56(84) bytes of data.
64 bytes from 192.168.1.105: icmp_seq=1 ttl=64 time=0.099 ms
64 bytes from 192.168.1.105: icmp_seq=2 ttl=64 time=0.081 ms
 
#Test ping another virtual machine [root@e98109ef9fd6 /]# ping 192.168.1.106
PING 192.168.1.106 (192.168.1.106) 56(84) bytes of data.
64 bytes from 192.168.1.106: icmp_seq=1 ttl=63 time=1.67 ms
64 bytes from 192.168.1.106: icmp_seq=2 ttl=63 time=0.587 ms

At this point, binding a fixed IP address to the container has been completed. The following is how containers can access each other across hosts.

Cross-host container access

Step 4: On the 192.168.1.106 virtual machine, bind the container to a fixed IP address, following the steps 1 to 3 above.

Step 5: Access each other in the two containers and find that cross-host container access cannot be pinged.

[root@e98109ef9fd6 /]# ping 172.172.1.10
PING 172.172.1.10 (172.172.1.10) 56(84) bytes of data.
From 192.168.1.105 icmp_seq=1 Destination Host Unreachable
From 192.168.1.105 icmp_seq=2 Destination Host Unreachable
From 192.168.1.105 icmp_seq=3 Destination Host Unreachable
 
[root@e98109ef9fd6 /]# ping 172.172.0.10
PING 172.172.0.10 (172.172.0.10) 56(84) bytes of data.
From 192.168.1.106 icmp_seq=1 Destination Host Unreachable
From 192.168.1.106 icmp_seq=2 Destination Host Unreachable
From 192.168.1.106 icmp_seq=3 Destination Host Unreachable

Step 6: Configure the routing table

#Add routing rules

ip route add The ip network segment/subnet mask of the other container via The ip dev of the other virtual machine communicates through which network card

like:

ip route add 172.172.1.0/24 via 192.168.1.106 dev eno16777736

After adding, you can use the route command to view the added rules, or use ip route del 172.172.1.0/24 to remove the routing rules.

Add corresponding routing rules on the 192.168.1.105 and 192.168.1.106 virtual machines respectively!

192.168.1.105: ip route add 172.172.1.0/24 via 192.168.1.106 dev eno16777736

192.168.1.106: ip route add 172.172.0.0/24 via 192.168.1.105 dev eno16777736

Step 7: Access each other in the two containers and find that cross-host containers can ping each other.

[root@e98109ef9fd6 /]# ping 172.172.1.10
PING 172.172.1.10 (172.172.1.10) 56(84) bytes of data.
64 bytes from 172.172.1.10: icmp_seq=1 ttl=62 time=0.636 ms
64 bytes from 172.172.1.10: icmp_seq=2 ttl=62 time=0.411 ms
64 bytes from 172.172.1.10: icmp_seq=3 ttl=62 time=0.472 ms
 
[root@8343ad7e7f0f /]# ping 172.172.0.10
PING 172.172.0.10 (172.172.0.10) 56(84) bytes of data.
64 bytes from 172.172.0.10: icmp_seq=1 ttl=62 time=0.920 ms
64 bytes from 172.172.0.10: icmp_seq=2 ttl=62 time=0.674 ms
64 bytes from 172.172.0.10: icmp_seq=3 ttl=62 time=0.657 ms

Additional knowledge: docker-compose custom network, fixed container IP address

Due to the default bridge network, the IP address will change after restarting the container. In some scenarios we want to fix the container IP address.

Docker-compose is an orchestration tool for Docker, which creates networks, containers, etc. relative to the command mode.

Using configuration files is relatively more convenient and can trace problems.

Paste the docker-compose.yml file directly

version: '2'
services:
  nginx:
   image: nginx:1.13.12
   container_name: nginx
   restart: always
   tty: true
   networks:
     extnetwork:
      ipv4_address: 172.19.0.2
 
networks:
  extnetwork:
   ipam:
     config:
     - subnet: 172.19.0.0/16
      gateway: 172.19.0.1

illustrate:

gateway is the gateway address

subnet is the network segment

extnetwork is a custom network name

In the above configuration, our nginx container has a fixed IP of 172.19.0.2

Example, custom network mode:

version: '2'
services:
  nginx:
   image: nginx:1.13.12
   container_name: nginx
   restart: always
   networks:
     extnetwork:
   ports:
     - 80:80
   volumes:
     - '/nginx/conf.d:/etc/nginx/conf.d'
  nginx2:
   image: nginx:1.13.12
   container_name: nginx2
   restart: always
   networks:
     extnetwork:
      ipv4_address: 172.19.0.2
     
  db:
   image:mysql:5.7
   container_name: db
   volumes:
    - /var/lib/mysql:/var/lib/mysql
   restart: always
   networks:
     extnetwork:
   ports:
     -3306:3306
   environment:
    MYSQL_ROOT_PASSWORD: wordpress
    MYSQL_DATABASE: wordpress
    MYSQL_USER: wordpress
    MYSQL_PASSWORD: wordpress   
  
  wordpress:
   image: wordpress:latest
   container_name: wordpress
   depends_on:
     -db
   ports:
     - "8000:80"
   restart: always
   networks:
     extnetwork:
   environment:
     WORDPRESS_DB_HOST: db:3306
     WORDPRESS_DB_NAME: wordpress
     WORDPRESS_DB_USER: wordpress
     WORDPRESS_DB_PASSWORD: wordpress
networks:
  extnetwork:
   ipam:
     config:
     - subnet: 172.19.0.0/16
      gateway: 172.19.0.1

The above article about Docker binding fixed IP/cross-host container mutual access operation is all the content that the editor shares with you. I hope it can give you a reference. I also hope that you will support 123WORDPRESS.COM.