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?

3 Answers 3


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.

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.


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.

  • thanks for your input, I think this is hard to answer. My point is more when using dockerfile to install packages. In my oppinion, you install it once, snapshot and commit. if you need to replace it you re-install, commit again. Installing this packages via docker file seems to defeat the point.
    – bitoiu
    Nov 24, 2013 at 21:37
  • Just started looking at Dockerfile but my take is it can be useful to document how the container was created. Yes, Chef/Puppet or whatever else are not replaced by Dockerfile IMO. My 2 cents.
    – jipiboily
    Nov 25, 2013 at 12:20
  • I'm not talking about the specific technology but the concept: docker says it's bad to run package managers at different points in time to create a machine state (got it!). however it goes against that when in their tutorial they build a machine from a set of "apt-gets". The concept is the same, bower downloads web packages, "apt-get" installs linux packages. Why is one bad and the other "ok".
    – bitoiu
    Nov 25, 2013 at 16:33
  • I think we are diverting the question (1) to a discussion and (2) to something different. Initially it was about the necessity or lack of, of Dockerfile. I believe it is necessary, even if it will not get used for installing packages. So answering your question, docker file is NOT the same as running chef etc. Nov 26, 2013 at 11:25
  • For the specifics of apt-get, there can be some debate: a counter question would be: how else would you kickstart a chef/puppet/any other DevOps agent from within a container? Nov 26, 2013 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.