这篇文章但愿可以帮助读者深刻理解 Docker 的命令,还有容器(container)和镜像(image)之间的区别,并深刻探讨容器和运行中的容器之间的区别。git
当我对 Docker 技术仍是只知其一;不知其二的时候,我发现理解 Docker 的命令很是困难。因而,我花了几周的时间来学习 Docker 的工做原理,更确切地说,是关于 Docker 统一文件系统(the union file system)的知识,而后回过头来再看 Docker 的命令,一切变得瓜熟蒂落,简单极了。docker
题外话:就我我的而言,掌握一门技术并合理使用它的最好办法就是深刻理解这项技术背后的工做原理。一般状况下,一项新技术的诞生经常会伴随着媒体的大肆宣传和炒做,这使得用户很难看清技术的本质。更确切地说,新技术老是会发明一些新的术语或者隐喻词来帮助宣传,这在初期是很是有帮助的,可是这给技术的原理蒙上了一层砂纸,不利于用户在后期掌握技术的真谛。json
Git 就是一个很好的例子。我以前不可以很好的使用 Git,因而我花了一段时间去学习 Git 的原理,直到这时,我才真正明白了 Git 的用法。我坚信只有真正理解 Git 内部原理的人才可以掌握这个工具。ubuntu
镜像(Image)就是一堆只读层(read-only layer)的统一视角,也许这个定义有些难以理解,下面的这张图可以帮助读者理解镜像的定义。网络
从左边咱们看到了多个只读层,它们重叠在一块儿。除了最下面一层,其它层都会有一个指针指向下一层。这些层是 Docker 内部的实现细节,而且可以在主机(译者注:运行 Docker 的机器)的文件系统上访问到。统一文件系统(union file system)技术可以将不一样的层整合成一个文件系统,为这些层提供了一个统一的视角,这样就隐藏了多层的存在,在用户的角度看来,只存在一个文件系统。咱们能够在图片的右边看到这个视角的形式。app
你能够在你的主机文件系统上找到有关这些层的文件。须要注意的是,在一个运行中的容器内部,这些层是不可见的。在个人主机上,我发现它们存在于 /var/lib/docker/aufs 目录下。工具
sudo tree -L 1 /var/lib/docker/ /var/lib/docker/ ├── aufs ├── containers ├── graph ├── init ├── linkgraph.db ├── repositories-aufs ├── tmp ├── trust └── volumes 7 directories, 2 files
容器(container)的定义和镜像(image)几乎如出一辙,也是一堆层的统一视角,惟一区别在于容器的最上面那一层是可读可写的。学习
细心的读者可能会发现,容器的定义并无说起容器是否在运行,没错,这是故意的。正是这个发现帮助我理解了不少困惑。fetch
要点:容器 = 镜像 + 可读层。而且容器的定义并无说起是否要运行容器。ui
接下来,咱们将会讨论运行态容器。
一个运行态容器(running container)被定义为一个可读写的统一文件系统加上隔离的进程空间和包含其中的进程。下面这张图片展现了一个运行中的容器。
正是文件系统隔离技术使得 Docker 成为了一个前途无量的技术。一个容器中的进程可能会对文件进行修改、删除、建立,这些改变都将做用于可读写层(read-write layer)。下面这张图展现了这个行为。
咱们能够经过运行如下命令来验证咱们上面所说的:
docker run ubuntu touch happiness.txt
即使是这个 ubuntu 容器再也不运行,咱们依旧可以在主机的文件系统上找到这个新文件。
find / -name happiness.txt /var/lib/docker/aufs/diff/860a7b...889/happiness.txt
为了将零星的数据整合起来,咱们提出了镜像层(image layer)这个概念。下面的这张图描述了一个镜像层,经过图片咱们可以发现一个层并不只仅包含文件系统的改变,它还能包含了其余重要信息。
元数据(metadata)就是关于这个层的额外信息,它不只可以让 Docker 获取运行和构建时的信息,还包括父层的层次信息。须要注意,只读层和读写层都包含元数据。
除此以外,每一层都包括了一个指向父层的指针。若是一个层没有这个指针,说明它处于最底层。
Metadata Location:
我发如今我本身的主机上,镜像层(image layer)的元数据被保存在名为 "json" 的文件中,好比说:
/var/lib/docker/graph/e809f156dc985.../json
e809f156dc985… 就是这层的 id
一个容器的元数据好像是被分红了不少文件,但或多或少可以在 /var/lib/docker/containers/<id> 目录下找到,<id> 就是一个可读层的 id。这个目录下的文件大可能是运行时的数据,好比说网络,日志等等。
如今,让咱们结合上面提到的实现细节来理解 Docker 的命令。
docker create 命令为指定的镜像(image)添加了一个可读层,构成了一个新的容器。注意,这个容器并无运行。
Docker start 命令为容器文件系统建立了一个进程隔离空间。注意,每个容器只可以有一个进程隔离空间。
看到这个命令,读者一般会有一个疑问:docker start 和 docker run 命令有什么区别?
从图片能够看出,docker run 命令先是利用镜像建立了一个容器,而后运行这个容器。这个命令很是的方便,而且隐藏了两个命令的细节,但从另外一方面来看,这容易让用户产生误解。
题外话:继续咱们以前有关于 Git 的话题,我认为 docker run 命令相似于 git pull 命令。git pull 命令就是 git fetch 和 git merge 两个命令的组合,一样的,docker run 就是 docker create 和 docker start 两个命令的组合。
docker ps 命令会列出全部运行中的容器。这隐藏了非运行态容器的存在,若是想要找出这些容器,咱们须要使用下面这个命令。
docker ps –a 命令会列出全部的容器,不论是运行的,仍是中止的。
docker images 命令会列出了全部顶层(top-level)镜像。实际上,在这里咱们没有办法区分一个镜像和一个只读层,因此咱们提出了 top-level 镜像。只有建立容器时使用的镜像或者是直接 pull 下来的镜像能被称为顶层(top-level)镜像,而且每个顶层镜像下面都隐藏了多个镜像层。
docker images –a 命令列出了全部的镜像,也能够说是列出了全部的可读层。若是你想要查看某一个 image-id 下的全部层,可使用 docker history 来查看。
docker stop 命令会向运行中的容器发送一个 SIGTERM 的信号,而后中止全部的进程。
docker kill 命令向全部运行在容器中的进程发送了一个不友好的 SIGKILL 信号。
docker stop 和 docker kill 命令会发送 UNIX 的信号给运行中的进程,docker pause 命令则不同,它利用了 cgroups 的特性将运行中的进程空间暂停。具体的内部原理你能够在这里找到:https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt,可是这种方式的不足之处在于发送一个 SIGTSTP 信号对于进程来讲不够简单易懂,以致于不可以让全部进程暂停。
docker rm 命令会移除构成容器的可读写层。注意,这个命令只能对非运行态容器执行。
docker rmi 命令会移除构成镜像的一个只读层。你只可以使用 docker rmi 来移除最顶层(top level layer)(也能够说是镜像),你也可使用 -f 参数来强制删除中间的只读层。
docker commit 命令将容器的可读写层转换为一个只读层,这样就把一个容器转换成了不可变的镜像。
docker build 命令很是有趣,它会反复的执行多个命令。
咱们从上图能够看到,build 命令根据 Dockerfile 文件中的 FROM 指令获取到镜像,而后重复地1)run(create和start)、2)修改、3)commit。在循环中的每一步都会生成一个新的层,所以许多新的层会被建立。
docker exec 命令会在运行中的容器执行一个新进程。
docker inspect 命令会提取出容器或者镜像最顶层的元数据。
docker save 命令会建立一个镜像的压缩文件,这个文件可以在另一个主机的 Docker上使用。和 export 命令不一样,这个命令为每个层都保存了它们的元数据。这个命令只能对镜像生效。
docker export 命令建立一个tar文件,而且移除了元数据和没必要要的层,将多个层整合成了一个层,只保存了当前统一视角看到的内容(译者注:expoxt 后的容器再 import 到 Docker 中,经过 docker images –tree 命令只能看到一个镜像;而 save 后的镜像则不一样,它可以看到这个镜像的历史镜像)。
docker history 命令递归地输出指定镜像的历史镜像。