Source From HereIntroduction
This post is meant as a Docker 102-level post. If you are unaware of what Docker is, or don't know how it compares to virtual machines or to configuration management tools, then this post might be a bit too advanced at this time. This post hopes to aid those struggling to internalize the docker command-line, specifically with knowing the exact difference between a container and an image. More specifically, this post shall differentiate a simple container from arunning container.
I do this by taking a look at some of the underlying details, namely the layers of the union file system. This was a process I undertook for myself in the past few weeks, as I am relatively new to the docker technology and have found the docker command-lines difficult to internalize.
The first visual I present is that of an image, shown below with two different visuals. It is defined as the "union view" of a stack of read-only layers.
On the left we see a stack of read-layers. These layers are internal implementation details only, and are accessible outside of running containers in the host's file system. Importantly, they are read-only (or immutable) but capture the changes (deltas) made to the layers below. Each layer may have one parent, which itself may have a parent, etc. The top-level layer may be read by a union-ing file system (AUFS on my docker implementation) to present a single cohesive view of all the changes as one read-only file system. We see this "union view" on the right.
If you want to see these layers in their glory, you might find them in different locations on your host's files system. These layers will not be viewable from within a running container directly. In my docker's host system I can see them at /var/lib/docker in a subdirectory called aufs.
A container is defined as a "union view" of a stack of layers the top of which is a read-write layer.
I show this visual above, and you will note it is nearly the same thing as an image, except that the top layer is read-write. At this point, some of you might notice that this definition says nothing about whether this container is running, and this is on purpose. It was this discovery in particular that cleared up a lot of confusion I had up to this point.
Running Container Definition
A running container is defined as a read-write "union view" and the the isolated process-space and processes within. The below visual shows the read-write container surrounded by this process-space.
It is this act of isolation atop the file system effected by kernel-level technologies like cgroups, namespaces, etc that have made docker such a promising technology. The processes within this process-space may change, delete or create files within the "union view" file that will be captured in the read-write layer. I show this in the visual below:
To see this at work run the following command: docker run ubuntu touch happiness.txt. You will then be able to see the new file in the read-write layer of the host system, even though there is no longer a running container (note, run this in your host system, not a container):
Finally, to tie up some loose ends, we should define an image layer. The below image shows an image layer and makes us realize that a layer is not just the changes to the file system.
The metadata is additional information about the layer that allows docker to capture runtime and build-time information, but also hierarchical information on a layer's parent. Both read and read-write layers contain this metadata.
Additionally, as we have mentioned before, each layer contains a pointer to a parent layer using the Id (here, the parent layers are below). If a layer does not point to a parent layer, then it is at the bottom of the stack.
Now, let's look at the commands in the light of these visual metaphors and implementation details.
The 'docker create' command adds a read-write layer to the top stack based on the image id. It does not run this container.
The command 'docker start' creates a process space around the union view of the container's layers. There can only be one process space per container.
One of the first questions people ask (myself included) is "What is the difference between 'docker start' and 'docker run'. You might argue that the entire point of this post is to explain the subtleties in this distinction.
As we can see, the docker run command starts with an image, creates a container, and starts the container (turning it into a running container). It is very much a convenience, and hides the details of two commands.
The command 'docker ps -a' where the 'a' is short for 'all' lists out all the containers on your system, whether stopped or running.
The 'docker images' command lists out the inventor of top-level images on your system. Effectively there is nothing to distinguish an image from a read-only layer. Only those images that have containers attached to them or that have been pulled are considered top-level. This distinction is for convenience as there are may be many hidden layers beneath each top-level read-only layer.
This command 'docker images -a' shows all the images on your system. This is exactly the same as showing all the read-only layers on the system. If you want to see the layers below one image-id, you should use the 'docker history' command discussed below.
The command 'docker stop' issues a SIGTERM to a running container which politely stops all the processes in that process-space. What results is a normal, but non-running, container.
The command 'docker kill' issues a non-polite SIGKILL command to all the processes in a running container.
Unlike 'docker stop' and 'docker kill' which send actual UNIX signals to a running process, the command 'docker pause' uses a special cgroups feature to freeze/pause a running process-space. The rationale can be found here:https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt, but the short of it is that sending a Control-Z (SIGTSTP) is not transparent enough to the processes within the process-space to truly allow all of them to be frozen.
The command 'docker rm' removes the read-write layer that defines a container from your host system. It must be run on stopped containers. It effectively deletes files.
The command 'docker rmi' removes the read-layer that defines a "union view" of an image. It removes this image from your host, though the image may still be found from the repository from which you issued a 'docker pull'. You can only use 'docker rmi' on top-level layers (or images), and not on intermediate read-only layers (unless you use -f for 'force').
The command 'docker commit' takes a container's top-level read-write layer and burns it into a read-only layer. This effectively turns a container (whether running or stopped) into an immutable image.
The 'docker build' command is an interesting one as it iteratively runs multiple commands at once.
The 'docker exec' command runs on a running container and executes a process in that running container's process space.
The command 'docker inspect' fetches the metadata that has been associated with the top-layer of the container or image.
The command 'docker save' creates a single tar file that can be used to import on a different host system. Unlike the 'export' command, it saves the individual layers with all their metadata. This command can only be run on an image.
The 'docker export' command creates a tar file of the contents of the "union view" and flattens it for consumption for non-Docker usages. This command removes the metadata and the layers. This command can only be run on containers.
The 'docker history' command takes an image-id and recursively prints out the read-only layers (which are themselves images) that are ancestors of the input image-id.
I hope you enjoyed this visualization of containers and images. There are many other commands (pull, search, restart, attach, etc) which may or may not relate to these metaphors. I believe though that the great majority of docker's primary commands can be easier understood with this effort. I am only two weeks into learning docker, so if I missed a point or something can be better explained,