What is the difference between a Docker image and a container?
Solution 1
An instance of an image is called a container. You have an image, which is a set of layers as you describe. If you start this image, you have a running container of this image. You can have many running containers of the same image.
You can see all your images with docker images
whereas you can see your running containers with docker ps
(and you can see all containers with docker ps -a
).
So a running instance of an image is a container.
Solution 2
From my article on Automating Docker Deployments (archived):
Docker Images vs. Containers
In Dockerland, there are images and there are containers. The two are closely related, but distinct. For me, grasping this dichotomy has clarified Docker immensely.
What's an Image?
An image is an inert, immutable, file that's essentially a snapshot of a container. Images are created with the build command, and they'll produce a container when started with run. Images are stored in a Docker registry such as registry.hub.docker.com. Because they can become quite large, images are designed to be composed of layers of other images, allowing a minimal amount of data to be sent when transferring images over the network.
Local images can be listed by running docker images
:
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
ubuntu 13.10 5e019ab7bf6d 2 months ago 180 MB
ubuntu 14.04 99ec81b80c55 2 months ago 266 MB
ubuntu latest 99ec81b80c55 2 months ago 266 MB
ubuntu trusty 99ec81b80c55 2 months ago 266 MB
<none> <none> 4ab0d9120985 3 months ago 486.5 MB
Some things to note:
- IMAGE ID is the first 12 characters of the true identifier for an image. You can create many tags of a given image, but their IDs will all be the same (as above).
- VIRTUAL SIZE is virtual because it's adding up the sizes of all the distinct underlying layers. This means that the sum of all the values in that column is probably much larger than the disk space used by all of those images.
- The value in the REPOSITORY column comes from the
-t
flag of thedocker build
command, or fromdocker tag
-ing an existing image. You're free to tag images using a nomenclature that makes sense to you, but know that docker will use the tag as the registry location in adocker push
ordocker pull
. - The full form of a tag is
[REGISTRYHOST/][USERNAME/]NAME[:TAG]
. Forubuntu
above, REGISTRYHOST is inferred to beregistry.hub.docker.com
. So if you plan on storing your image calledmy-application
in a registry atdocker.example.com
, you should tag that imagedocker.example.com/my-application
. - The TAG column is just the [:TAG] part of the full tag. This is unfortunate terminology.
- The
latest
tag is not magical, it's simply the default tag when you don't specify a tag. - You can have untagged images only identifiable by their IMAGE IDs. These will get the
<none>
TAG and REPOSITORY. It's easy to forget about them.
More information on images is available from the Docker documentation and glossary.
What's a container?
To use a programming metaphor, if an image is a class, then a container is an instance of a class—a runtime object. Containers are hopefully why you're using Docker; they're lightweight and portable encapsulations of an environment in which to run applications.
View local running containers with docker ps
:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
f2ff1af05450 samalba/docker-registry:latest /bin/sh -c 'exec doc 4 months ago Up 12 weeks 0.0.0.0:5000->5000/tcp docker-registry
Here I'm running a dockerized version of the docker registry, so that I have a private place to store my images. Again, some things to note:
- Like IMAGE ID, CONTAINER ID is the true identifier for the container. It has the same form, but it identifies a different kind of object.
-
docker ps
only outputs running containers. You can view all containers (running or stopped) withdocker ps -a
. - NAMES can be used to identify a started container via the
--name
flag.
How to avoid image and container buildup
One of my early frustrations with Docker was the seemingly constant buildup of untagged images and stopped containers. On a handful of occasions this buildup resulted in maxed out hard drives slowing down my laptop or halting my automated build pipeline. Talk about "containers everywhere"!
We can remove all untagged images by combining docker rmi
with the recent dangling=true
query:
docker images -q --filter "dangling=true" | xargs docker rmi
Docker won't be able to remove images that are behind existing containers, so you may have to remove stopped containers with docker rm
first:
docker rm `docker ps --no-trunc -aq`
These are known pain points with Docker and may be addressed in future releases. However, with a clear understanding of images and containers, these situations can be avoided with a couple of practices:
- Always remove a useless, stopped container with
docker rm [CONTAINER_ID]
. - Always remove the image behind a useless, stopped container with
docker rmi [IMAGE_ID]
.
Solution 3
In easy words.
Images -
The file system and configuration(read-only) application which is used to create containers. More detail.
Containers -
The major difference between a container and an image is the top writable layer. Containers are running instances of Docker images with top writable layer. Containers run the actual applications. A container includes an application and all of its dependencies. When the container is deleted, the writable layer is also deleted. The underlying image remains unchanged. More detail.
Other important terms to notice:
Docker daemon -
The background service running on the host that manages the building, running and distributing Docker containers.
Docker client -
The command line tool that allows the user to interact with the Docker daemon.
Docker Store -
Store is, among other things, a registry of Docker images. You can think of the registry as a directory of all available Docker images.
A picture from this blog post is worth a thousand words.
(For deeper understanding please read this.)
Summary:
- Pull image from Docker hub or build from a Dockerfile => Gives a Docker image (not editable).
- Run the image (
docker run image_name:tag_name
) => Gives a running Image i.e. container (editable)
Solution 4
While it's simplest to think of a container as a running image, this isn't quite accurate.
An image is really a template that can be turned into a container. To turn an image into a container, the Docker engine takes the image, adds a read-write filesystem on top and initialises various settings including network ports, container name, ID and resource limits. A running container has a currently executing process, but a container can also be stopped (or exited in Docker's terminology). An exited container is not the same as an image, as it can be restarted and will retain its settings and any filesystem changes.
Solution 5
Maybe explaining the whole workflow can help.
Everything starts with the Dockerfile. The Dockerfile is the source code of the image.
Once the Dockerfile is created, you build it to create the image of the container. The image is just the "compiled version" of the "source code" which is the Dockerfile.
Once you have the image of the container, you should redistribute it using the registry. The registry is like a Git repository -- you can push and pull images.
Next, you can use the image to run containers. A running container is very similar, in many aspects, to a virtual machine (but without the hypervisor).
Bibek Shrestha
Updated on July 16, 2022Comments
-
Bibek Shrestha almost 2 years
When using Docker, we start with a base image. We boot it up, create changes and those changes are saved in layers forming another image.
So eventually I have an image for my PostgreSQL instance and an image for my web application, changes to which keep on being persisted.
What is a container?
-
user3192295 about 2 yearsas of 2022 where docker is almost "dead" , question and answers should be brought into a more generalized form to comply to OCI spec/definitions of images and containers.
-
-
Gibbs over 9 yearsGood Differentiation bte images and container. Helps a lot for the beginners like me.
-
Kenny Worden over 9 yearsI guess what I'm stuck on is how images run (I use boot2docker on Windows). Why do we create images for applications, say mysql? At this point, how is mysql even running? Don't I need to have a Linux image to run mysql on top of?
-
Janus Troelsen about 9 yearshow do I turn an image into a container without running it?
-
Adrian Mouat about 9 years@JanusTroelsen Use
docker create
. -
Adrian Mouat about 9 yearsActually this isn't true: "docker pull-ing the :latest tag of an image will add at least two images to your local image list: one with the latest tag, and one for each original tag of the latest image, e.g. 14.04 and trysty above." It will only add one image with the latest tag. Pulling 14.04 later may be a no-op if the image ID is the same, but it still requires a separate pull.
-
Adrian Mouat about 9 yearsThis isn't true either: "The latest tag will always refer to the newest version of an image when specified in a docker pull.". The latest tag just refers to whatever was pushed with the tag latest. The wrinkle is that
latest
is used as the default tag if no tag is specified. -
Forage almost 8 yearsThank you for the clarifying summary. The only thing missing, in my opinion, is an explanation about when/how containers are being created or reused. With just two images I managed to end up with a long list of containers, yet a new container is not created every time I use docker again after stopping.
-
Victor Dombrovsky almost 7 yearsSo, what is difference between an image and a stopped container?
-
Julien over 6 yearsthe image is the recipe, the container is the cake ;-) you can make as many cakes as you like with a given recipe
-
Sridhar Sarnobat over 6 yearsFor a more comprehensive workflow diagram, see this: stackoverflow.com/a/46528745/714112
-
user1842947 about 6 yearsThanks for this comment, it confirmes the difference between size and virtual size and it's very interresting for multiple containers that they share the same read-only data and it's a gain os disk space.
-
lin about 6 yearssomething like program and process ?
-
Dchucks about 6 yearsThis is bit confusing. We say images are immutable, but when being run as a container it stores any changes to the mutable top layer as you said. But when stopped, are these changes then saved as this new layer in the image? If yes, then how was it possible as the original image was supposed to be immutable?
-
Dchucks about 6 yearsOK, did some reading and got the answer in this thread itself. "When the container is deleted, the writable layer is also deleted. The underlying image remains unchanged."
-
Dinesh Sonachalam about 6 yearsIt is similar to class-object relationship in oops. Where the image is a blueprint of a house, and all the houses built from the blueprint(images) is called containers.
-
Jacob Ford about 6 years@VictorDombrovsky A stopped container is a cake in the freezer.
-
coder.in.me about 6 yearsrecipe-cake, class-object: does it mean that each container has a copy of the image's layers? If image has Ubuntu 14.04 + MongoDB, will there copies of these in each container? Looks like VM to me. Confused.
-
Johnny Willer about 6 years@Julien if the image is the recipe, what about the Dockerfile? :)
-
Julien about 6 years@JohnnyWiller Analogies have their limits, but maybe we can see the Dockerfile is your shopping list for ingredients ;-). Otherwise call the Dockerfile the recipe, the image the mould, the container still being the yummy cake
-
Dario Seidl almost 6 yearsIn newer versions of docker, you can use
docker image prune
to cleanup dangling images. Prune unused Docker objects -
Peter Mortensen almost 6 yearsBut the required scrolling in that ASCII art is a problem.
-
Peter Mortensen almost 6 yearsUnicode could be used instead to get nicer-looking boxes. An online tool is Javascript Box Drawing Demo.
-
vadipp over 5 years@coder.in.me no, there will not be copies of the image files, instead, only changed files will be stored. A copy-on-write filesystem is used, afaik.
-
ejlp12 about 5 yearsDockerfile is like source code. Image is like executable file after the source code compiled/built. A container is like an application that running from the executable file.
-
Rami Alloush over 4 yearsI just use
docker system prune
to clean EVERYTHING -
James Allen over 4 yearsVery helpful reply. I was confused before. If I DL an image, run it as a container, put a random text file in that container, and stop the container, the text file is in the stopped container but NOT the base image I downloaded.
-
Giora Guttsait over 4 yearsFor me, the terminology to understand and explain the relation between images and containers is that images are templates, and containers are instantiations of these templates.
-
Rich Lysakowski PhD about 4 yearsThis answer has it backward. A container is an instance of an image, or a executable snapshot of an image. The image is not executed directly since it the parent class of the instance. The instance (container) is a child of the parent (recipe or template for making instances.)
-
Rich Lysakowski PhD about 4 yearsImage is NOT the source code for a container. The dockerfile is the metaclass or specification for the class. The image is a class or template for the container, and the container is the instance of the class. The container is an instance that runs. You can have a 1000 instances of a class. An image is like compiled object code that can be linked into another program and run as part of that program.
-
Rich Lysakowski PhD about 4 yearsExcellent analogy. If I could give you 1000 thumbs up I would.
-
Rich Lysakowski PhD about 4 yearsThis answer starts off at the end of the process. A new image CAN be made as a snapshot of a container, but all containers had to have a parent image. In this case here is no chicken and egg problem, because a first primordial image must first be built from a Dockerfile. First came the Dockerfile, then the Image, then the Container. A container can be used as the foundation for a new image, but that container had to have a "parent image".
-
xjcl about 4 yearsI like @x-yuri's analogy. The Dockerfile is source code, the image is an executable and the container is a process
-
tothemario almost 4 yearsThanks! I edited the answer a little bit to make it clear the point of view for this reasoning, and that containers are always instantiated from images (and not the other way around)
-
OrangePot over 3 yearsWhy does GCP call it GCR (container registry) then? By this logic it should be Image Registry.
-
Dragos Alexe over 3 yearsIn fact, docker images command is used to list the locally available repositories. So these repositories can be thought of as container images, but it’s important to realize that these repositories are actually made up of layers-iamge layer and include metadata about in a file referred to as the manifest (manifest.json). See this link also: developers.redhat.com/blog/2018/02/22/…
-
mzjn about 3 yearsThe same answer as stackoverflow.com/a/63048251/407651, stackoverflow.com/a/46073260/407651
-
Clearer about 3 yearsA container is not an exectuable binary.
-
Juanma Menendez over 2 yearsExcellent explanation thanks!
-
Rustem Mustafin over 2 yearsI'd say docker image is a blueprint of the engine (e.g. car engine). When you create container = new engine is built. When you run it = you start the engine. You can turn it off later. You can destroy it.