5 ms·

To be honest, I'm very much against this approach to containerized development. The project should have a single Dockerfile from which dev/test/staging/product

To be honest, I'm very much against this approach to containerized development. The project should have a single Dockerfile from which dev/test/staging/production work from. There are certaily things you may want to change in these envs (particularly dev and test) but these can be runtime configurations (through env vars or changing the command that gets run in the container). When I do dev, if I need to do so interactively I build from my main dockerfile and do `docker run -v $(pwd):/opt/myapp myapp bash`, which mounts my live code into the container, overwriting the code that was built in. I'll mess around with some things, exit and adjust my Dockerfile if needed based on those changes. To run tests (as an example): `docker run -e RAILS_ENV test -v $(pwd):/opt/myapp myapp rake test` If all is well and I'm ready to push my code up, go ahead and rebuild the image with the changed code, run the tests again, 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. 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.

vidarh 12y ago
> 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.
- msane 12y ago
  The only difference between dev/stage/prod/whathaveyou with docker is the topography of the servers. For the (local) dev case, the topography is 1 box; an "all-in-one" system. This does not require you to have different dockerfiles per environment, it just means you have to make dockerfiles that don't care about the topography!
mh-cx 12y ago
I couldn't agree more.
bibonix 12y ago
Totally agree!

vidarh 12y ago

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

msane 12y ago
The only difference between dev/stage/prod/whathaveyou with docker is the topography of the servers. For the (local) dev case, the topography is 1 box; an "all-in-one" system. This does not require you to have different dockerfiles per environment, it just means you have to make dockerfiles that don't care about the topography!

mh-cx 12y ago

I couldn't agree more.

bibonix 12y ago

Totally agree!