What is the difference between a Docker image and

Question

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.

So the question is: What is a container?

Answer 1

Simply said, if an image is a class, then a container is an instance of a class is a runtime object.

Answer 2

From my article on Automating Docker Deployments:

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 miminal 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:

1. 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).
2. 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.
3. The value in the REPOSITORY column comes from the -t flag of the docker build command, or from docker 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 a docker push or docker pull.
4. The full form of a tag is [REGISTRYHOST/][USERNAME/]NAME[:TAG]. For ubuntu above, REGISTRYHOST is inferred to be registry.hub.docker.com. So if you plan on storing your image called my-application in a registry at docker.example.com, you should tag that image docker.example.com/my-application.
5. The TAG column is just the [:TAG] part of the full tag. This is unfortunate terminology.
6. The latest tag is not magical, it's simply the default tag when you don't specify a tag.
7. 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 info on images is available from the Docker docs 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:

1. 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.
2. docker ps only outputs running containers. You can view all containers (running or stopped) with docker ps -a.
3. 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 occassions 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:

1. Always remove a useless, stopped container with docker rm [CONTAINER_ID].
2. Always remove the image behind a useless, stopped container with docker rmi [IMAGE_ID].

Answer 3

Dockerfile > (Build) > Image > (Run) > Container.

• Dockerfile: contains a set of docker instructions that provisions your operating system the way you like, and installs/configure all your software's.

• Image: compiled Dockerfile. Saves you time from rebuilding the Dockerfile every time you need to run a container. And it's a way to hide your provision code.

• Container: the virtual operating system itself, you can ssh into it and run any commands you wish, as if it's a real environment. You can run 1000+ containers from the same Image.

Answer 4

A Docker image packs up the application and environment required by the application to run, and a container is a running instance of the image.

Images are the packing part of docker, analogous to "source code" or a "program". Containers are the execution part of docker, analogous to a "process".

In the question, only the "program" part is referred to and that's the image. The "running" part of docker is the container. When a container is run and changes are made, it's as if the process makes a change in it's own source code and saves it as the new image.

Answer 5

As many answers pointed this out: You build Dockerfile to get an image and you run image to get a container.

However, following steps helped me get a better feel for what Docker image and container are:

1) Build Dockerfile:

docker build -t my_image dir_with_dockerfile

2) Save the image to .tar file

docker save -o my_file.tar my_image_id

my_file.tar will store the image. Open it with tar -xvf my_file.tar, and you will get to see all the layers. If you dive deeper into each layer you can see what changes were added in each layer. (They should be pretty close to commands in the Dockerfile).

3) To take a look inside of a container, you can do:

sudo docker run -it my_image bash

and you can see that is very much like an OS.

Answer 6

Workflow

Here is the end-to-end workflow showing the various commands and their associated inputs and outputs. That should clarify the relationship between an image and a container.

+------------+  docker build   +--------------+  docker run -dt   +-----------+  docker exec -it   +------+
| Dockerfile | --------------> |    Image     | --------------->  | Container | -----------------> | Bash |
+------------+                 +--------------+                   +-----------+                    +------+
                                 ^
                                 | docker pull
                                 |
                               +--------------+
                               |   Registry   |
                               +--------------+

To list the images you could run, execute:

docker image ls

To list the containers you could execute commands on:

docker ps