With beta9 compose no longer starts services on 172.17.*.*

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

Actual behavior

With this docker-compose.yml:

version: '2'
services:
  aptcacherng:
    restart: always
    image: sameersbn/apt-cacher-ng
    ports:
      - "3142:3142"

Run 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...

Information

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

Okay Ignore docker-compose for now.

Before beta9 this docker run (even without port specifier “172.17.0.1:”) publishes the container’s port on 172.17.0.1.

docker run -d --name aptcacherng --net=bridge -p "172.17.0.1:3142:3142" sameersbn/apt-cacher-ng 

And docker build provides access to 172.17.0.1, so a Dockerfile like this builds:

FROM debian:jessie
RUN curl -i http://172.17.0.1:3142

This still works on the below debian-based docker server, but Docker for Mac reports:

docker: Error response from daemon: driver failed programming external connectivity on endpoint aptcacherng (fece3a7d783553723ff3acbda8b4d17273844feb895fc382d8c243a94e4b44c9): Error starting userland proxy: Failed to bind TCP 172.17.0.1:9999 Unix.Unix_error(Unix.EADDRNOTAVAIL, "bind", "").

Have I been relying on unspecified behavior, or is this a bug in Docker for Mac?

 docker info
Containers: 102
 Running: 46
 Paused: 0
 Stopped: 56
Images: 1616
Server Version: 1.11.0
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 1307
 Dirperm1 Supported: false
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: null host bridge
Kernel Version: 3.13.0-85-generic
Operating System: Ubuntu 14.04.4 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.66 GiB
Name: docker.tx.caringo.com
ID: WLPF:2L3Q:IBZJ:QSUH:L7IA:HHKX:6K5T:XIUQ:M6DY:P26W:K7HP:VDVS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Labels:
 provider=generic

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:

pinata get daemon

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?

Thanks