docker - Should I use Dockerfiles or image commits?

Question

I'm a little bit confused about these two options. They appear to be related. However, they're not really compatible.

For example, it seems that using Dockerfiles means that you shouldn't really be committing to images, because you should really just track the Dockerfile in git and make changes to that. Then there's no ambiguity about what is authoritative.

However, image commits seem really nice. It's so great that you could just modify a container directly and tag the changes to create another image. I understand that you can even get something like a filesystem diff from an image commit history. Awesome. But then you shouldn't use Dockerfiles. Otherwise, if you made an image commit, you'd have to go back to your Dockerfile and make some change which represents what you did.

So I'm torn. I love the idea of image commits: that you don't have to represent your image state in a Dockerfile -- you can just track it directly. But I'm uneasy about giving up the idea of some kind of manifest file which gives you a quick overview of what's in an image. It's also disconcerting to see two features in the same software package which seem to be incompatible.

Does anyone have any thoughts on this? Is it considered bad practice to use image commits? Or should I just let go of my attachment to manifest files from my Puppet days? What should I do?

Update:

To all those who think this is an opinion-based question, I'm not so sure. There are some subjective qualities to it, but I think it's mostly an objective question. Furthermore, I believe a good discussion on this topic will be informative.

In the end, I hope that anyone reading this post will come away with a better understanding of how Dockerfiles and image commits relate to each other.

Update - 2017/7/18:

I just recently discovered a legitimate use for image commits. We just set up a CI pipeline at our company and, during one stage of the pipeline, our app tests are run inside of a container. We need to retrieve the coverage results from the exited container after the test runner process has generated them (in the container's file system) and the container has stopped running. We use image commits to do this by committing the stopped container to create a new image and then running commands which display and dump the coverage file to stdout. So it's handy to have this. Apart from this very specific case, we use Dockerfiles to define our environments.

Answer 1

Dockerfiles are a tool that is used to create images.

The result of running docker build . is an image with a commit so it's not possible to use a Dockerfile with out creating a commit. The question is should you update the image by hand each time anything changes and thus doom yourself to the curse of the golden image?

The curse of the golden image is a terrible curse cast upon people who must continue living with a buggy security hole ridden base image to run their software on because the person who created it was long ago devoured by the ancient ones (or moved on to a new job) and nobody knows where they got the version of imagemagic that went into that image. and is the only thing that will link against the c++ module that was provided by that consultant the boss's son hired three years ago, and anyway it doesn't matter because even if you figured out where imagemagic came from the version of libstdc++ used by the JNI calls in the support tool that intern with the long hair created only exists in an unsupported version of ubuntu anyway.