> * Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land?

The question doesn't really make sense: The equivalent is supervisord running inside the lxc container.

> * Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?"

How do you tell them in a cluster? This is a problem anyone who's ever needed to scale a system beyond a single server has already had to deal with, whether or not the application is package up a container, and there's a plethora of solutions, ranging from hardcoding it in config files, to LDAP or DNS based approaches, to things like Zookeeper or Doozer, to keeping all the config data in a database server (and hardcoding the dsn for that), to rsyncing files with all the config data to all the servers, and lots more.

I'm not sure there's going to be a bullet-proof solution to this. I believe that Docker is the right step forward, especially for the application containers. What I have been tinkering with is the idea of having smaller, configurable pieces of infrastructure and then providing a simple tool on top of that (e.g. 'heroku' CLI).

Once you are past the procurement and provisioning steps you really need a way to describe how to wire everything together. I definitely haven't solved it yet but I sure hope to! :)

Take a look at "juju". Canonical is doing a bunch of stuff in this area. Juju does service orchestration across containers. I don't particularly like how they've done it, but it shows a fairly typical approach (scripts that expose a standard interface for associating a service to another, coupled with a tool that lets you mutate a description of your entire environment and translates that into calls to the scripts of the various containers/vms that should be "connected" in some way to add or remove the relations between them)

What don't you like about Juju's approach, and what do you think the right way would be?

To be fair, it's been a while since I've looked at it, so it could have matured quite a while. I should give it more of a chance. My impression was probably also coloured by not liking Python... Other than that, the main objection I had was that it seemed on one hand that writing charms seemed over-complicated (might have been coloured by the Pyhthon examples..) , and that there seemed to be too much "magic" in the examples. But I looked right after it was released, so it's definitively time for another look.

(EDIT: It actually does look vastly improved over last time; not least the documentation)

Specifically, I run a private cloud at work across a few dozen servers and a bit over a hundred VMs currently, and we very much need control over which physical servers we deploy to because the age and capabilities varies a lot - ranging from ancient single CPU servers to 32 core monstrosities stuffed full of SSDs. They're also in two data centres.

When I last looked at juju it seemed to lack a simple way to specify machines or data centres. I just looked at the site again and it has a "set-constraint" command now that seems to do that.

The second issue is/was deployment. OpenStack or EC2 used to be the only options for deploying other than locally. Local deployment was possible via LXC. EC2 is ludicrously expensive, and OpenStack is ridiculous overkill to us compared to our current system (which is OpenVz - our stack predates LXC - managed via a few hundred lines of Ruby script) .

I don't know if that has changed (will look, though, when I get time away from an annoying IP renumbering exercise...), but we'd need either a lighter option ("bare" LXC or something like Docker on each host would both be ok) or an easy way to hook in our own provisioning script.

(EDIT: I see they've added support for deployment via MAAS at least, which is a great)

Docker will soon expose a simple API for service discovery and wiring. This will standardize 1) how containers look each other up and 2) how sysadmins specify the relationship. The actual wiring is done by a plugin, so you are free to choose the best mechanism - dns, juju, mesos/zookeeper, or just manual configuration.

> The question doesn't really make sense: The equivalent is supervisord running inside the lxc container.

So the solution is to "batch up" a load of apps into one container and run with supervisor or something as per my last bullet? I had pretty much envisaged a one docker container per application type of model...

You can do that too. But that is a very different setup. If you build "single application" containers, then the container will stop if the application stops, and you can run supervisord from the host, configured to bring up the container.

If you build full containers, with a single application, you probably still want supervisord inside each container. EDIT: This is because the container will remain up as long as whatever is specified as the "init" of the container stays up, so in this case your app can die without bringing down the container, and something needs to be able to detect it.

Hi, I'm the lead maintainer of Docker.

> The data? I can see postgres, redis or whatever being packaged up into containers, but what about the data that they use? Will there be attachable storage? Will you share some exposed resource on the host? Will the data be another container on top of the database app container?

Docker supports persistent data volumes, which can be shared between containers, between the underlying host and the container, or both.

Here's a basic example: http://docs.docker.io/en/latest/examples/couchdb_data_volume...

> Routing. How do you tell your reporting/web app containers "this is where your message bus and database live?"

For now, docker leaves that to companion tools - which typically pass the information via command-line argument, environment variable, or some sort of network service (dns or some other custom protocol).

In the near future Docker will include a more standard way for containers to discover each other. Just like the rest of Docker, we will try hard to make it simple and easy to customize.

> Coordination. I'm used to using something like supervisord to control my processes - what's the equivalent in docker land? Replace the scripts in supervisord with the equivalent dockerized apps? A docker file for the host specifying what to run? How do you know if your app that you've run inside docker has crashed?

Docker itself monitors the process, so you could use it as a process monitor - but it's probably better to couple it with a more standard process supervisor, like supervisord, runit, upstart, systemd etc.

There are 2 ways to combine docker with a supervisor: docker on the inside, or docker on the outside. Both are used in the wild, but I think "docker in the inside" makes more sense. That is, have your init process monitor docker at boot, and make sure it's restarted if necessary.

> Or do you just package the whole lot above up into one container?

You can also do that (and some people do), which leads to the "docker on the outside" scenario, with supervisord or runit inside managing X processes. I would only recommend this as a stopgap, if you are unable or unwilling to break down your stack into multiple containers.

In the long run multiple containers is the way to go. It makes your stack easier to scale, maintain and upgrade.