Beta9 broke some network-related behavior I was relying on, but maybe the problem is a compose or docker bug, or maybe I’ve been relying on unintended behavior.
Expected behavior
If no network config is specified in docker-compose.yml the containers started by compose should be on the “bridge” network. This is (typically?) 172.17.. and has the really nice property of being internal to docker but still accessible by “docker build” commands. That makes it good for running build caches like polipo, apt-cacher-ng, npm-lazy, etc.
Plain docker run behaves as expected (container is on 172.17..), why not containers started by docker-compose?
$ docker run debian:jessie ip addr show | grep 172
inet 172.17.0.3/16 scope global eth0
Not sure if this is the problem, but I believe that if you absolutely need to rely on the “docker0” IP range you must set the “–bip” (or “–fixed-cidr”) daemon options.
In Docker for Mac (beta) this is done with the pinata tool:
pinata set daemon @myoptions.json
Where “myoption.json” is a JSON file containing the daemon options. This is a replacement all options, so just make sure you preserve current options on your file, by reading them before with:
I’m also having this problem, nothing works with beta9 & images trying to connect to 172.17.0.x. I’ve tried setting bip to 172.17.0.0/16 but Docker doesn’t start when I do that. Trying the same with fixed-cidr makes Docker start, but things continue to be broken.
Can someone post what options need to be set for this to work again as before?