I think this issue somewhat compromises Dockerfiles as a means of distributing applications. With a VM, you can supply something in a minimally configured, plug-and-play state, and then leave it to the user to set it up. With Docker, it's a little bit too painful to configure things after running an image. I'm not sure what the answer to this is.
Which is it: Minimally configured, or plug-and-play?
Either you'll be setting up your containers to prepare you to use something like Chef or Puppet against the, or you'll be setting up your containers to be fully configured apart from connection details to other components.
That last bit is down to service orchestration, which is outside the scope of Docker as far as I understand it. You can "roll your own" easily enough: Write a "/usr/local/bin/add-relation" script that takes a function and a list of arguments to configure that function.
Write a script that reads a config file that defines the relationships between container types (e.g. your MySQL container and your Web container), and triggers execution of those add-relation scripts. E.g. your Web container gets called with "add-relation Mysql --ip [foo] --username [bar] --password [baz]" and the version of the script in that container knows how to add users to MySQL.
That is very roughly the approach that Juju (Ubuntu's orchestration system) takes.
The point is to split all configuration details into thress classes: Those that can be set statically on build. Those that can be decided on first boot (e.g. re-generate a ssh-host-key, get IP address etc.). And finally those that needs to be set dynamically based on what other containers are spun up.
The latter has no place in the Dockerfiles or images, but scripts or tools to set these config details based on input from some external source, does.
It may sound painful, but only if you do it to a handful of vm's that rarely change. The moment you need to manage dozens, or need to spin vm's up and down regularly, taking the effort to set up proper orchestration, whichever method you prefers, wins hands down to having a user set it up (I can guarantee with near 100% certainty that said user will not set them up different VMs consistently).
