> The project should have a single Dockerfile from which dev/test/staging/production work from.
I don't agree with this largely, I think because we actually substantially agree about the need to test regularly in an environment identical to staging/production during development. I DO agree that there should be a single Dockerfile to be used as the basis, and I DO agree that you should regularly run that Dockerfile in dev/test/staging/production unmodified.
But part of the point is that there is no reason to limit yourself to a single dev instance of your app. I appreciate that might have been somewhat obscured because of some of my examples, which uses a separate dev container setup that I use for some projects as the base, including as a base for the production container for my blog.
So to reiterate, I absolutely agree with having a Dockerfile that is identical to your live environment to bring up an instance with during development.
But that is not a reason to not _also_ have a container that bring it up with a code reloader, or a container that lets you test in different environments. And it certainly is not a reason to avoid isolating dev/build dependencies into yet other containers.
I actually much prefer that to the "Rails way" of having separate environments "built into" the app, and that's probably part of the difference. Instead of doing that, I use "FROM" in Dockerfiles to "inherit" from bases to provide me with different "lenses" to work on the project from different viewpoints. Not just dev vs. live, but also with debugging tools, or architecture differences etc.
> Sometimes it is neccessary to have some tools like gdb, strace, etc, available within the container. For this you can startup the container as you normally would, then (with Docker 1.3) `docker exec -it /bin/bash`, install the tools I need to debug something, and get out.
But there's no reason to keep redoing these steps when they can be encapsulated in a Dockerfile that inherits from your basic container. And you can easily run it in parallel with your "pristine" containers, or bring it up in seconds as needed.
> In general it is just going to be bad practice to have a significantly different from the production env, and is indeed why dev handoff to production is often wrought with trouble.
We fully agree with this. It's a decade of frustration doing devops that has made me enjoy the opportunities Docker brings to layer situation-specific dependencies on top of a pristine base: It takes away any excuse for letting the basic setup diverge, or for being unable to run full tests on an environment identical to live.