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.
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.
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
With this docker-compose.yml:
version: '2' services: aptcacherng: restart: always image: sameersbn/apt-cacher-ng ports: - "3142:3142"
docker-compose up -d then
$ docker-compose exec aptcacherng ip addr show | grep 172 inet 172.23.0.2/16 scope global eth0
Why is it on 172.23.. instead of 172.17.. like the
docker run container? Until beta9 the service would be on 172.17...
OS X: version 10.11.4 (build: 15E65) Docker.app: version v1.11.0-beta9 Running diagnostic tests: [OK] docker-cli [OK] Moby booted [OK] driver.amd64-linux [OK] vmnetd [OK] osxfs [OK] db [OK] slirp [OK] menubar [OK] environment [OK] Docker [OK] VT-x Error exec: echo "00000003.0000f3a6" | nc -U /var/tmp/com.docker.vsock/connect > /tmp/20160429-115640/diagnostics.tar: exit 1