Docker-Compose Network Gotcha

So, you’ve installed Docker, which is great. Then maybe you tried to access your shiny new containers across a controlled internal IP space (like VPN or maybe an office or campus network) and simply couldn’t because Docker by default gobbles up a pretty big internal range:

{
  "Subnet": "172.17.0.1/16",
  "Gateway": "172.17.0.1"
}

The above is from running “docker network inspect bridge”. This maps to your docker0 network interface.

Get Jacob Beatty’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Now, you’re pretty savvy and you probably found out you can overwrite this behavior by creating /etc/docker/daemon.json and filling it with something like:

{
  "bip":"10.10.10.1/22",
  "fixed-cidr":"10.10.10.0/22"
}

Which is great! Until you use docker-compose and it creates its own network adapters and it’s back to that 172.17.0.1/16 subnet. Okay, groovy, you know you can specify a custom network directive in your docker-compose.yml, problem solved:

version: '2'
services:
  web1:
    image: tomcat:8.0
    ports:
      - 8080
    networks: 
    - app
  web2:
    image: tomcat:8.0
    ports:
      - 8080
    networks:
    - app
networks:
  app:
    ipam:
      driver: default
      config:
        - subnet: 10.10.11.1/22

Note: The above is just a super basic example to show the structure of the solution.

Except that the problem is not solved, you still see that pesky interface and route using the problem subnet. Well, this then is the final piece you may be missing:

$ docker network ls
<output here>
$ docker network inspect <id>
<confirm it has the conflicting subnet>
$ docker network rm <id>

Now you’ll want to docker-compose down and then restart docker as well. Now, when you docker-compose up you should be good to go.

Final Note: All examples including IP ranges are just that, examples. You will need to determine your own needs for subnetting.