I would like to fill the missing part here between docker images and containers. Docker uses a union file system (UFS) for containers, which allows multiple filesystems to be mounted in a hierarchy and to appear as a single filesystem. The filesystem from the image has been mounted as a read-only layer, and any changes to the running container are made to a read-write layer mounted on top of this. Because of this, Docker only has to look at the topmost read-write layer to find the changes made to the running system.

我想用以下类比来说明:

+-----------------------------+-------+-----------+
|             Domain          | Meta  | Concrete  |
+-----------------------------+-------+-----------+
| Docker                      | Image | Container |
| Object oriented programming | Class | Object    |
+-----------------------------+-------+-----------+

简而言之:

容器是内核中的一个分区(虚拟)，它共享一个公共操作系统并运行一个镜像(Docker镜像)。

容器是一个自我维持的应用程序，它将包含包和运行代码所需的所有依赖项。

图像之于类就像容器之于对象。

容器是图像的实例，就像对象是类的实例一样。

摘自我关于Docker部署自动化的文章(存档):

Docker Images vs. Containers

在Dockerland，有图像，也有容器。这两者密切相关，但又截然不同。对我来说，把握这种二分法极大地澄清了Docker。

什么是图像?

映像是惰性的、不可变的文件，本质上是容器的快照。映像是用build命令创建的，当使用run启动时，映像将生成一个容器。图像存储在Docker注册表中，例如registry.hub.docker.com。由于图像可以变得相当大，因此图像被设计成由其他图像的层组成，在通过网络传输图像时允许发送最少的数据。

本地映像可以通过运行docker映像列出:

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

需要注意的一些事情:

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

更多关于图像的信息可以从Docker文档和术语表中获得。

容器是什么?

用一个编程的比喻来说，如果一个图像是一个类，那么容器就是一个类的实例——一个运行时对象。容器是你使用Docker的原因;它们是运行应用程序的环境的轻量级和可移植封装。

使用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

这里我运行dockerized版本的docker注册表，这样我就有一个私有的地方来存储我的图像。这里有几点需要注意:

和IMAGE ID一样，CONTAINER ID是容器的真实标识符。它有相同的形式，但它识别了不同种类的物体。 Docker ps只输出正在运行的容器。你可以使用docker ps -a查看所有的容器(正在运行或已停止)。 NAMES可以通过——name标志来标识一个启动的容器。

如何避免图像和容器堆积

我早期使用Docker时遇到的一个挫折是，未标记的图像和停止的容器似乎不断堆积。在少数情况下，这种堆积导致硬盘驱动器过载，使我的笔记本电脑变慢或停止自动构建管道。谈论“无处不在的容器”!

我们可以通过结合docker rmi和最近的悬挂=true查询来删除所有未标记的图像:

docker images -q --filter "dangling=true" | xargs docker rmi

Docker将不能删除现有容器后面的图像，所以你可能必须先用Docker rm删除停止的容器:

docker rm `docker ps --no-trunc -aq`

这些都是Docker的已知痛点，可能会在未来的版本中得到解决。然而，通过对映像和容器的清晰理解，可以通过以下几个实践来避免这些情况:

总是使用docker rm [CONTAINER_ID]删除无用的、停止的容器。 总是使用docker rmi [IMAGE_ID]删除无用的、停止的容器后面的映像。

我认为最好一开始就解释清楚。

假设你运行命令docker run hello-world。会发生什么呢?

它调用Docker CLI，负责接收Docker命令并转换为调用Docker服务器命令。一旦Docker服务器得到一个运行映像的命令，它就会检查映像缓存中是否有这样一个名称的映像。

假设hello-world不存在。Docker服务器访问Docker Hub (Docker Hub只是一个免费的图像存储库)并询问，嘿，Hub，你有一个名为hello-world的图像吗? 枢纽响应-是的，我有。那就请给我吧。下载过程开始了。一旦Docker镜像下载完成，Docker服务器就会将其放入镜像缓存中。

所以在我们解释Docker镜像和Docker容器是什么之前，让我们先来介绍一下你电脑上的操作系统以及它是如何运行软件的。

例如，当你在电脑上运行Chrome时，它会调用操作系统，操作系统自己会调用内核并请求，嘿，我想运行这个程序。内核设法从您的硬盘运行文件。

现在假设你有两个程序，Chrome和Node.js。Chrome需要Python版本2才能运行，Node.js需要Python版本3才能运行。如果您的计算机上只安装了Python v2，则只能运行Chrome。

为了使这两种情况都能工作，您需要以某种方式使用称为名称空间的操作系统特性。命名空间是一种特性，它使您有机会隔离进程、硬盘驱动器、网络、用户、主机名等。

当我们讨论映像时，我们实际上是在讨论文件系统快照。映像是一个物理文件，其中包含构建特定容器的方向和元数据。容器本身是一个映像的实例;它使用名称空间隔离硬盘驱动器，该名称空间仅对该容器可用。因此容器是一个进程或一组进程，它将分配给它的不同资源分组。