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 u

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_volumes/ 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.