Doesn't dockerfile initial configuration defeat one of the key arguments of docker?

Question

I'm very excited about Docker, if you're a developer in a big project you've suffered too much at the machine hands of environments and multi-platforms.

One of the key selling points of Docker is that by snapshotting/committing image state you avoid the risk of building an environment with a different version, possibly incompatible, of a given dependency. I get that, great!

Doing the tutorials on dockerfile, isn't this exactly the same concept as running npm, chef or bower. Of course unix libraries would be more stable than most of the ones found on these library stores I just mentioned but isn't this the same workflow that docker is fighting?

Isn't the goal to tailor a container to your needs and then commit it's state to then multiply at will?

Am I missing something trivial, or this is the case? Does docker still gives you a chance for building up images from script files and by that it steps on it's toes?

Answer 1

Docker says it's bad to run package managers at different points in time

...

however it goes against that when in their tutorial they build a machine from a set of "apt-gets"

Docker says:

• ... it's great to have package managers (like apt/yum/npm/bower)
• ... they work very well for "please install these packages at their newest versions (i.e. as of now)"
• ... they make it tricky (or in some cases outright impossible) to replicate to production:
  • "install on prod what has been installed during our successful test which happened 11 days ago"
  • ... exactly the same set of packages, nothing less, nothing more
  • ... with exactly the same versions
  • ... containing the same raw bytes
  • not forgetting about your "nested" package manager (for example some projects first use yum, and then pip or npm underneath)
  • along with any files that are needed by application, but not maintained by any package manager
  • clearly specifying what does change between test and prod
• ...while Docker makes all that quite easy.

Answer 2

Containers/docker are a lot easier for developers to wrap their heads around for local development, and it eliminates the requirement of the whole team understanding how to utilize your config management system of choice glued together with Vagrant. Docker containers are similar to virtual machines, but there are key differences.

All of the dependencies of the application are bundled with the container which means no need to build on the fly on every server during deployment. This results in much faster deployments and rollbacks. With configuration management tools, you’ll have to redo the same steps for each deployment. This means it’s harder to keep track of software releases and dependencies.

Another difference is that Dockerfiles do not give you the same level of control over the configuration as your application transitions between environments, like dev, staging, and production. You can get into a situation where your Dockerfile has to call an external script that edits config files in the docker image on the fly. If you'd like more information take a look at this container wiki.

Answer 3

I had a discussion at a conference this week about the same thing, having more or less the same question.

Because there seems to be some overlap, a good practice, based on my understanding is that with a Dockerfile you will get the container to an initial state from which you can then utilise a DevOps framework (or npm or bower).

Dockerfile might also speed the things up, since slices might inherit from a better initial state, in case this is required. Example if you have installed "g++" from within the Dockerfile, each instance you spawn, will not need to download it, which will be the case for Chef, running on a "bare metal" machine.

At last, I think that we need to consider where there is no overlap, for things that can be done only on from within the Dockerfile, like which ports to map, etc. So it is necessary at least for this. As an example:

FROM ubuntu

I suppose you cannot say to a DevOps tool: "make this node an ubuntu instance".

I am a bit new in this territory and also this territory is new, so the validity of this answer might fluctuate with time.