4

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?

YulePale
  • 6,688
  • 16
  • 46
  • 95
  • An image may contains several layers, which you can customize. This is not possible with containers. – Mohammad Nov 14 '19 at 13:30
  • 1
    But I can also customise my Dockerfile? – YulePale Nov 14 '19 at 13:34
  • 1
    Possible duplicate of [What is the difference between a Docker image and a container?](https://stackoverflow.com/questions/23735149/what-is-the-difference-between-a-docker-image-and-a-container) – k0pernikus Nov 14 '19 at 13:38
  • If there were no images, anytime you will need to run a container you should re-build dockerfile. Think of it, you will conclude that you need something to persist what is defined in the dockerfile. And that something is called docker image. – leopal Nov 14 '19 at 13:45

3 Answers3

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

k0pernikus
  • 60,309
  • 67
  • 216
  • 347
  • What is a virtual file system? I have checked it online but the definitions are hard to understand for me. – YulePale Nov 14 '19 at 13:49
  • Does a virtual file system litrally mean a file system(like [described here](https://www.youtube.com/watch?v=mzUyMy7Ihk0)) that is virtual? – YulePale Nov 14 '19 at 13:55
  • So one of the purpose of an image is to save expensive tasks from your server by saving it to have to build an image everytime? – YulePale Nov 14 '19 at 13:59
  • @YulePale I am not following by your "build everytime" remark. It depends on your use case. There are images for some tool-images that remain stable for years, others you have to rebuild for each deployment. The workflow with docker is: Build images, publish them in a (private or public) registry, depend on those images in other images and/or spin them up as containers in the cloud and/or run them locally for development. – k0pernikus Nov 14 '19 at 14:14
  • 1
    So if creating an image is not expensive we can directly use dockerfile to create container instead of creating, pushing and then pulling image? The benefit is: we do not need to use a docker registry. While writing this comment I came to the conclusion it would be like to compile application from source codes every time we need to use it instead of using ready exe file. It would be overkill. – raV720 Dec 28 '21 at 08:59
1

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.

Orabîg
  • 11,718
  • 6
  • 38
  • 58
  • 1
    Thank you. But my confusion is why do I need images. Why not create containers straight from Dockerfiles? – YulePale Nov 14 '19 at 13:36
  • 2
    Think about the container as a process. To be able to run this process, you need **first** to make up an environment for it (full filesystem, environment variables, user...). That's where the image is needed. – Orabîg Nov 14 '19 at 13:41
1

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, e.g. 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.

BMitch
  • 231,797
  • 42
  • 475
  • 450