I've struggled with Docker, and getting it to play nicely with our workflow, principally around the issue of container IP resolution at runtime:

the linking of containers only works if it is done in the correct order. If you decide to restart / rebuild your database container (for instance, to reset the data to a known state), and the assigned IP changes, your downstream App container will no longer link to the correct container.

I thought that Skydock would be the solution - as a DNS server that would handle the resolution of deterministic container names to dynamic IPs (assigned on container startup). Turned out to be a much more complete, and therefore complex, product than I had hoped, and it added more problems than it solved.

I think the underlying issue is that docker, containers, and I are fundamentally solving different problems. The core docker use case is how to run and manage containers, at scale, in a production environment. My use case is getting to a simple, repeatable, local developer environment that includes common builds of the core components (redis, memcache, postgres, django, elasticsearch). The kicker is that precisely because this is a developer's environment the containers need to be updated, torn down, restarted, repeatedly, by design. This is almost the inverse of a standard containerised deployment.

Anyhoo, the latest DNS solution comes from Tõnis Tiigi and is called dnsdock. The intro to dnsdock includes this:

Simplified version of crosbymichael/skydock.[...] Does not use any distributed storage and is meant to be used only inside single host.

This sounds much closer to my own situation. I won't set my own expectations too high given the problems I've already had, but I'm (secretly) hopeful...