Support new Docker networking idioms

[aanand]

Docker 1.7 will introduce the top-level concept of a "network", accompanied by new CLI and API functionality. Compose should add support for networks, which might involve one or both of:

• putting all containers in a project-wide network
• adding a network key so that users can enable more specific inter-service communication

[aanand]

[Pinging @dave-tucker and @mavenugo in case I've made any basic errors here.]

Here's the shortest possible explanation of how networks will be used in the Docker CLI:

$ docker run -d --name c1 ...
$ docker run -d --name c2 ...
$ docker networks create mynetwork
$ docker networks attach mynetwork c1 foo
$ docker networks attach mynetwork c2 bar

c1 and c2 can now communicate with one another within the network mynetwork. Each has an IP address in mynetwork, and each one is addressable by its given hostname (foo, bar) by other containers in mynetwork.

Behind the scenes, a network can be implemented by one of many drivers. There'll be a basic driver enabling basic single-host inter-container communication, but people can implement more capable drivers which can provide cross-host communication (as well as, presumably, all sorts of other cool stuff).

I see two obvious approaches we could take to networking UX in Compose:

1. Create a default network for each Compose application, and put all containers in it under the service name

This is cool because it involves no new stuff to learn, and in fact users now have less to know about - you delete your links entry and everything will still work:

web:
  build: .
  ports: ["80:8000"]
redis:
  image: redis

Behind the scenes, when you run docker-compose up, Compose will:

• Create a network, presumably named after the project
• Attach the web container to the network with the name web
• Attach the redis container to the network with the name redis

Then the web container can connect to the hostname redis, just as with links.
2. Require users to explicitly specify networks

Here, you'd have a networks key for explicitly putting containers in networks, and anything not explicitly attached would be isolated:

web:
  build: .
  ports: ["80:8000"]
  networks:
    - mynetwork
redis:
  image: redis
  networks:
    - mynetwork
redisbackup:
  build: ./redis-backup
  volumes_from: redis
  # not attached to any networks

You'd also (presumably) be able to specify explicit hostnames to join as:

networks:
  - mynetwork:redis
  - othernetwork:persistence

Here are some things to think about:

• Approach 1 is fantastic from a first-time UX standpoint, but is quite prescriptive, and not going to work for everyone. Can people disable it? How?
• Approach 2 is nice in that it's opt-in, which might make sense while people are still widely using links, but it's very verbose.
• Approach 2 also has the nice property of enabling communication with containers not managed by the current Compose app, or by Compose at all.
• Can we implement both approaches? How would they interact?
• How will networks interact with links? (This is partly a question for the networking team.)

[dave-tucker]

Quoting from libnetwork's roadmap

The container network model assumes the following axioms about how libnetwork provides network connectivity to containers:

• All containers on a specific network can communicate with each other freely.
• Multiple networks are the way to segment traffic between containers and should be supported by all drivers.
• Multiple endpoints per container are the way to join a container to multiple networks.

The following is how I would envisage that you would create a compose.yml for a 3-tier app

web:
  build: .
  ports: ["80:8000"]
  networks:
    - frontend
    - middle
foo:
  image: myorg/foo
  networks:
    - middle
    - backend
db:
  image: postgres
  networks:
    - backend  

Note that the cool thing here is that I could easily add more containers as needed to help scale out my service.

Re: Option 1, it would work as described except, you would have one network per compose.yml. Does compose have a way of generating a name for this network?

Re: Option 2, the default behavior isn't being isolated, it's as per Docker 1.6 when you create a container without a --net flag. It will belong on the default "bridge" network and as such can talk to other containers on that network, but it won't be able to see other container on other networks.

Finally, with regard to links I don't think we have all the details worked out as yet. I'll create an issue in libnetwork to discuss it further.

[aanand]

Thanks. Your example looks good - perhaps we should make that the canonical use case. (I presume foo is the application server and web is a proxy such as nginx?)

Re: Option 1, it would work as described except, you would have one network per compose.yml.

Yeah, one network per compose.yml is what I was imagining - I've updated my comment accordingly.

Does compose have a way of generating a name for this network?

Yep - we already have the concept of a "project name", which defaults to the (munged) basename of the current directory.

It will belong on the default "bridge" network and as such can talk to other containers on that network, but it won't be able to see other container on other networks.

OK, that's sensible and unsurprising, but in that case how do I create a container without it joining the "bridge" network? Or will it leave the "bridge" network as soon as I attach it to another?

Finally, will it be possible to specify networks to join at container creation time, or will attaching after the fact be the only way to do it? (This is really a Docker API/CLI design question.)

[mavenugo]

OK, that's sensible and unsurprising, but in that case how do I create a container without it joining the "bridge" network? Or will it leave the "bridge" network as soon as I attach it to another?
Finally, will it be possible to specify networks to join at container creation time, or will attaching after the fact be the only way to do it? (This is really a Docker API/CLI design question.)

Yes. docker run command's -net option will be enhanced to include the "Network", like docker run --net=frontend ....

[squaremo]

@aanand You may want to keep an eye on moby/moby#13441, which represents the UI part of the Docker integration of libnetwork.

[NickClark]

👍 Definitely looking forward to this (and needing it)

[squaremo]

You may want to keep an eye on moby/moby#13441

Scratch that, the whole thing went pear-shaped. Now I don't know what you should be looking at :(