In using docker compose to modernize some of my apps (including this wiki) I discovered some network awkwardness. The first problem I experienced was when I was setting up a new Wordpress, using the following docker-compose.yml:

docker-compose.yml

version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: **********
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: **********
   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: **********
volumes:
    db_data:

Being largely unchanged from the YAML provided on the Docker Hub page dedicated to the project I expected this to work, and it kind of did. The problem was as soon as I ran docker-compose up -d I lost my remote connection to the machine. I discovered the problem remarkably fast given the oddness of the issue. My local network in my home is on the subnet 172.18.0.0/24, which just happens to be the same subnet that gets built for the docker0 internal network. This means that after the docker daemon brought up that network, the host OS stopped using the default route to get to my home network. It should be noted that my home network has a routed VPN to the network where that host exists; if I was crossing the Internet without tunneling my network the problem wouldn't have occurred.

The solution to this particular networking problem comes from modifying /etc/docker/daemon.json. On my machine this file was empty before I made the change, which ultimately resulted in this:

daemon.json

{
  "bip": "10.255.255.1/24",
  "fixed-cidr": "10.255.255.0/25"
}

After restarting the docker daemon I still had to down and up my Wordpress to get the reconfigured network to function properly.

Moving past the last problem took me directly into my next problem. Wordpress came up and there were no ugly log entries, however I still couldn't get to the app. The behavior was strikingly similar to the last problem… just nothing. I could see the requests in the log, but I was very clearly not getting replies to my browser. A quick look at the new network created docker network inspect wp1_default (not the docker0 network, but the Wordpress/MySQL network) illustrated my new issue; this network's subnet also overlapped with other local subnets in my environment. This time the network in question was 172.17.0.0/16, a segment that I parse up into multiple /24 subnets in my server environment for various reasons.

So the problem is the same, but in this case the place to fix it is different. Moreover it seems this is something of a “docker-compose” default and I was unable to identify where I would be able to change that behavior. As such each app spun up on my network will require changes similar to the following:

docker-compose.yml

version: '3.3'
 
services:
   db:
     image: mysql:5.7
     networks:
       default:
         aliases:
           - wordpress.internal.com
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: **********
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: **********
   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     networks:
       default:
         aliases:
           - wordpress.internal.com
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: **********
volumes:
    db_data:

networks:
  default:
    driver: bridge
    ipam:
      driver: default
      config:
      - subnet: 10.255.254.0/24

Again, after this process I had to down and up, but directly afterwards all my life was good.