Docker Image vs Container: Closely Related, But Distinct. What's The Difference?

Welcome to... Dockerland, a place of never-ending confusions! The most frustrating one of them all — for every novice planning to explore Docker — being the “Docker Image vs Container” dilemma.

“What, aren't they one and the same concept?”

But you know that this is a rhetorical question: you just sense that they're 2 distinct concepts...

Yet, you can't really identify the differences:

How are Docker containers and images different after all?

Now let's clear up the Docker Image vs Container confusion once and for all:

First Things First: What's a Docker Image?

A file (or file-like... thing) that gets built from a Dockerfile, by running a "build" command. 

Moreover — and this is particularly important in defining a Docker image and setting it apart from containers — it's an inert, immutable type of file. A template-like file (you could also imagine it as a snapshot of a container).

It's only when started, with the docker command, that a docker image starts producing a container.

And since images in Docker tend to grow quite large, they're built on a layered structure (multiple players of other images). This way, only a small “load” of data gets sent when loading images over the network.

Wrapping Up:
 

1. you can take the docker image as an application that you'd like to run
2. a docker image can't be “running” or be “started”; once the “docker run” command is... run (obviously!), the image grows into a docker container, so... mind the inevitable confusion
    

Which Leads Us to The Question: “What's a Docker Container Then?”

The not 100% accurate, yet generally accepted (even if halfheartedly) definition is: 

“A container is a running instance of an image”

Now, let me detail...

Practically, the very act of running a Docker image produces a Docker container. You won't find a more straightforward explanation than this one!

And containers are (or they should be) the very reason why “learning Docker” turned into one of your top resolutions for 2018 in the first place. For they're:
 

• lightweight
• using fewer resources
• portable
• easy-to-be-deployed
   

… ways of running and managing your applications.

If you're fond of analogies, here's one that will undoubtedly help you come up with a clear answer to your “Docker container vs image” dilemma:

If a Docker image was a class, then a Docker container would be an instance of a class (a runtime object). 

Wrapping up now:
 

1. once you start an image in Docker (so once you use the “docker run” command) you basically have a running container of this image in question
    
2. a container is created by adding a top writable layer to a Docker image and thus by initializing multiple settings (container name, ID, network ports etc.)
    
3. and it's due to that very writable layer, storing all the changes applied, that you can have multiple containers running off the same image; each and every one of them preserving its own distinct data state
    

Docker Image vs Container: Key Difference Revealed

The most significant difference clearing up the confusion is the following:

There is a top writable layer setting Docker images and Docker containers apart

It's that very layer, storing all write operation corresponding to the containers in question, which:
 

1. gets deleted along once/if the container, itself, gets deleted, while the underlying image remains intact
    
2. enables multiple containers to share the very same underlying image
    

Now to better explain the key differences founding this dichotomy, let's reduce everything to a simple, clear-enough (hopefully) formula:

a docker image + a docker run command = a docker container (meaning a running instance of the docker image)

… a container equipped with its own writable layer and which can get listed via a "docker ps" command

Is everything any clearer and simpler to you now?
 

Or Maybe a Metaphor Example Suits You Best?

In addition to my “class vs instance of a class” analogy, let me try now explaining this tricky Docker dichotomy by using a metaphor... or two:
 

1. Let's say you have a film and a VHS of (which stands for our “image” in Docker). Then, imagine you'd place that VHS into your “virtual” VCR. In this case, the VCR stands for your Docker container. Better?
    
2. Or you could see the Docker image as an executable file on a disk (an app's file); once you run your application, it promptly creates an instance running in its memory. Now that very instance is our metaphorical Docker container.
    

Have I managed to clear up your confusion or just... deepen it instead?
 

Docker Image vs Dockerfile: How Do You Set Them Apart in “Dockerland”?

Now, let me rewind to the stage where we can't even be talking about containers (not just yet). Where not even Docker images are yet built: the Dockerfile stage.

You can take a Dockerfile as a... recipe for creating Docker images.

And here's how the “cooking of an image” takes place:
 

1. a Docker command is run in that Dockerfile
2. and so an image gets built
    

Clear as daylight: a Dockerfile is a... file that you create which, in return, creates a Docker image when you run a separate build command.
 

The END! Do be honest now: have I managed to clear up your “Docker Image vs Container” confusion?

If so, then “solving the puzzle” around this dichotomy will make a huge jump start on your Docker learning plan for 2018. Happy learning!