Why does docker have to create an image from a dockerfile then create a container from the image instead of creating a container from a Dockerfile?

Question

Why does docker have to create an image from a dockerfile then create a container from the image instead of creating a container directly from a Dockerfile?

What is the purpose/benefit of creating the image first from the Dockerfile then from that create a container?

-----EDIT-----

This question What is the difference between a Docker image and a container? Does not answer my question.

My question is: Why do we need to create a container from an image and not a dockerfile? What is the purpose/benefit of creating the image first from the Dockerfile then from that create a container?

Answer 1

• the Dockerfile is the recipe to create an image
• the image is a virtual filesystem
• the container is the a running process on a host machine

You don't want every host to build its own image based on the recipe. It's easier for some hosts to just download an image and work with that.

Creating an image can be very expensive. I have complicated Dockerfiles that may take hours to build, may download 50 GB of data, yet still only create a 200 MB image that I can send to different hosts.

Spinning up a container from an existing image is very cheap.

If all you had was the Dockerfile in order to spin up image-containers, the entire workflow would become very cumbersome.

Answer 2

Images and Containers are two different concepts.

Basically, images are like a snapshot of a filesystem, along with some meta-data.

A container is one of several process that are actually running (and which is based on an image). As soon as the processes end, your container do not exist anymore (well, it is stopped to be exact)

You can view the image as the base that you will make your container run on.

Thus, you Dockerfile will create an image (which is static) which you can store locally or push on a repository, to be able to use it later.

The container cannot be "stored" because it is a "living" thing.

Answer 3

You can think of Images vs Containers similar to Classes vs Objects or the Definition vs Instance. The image contains the filesystem and default settings for creating the container. The container contains the settings for a specific instance, and when running, the namespaces and running process.

As for why you'd want to separate them, efficiency and portability. Since we have separate images, we also have inheritance, where one image extends another. The key detail of that inheritance is that filesystem layers in the image are not copied for each image. Those layers are static, and you can them by creating a new image with new layers. Using the overlay filesystem (or one of the other union filesystem drivers) we can append additional changes to that filesystem with our new image. Containers do the same when the run the image. That means you can have a 1 Gig base image, extend it with a child image with 100 Megs of changes, and run 5 containers that each write 1 Meg of files, and the overall disk space used on the docker host is only 1.105 Gigs rather than 7.6 Gigs.

The portability part comes into play when you use registries, eg Docker Hub. The image is the part of the container that is generic, reusable, and transferable. It's not associated with an instance on any host. So you can push and pull images, but containers are tightly bound to the host they are running on, named volumes on that host, networks defined on that host, etc.