白话容器基础（四）：重新认识Docker容器

这一次，我要用 Docker 部署一个用 Python 编写的 Web 应用。

这个应用的代码部分（app.py）非常简单：

from flask import Flask
import socket
import os

app = Flask(__name__)

@app.route('/')
def hello():
    html = "<h3>Hello {name}!</h3>" \
           "<b>Hostname:</b> {hostname}<br/>"           
    return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname())
    
if __name__ == "__main__":
    app.run(host='0.0.0.0', port=80)

而将这样一个应用容器化的第一步，是制作容器镜像。
不过，相较于之前介绍的制作 rootfs 的过程，Docker 为你提供了一种更便捷的方式，叫作 Dockerfile，如下所示。

# 使用官方提供的Python开发镜像作为基础镜像
FROM python:2.7-slim

# 将工作目录切换为/app
WORKDIR /app

# 将当前目录下的所有内容复制到/app下
ADD . /app

# 使用pip命令安装这个应用所需要的依赖
RUN pip install --trusted-host pypi.python.org -r requirements.txt

# 允许外界访问容器的80端口
EXPOSE 80

# 设置环境变量
ENV NAME World

# 设置容器进程为：python app.py，即：这个Python应用的启动命令
CMD ["python", "app.py"]

通过这个文件的内容，你可以看到 Dockerfile 的设计思想，是使用一些标准的原语（即大写高亮的词语），描述我们所要构建的 Docker 镜像。并且这些原语，都是按顺序处理的。

在使用 Dockerfile 时，你可能还会看到一个叫作 ENTRYPOINT 的原语。实际上，它和 CMD 都是 Docker 容器进程启动所必需的参数，完整执行格式是：“ENTRYPOINT CMD”。
但是，默认情况下，Docker 会为你提供一个隐含的 ENTRYPOINT，即：/bin/sh -c。所以，在不指定 ENTRYPOINT 时，比如在我们这个例子里，实际上运行在容器里的完整进程是：/bin/sh -c "python app.py"，即 CMD 的内容就是 ENTRYPOINT 的参数。

接下来，我就可以让 Docker 制作这个镜像了，在当前目录执行：

$ docker build -t helloworld .

其中，-t 的作用是给这个镜像加一个 Tag，即：起一个好听的名字。docker build 会自动加载当前目录下的 Dockerfile 文件，然后按照顺序，执行文件中的原语。而这个过程，实际上可以等同于 Docker 使用基础镜像启动了一个容器，然后在容器中依次执行 Dockerfile 中的原语。
需要注意的是，Dockerfile 中的每个原语执行后，都会生成一个对应的镜像层。即使原语本身并没有明显地修改文件的操作（比如，ENV 原语），它对应的层也会存在。只不过在外界看来，这个层是空的。
docker build 操作完成后，就可以通过 docker images 命令查看结果：

$ docker image ls
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
helloworld   latest    041c8cbc5273   2 minutes ago   158MB

通过这个镜像 ID，你就可以使用之前讲过的方法，查看这些新增的层在 AuFS 路径下对应的文件和目录了。

接下来，使用这个镜像，通过 docker run 命令启动容器：

$ docker run -p 4000:80 helloworld

在这一句命令中，镜像名 helloworld 后面，我什么都不用写，因为在 Dockerfile 中已经指定了 CMD。否则，我就得把进程的启动命令加在后面：

$ docker run -p 4000:80 helloworld python app.py

容器启动之后，我可以使用 docker ps 命令看到：

$ docker ps
CONTAINER ID   IMAGE        COMMAND           CREATED          STATUS          PORTS                                   NAMES
18b77b6e8e79   helloworld   "python app.py"   10 minutes ago   Up 10 minutes   0.0.0.0:4000->80/tcp, :::4000->80/tcp   romantic_edison

同时，我已经通过 -p 4000:80 告诉了 Docker，请把容器内的 80 端口映射在宿主机的 4000 端口上。
这样做的目的是，只要访问宿主机的 4000 端口，我就可以看到容器里应用返回的结果：

$ curl localhost:4000
<h3>Hello World!</h3><b>Hostname:</b> 18b77b6e8e79<br/>

至此，我已经使用容器完成了一个应用的开发与测试，如果现在想要把这个容器的镜像上传到 DockerHub 上分享给更多的人，我要怎么做呢？
为了能够上传镜像，我首先需要注册一个 Docker Hub 账号，然后使用 docker login 命令登录。
接下来，我要用 docker tag 命令给容器镜像起一个完整的名字：

$ docker tag helloworld geektime/helloworld:v1

然后，执行 docker push 就可以把这个镜像上传到 Docker Hub 上了。
此外，我还可以使用 docker commit 指令，把一个正在运行的容器，直接提交为一个镜像，比如：

$ docker exec -it 18b77b6e8e79 /bin/sh
# ls           
Dockerfile  app.py  requirements.txt
# touch test.txt 
# exit
$ sudo docker commit 18b77b6e8e79 cheyne94/helloworld:v2
sha256:06aebbce938acb5a3344b76e99949c5c0180508ec3bb5401d4fe79c75ffd364a

这里，我使用了 docker exec 命令进入到了容器当中。在了解了 Linux Namespace 的隔离机制后，你应该会很自然地想到一个问题：docker exec 是怎么做到进入容器里的呢？
实际上，Linux Namespace 创建的隔离空间虽然看不见摸不着，但一个进程的 Namespace 信息在宿主机上是确确实实存在的，并且是以一个文件的方式存在。
比如，通过如下指令，你可以看到当前正在运行的 Docker 容器的进程号（PID）是 1329191：

$ docker inspect --format '{{ .State.Pid }}' 18b77b6e8e79 
1329191

这时就可以通过查看宿主机的 proc 文件，看到这个进程的所有 Namespace 对应的文件：

$ ls -l /proc/1329191/ns
total 0
lrwxrwxrwx 1 root root 0 Dec 25 17:45 cgroup -> 'cgroup:[4026531835]'
lrwxrwxrwx 1 root root 0 Dec 25 17:45 ipc -> 'ipc:[4026532402]'
lrwxrwxrwx 1 root root 0 Dec 25 17:45 mnt -> 'mnt:[4026532400]'
lrwxrwxrwx 1 root root 0 Dec 25 17:45 net -> 'net:[4026532405]'
lrwxrwxrwx 1 root root 0 Dec 25 17:45 pid -> 'pid:[4026532403]'
lrwxrwxrwx 1 root root 0 Dec 25 18:04 pid_for_children -> 'pid:[4026532403]'
lrwxrwxrwx 1 root root 0 Dec 25 18:04 time -> 'time:[4026531834]'
lrwxrwxrwx 1 root root 0 Dec 25 18:04 time_for_children -> 'time:[4026531834]'
lrwxrwxrwx 1 root root 0 Dec 25 18:04 user -> 'user:[4026531837]'
lrwxrwxrwx 1 root root 0 Dec 25 17:45 uts -> 'uts:[4026532401]'

可以看到，一个进程的每种 Linux Namespace，都在它对应的 /proc///ns 下有一个对应的虚拟文件，并且链接到一个真实的 Namespace 文件上。
有了这样一个可以“hold 住”所有 Linux Namespace 的文件，我们就可以对 Namespace 做一些很有意义事情了，比如：加入到一个已经存在的 Namespace 当中。
这也就意味着：一个进程，可以选择加入到某个进程已有的 Namespace 当中，从而达到“进入”这个进程所在容器的目的，这正是 docker exec 的实现原理。
而这个操作所依赖的，乃是一个名叫 setns() 的 Linux 系统调用。它的调用方法，我可以用如下一段小程序为你说明：

#define _GNU_SOURCE
#include <fcntl.h>
#include <sched.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>

#define errExit(msg) do { perror(msg); exit(EXIT_FAILURE);} while (0)

int main(int argc, char *argv[]) {
    int fd;
    
    fd = open(argv[1], O_RDONLY);
    if (setns(fd, 0) == -1) {
        errExit("setns");
    }
    execvp(argv[2], &argv[2]); 
    errExit("execvp");
}

这段代码功能非常简单：它一共接收两个参数，第一个参数是 argv[1]，即当前进程要加入的 Namespace 文件的路径，比如 /proc/25686/ns/net；而第二个参数，则是你要在这个 Namespace 里运行的进程，比如 /bin/bash。
这段代码的核心操作，则是通过 open() 系统调用打开了指定的 Namespace 文件，并把这个文件的描述符 fd 交给 setns() 使用。在 setns() 执行后，当前进程就加入了这个文件对应的 Linux Namespace 当中了。
现在，你可以编译执行一下这个程序，加入到容器进程（PID=1329191）的 Network Namespace 中：

$ sudo ./setns_test /proc/1329191/ns/net /bin/bash
$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.2  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:ac:11:00:02  txqueuelen 0  (Ethernet)
        RX packets 31  bytes 2332 (2.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13  bytes 1027 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

正如上所示，当我们执行 ifconfig 命令查看网络设备时，我会发现能看到的网卡“变少”了：只有两个。而我的宿主机则至少有四个网卡。这是怎么回事呢？
实际上，在 setns() 之后我看到的这两个网卡，正是我在前面启动的 Docker 容器里的网卡。也就是说，我新创建的这个 /bin/bash 进程，由于加入了该容器进程（PID=1329191）的 Network Namepace，它看到的网络设备与这个容器里是一样的，即：/bin/bash 进程的网络设备视图，也被修改了。
而一旦一个进程加入到了另一个 Namespace 当中，在宿主机的 Namespace 文件上，也会有所体现。
在宿主机上，你可以用 ps 指令找到这个 set_ns 程序执行的 /bin/bash 进程，其真实的 PID 是 1425499：

$ ps aux | grep /bin/bash
root     1425499  0.1  0.0 222992  5088 pts/6    S+   19:44   0:00 /bin/bash

这时，如果按照前面介绍过的方法，查看一下这个 PID=1425499 的进程的 Namespace，你就会发现这样一个事实：

$ sudo ls -l /proc/1329191/ns/net
lrwxrwxrwx 1 root root 0 Dec 25 17:45 /proc/1329191/ns/net -> 'net:[4026532405]'
$ sudo ls -l /proc/1425499/ns/net
lrwxrwxrwx 1 root root 0 Dec 25 19:44 /proc/1425499/ns/net -> 'net:[4026532405]'

在 /proc/<PID>/ns/net 目录下，这个 PID=1425499 进程，与我们前面的 Docker 容器进程（PID=1329191）指向的 Network Namespace 文件完全一样。这说明这两个进程，共享了这个名叫 net:[4026532405]的 Network Namespace。
此外，Docker 还专门提供了一个参数，可以让你启动一个容器并“加入”到另一个容器的 Network Namespace 里，这个参数就是 –net，比如：

$ docker run -it --net container:18b77b6e8e79 busybox ifconfig

这样，我们新启动的这个容器，就会直接加入到 ID=18b77b6e8e79 的容器，也就是我们前面的创建的 Python 应用容器（PID=1329191）的 Network Namespace 中。所以，这里 ifconfig 返回的网卡信息，跟我前面那个小程序返回的结果一模一样。
而如果我指定–net=host，就意味着这个容器不会为进程启用 Network Namespace。这就意味着，这个容器拆除了 Network Namespace 的“隔离墙”，所以，它会和宿主机上的其他普通进程一样，直接共享宿主机的网络栈。这就为容器直接操作和使用宿主机网络提供了一个渠道。
转了一个大圈子，我其实是为你详细解读了 docker exec 这个操作背后，Linux Namespace 更具体的工作原理。

现在，我们再一起回到前面提交镜像的操作 docker commit 上来吧。
docker commit，实际上就是在容器运行起来后，把最上层的“可读写层”，加上原先容器镜像的只读层，打包组成了一个新的镜像。当然，下面这些只读层在宿主机上是共享的，不会占用额外的空间。
而由于使用了联合文件系统，你在容器里对镜像 rootfs 所做的任何修改，都会被操作系统先复制到这个可读写层，然后再修改。这就是所谓的：Copy-on-Write。
而正如前所说，Init 层的存在，就是为了避免你执行 docker commit 时，把 Docker 自己对 /etc/hosts 等文件做的修改，也一起提交掉。
有了新的镜像，我们就可以把它推送到 Docker Hub 上了：

$ docker push geektime/helloworld:v2

你可能还会有这样的问题：我在企业内部，能不能也搭建一个跟 Docker Hub 类似的镜像上传系统呢？
当然可以，这个统一存放镜像的系统，就叫作 Docker Registry。感兴趣的话，你可以查看Docker 的官方文档，以及VMware 的 Harbor 项目。

最后，我再来讲解一下 Docker 项目另一个重要的内容：Volume（数据卷）。
前面我已经介绍过，容器技术使用了 rootfs 机制和 Mount Namespace，构建出了一个同宿主机完全隔离开的文件系统环境。这时候，我们就需要考虑这样两个问题：

1. 容器里进程新建的文件，怎么才能让宿主机获取到？
2. 宿主机上的文件和目录，怎么才能让容器里的进程访问到？
   这正是 Docker Volume 要解决的问题：Volume 机制，允许你将宿主机上指定的目录或者文件，挂载到容器里面进行读取和修改操作。
   在 Docker 项目里，它支持两种 Volume 声明方式，可以把宿主机目录挂载进容器的 /test 目录当中：

   $ docker run -v /test ...
   $ docker run -v /home:/test ...

而这两种声明方式的本质，实际上是相同的：都是把一个宿主机的目录挂载进了容器的 /test 目录。
只不过，在第一种情况下，由于你并没有显示声明宿主机目录，那么 Docker 就会默认在宿主机上创建一个临时目录 /var/lib/docker/volumes/[VOLUME_ID]/_data，然后把它挂载到容器的 /test 目录上。而在第二种情况下，Docker 就直接把宿主机的 /home 目录挂载到容器的 /test 目录上。
那么，Docker 又是如何做到把一个宿主机上的目录或者文件，挂载到容器里面去呢？难道又是 Mount Namespace 的黑科技吗？
实际上，并不需要这么麻烦。
在之前的分享中已经介绍过，当容器进程被创建之后，尽管开启了 Mount Namespace，但是在它执行 chroot（或者 pivot_root）之前，容器进程一直可以看到宿主机上的整个文件系统。
而宿主机上的文件系统，也自然包括了我们要使用的容器镜像。这个镜像的各个层，保存在 /var/lib/docker/aufs/diff 目录下，在容器进程启动后，它们会被联合挂载在 /var/lib/docker/aufs/mnt/ 目录中，这样容器所需的 rootfs 就准备好了。
所以，我们只需要在 rootfs 准备好之后，在执行 chroot 之前，把 Volume 指定的宿主机目录（比如 /home 目录），挂载到指定的容器目录（比如 /test 目录）在宿主机上对应的目录（即 /var/lib/docker/aufs/mnt/[可读写层 ID]/test）上，这个 Volume 的挂载工作就完成了。
更重要的是，由于执行这个挂载操作时，“容器进程”已经创建了，也就意味着此时 Mount Namespace 已经开启了。所以，这个挂载事件只在这个容器里可见。你在宿主机上，是看不见容器内部的这个挂载点的。这就保证了容器的隔离性不会被 Volume 打破。

注意：这里提到的”容器进程”，是 Docker 创建的一个容器初始化进程 (dockerinit)，而不是应用进程 (ENTRYPOINT + CMD)。dockerinit 会负责完成根目录的准备、挂载设备和目录、配置 hostname 等一系列需要在容器内进行的初始化操作。最后，它通过 execv() 系统调用，让应用进程取代自己，成为容器里的 PID=1 的进程。

而这里要使用到的挂载技术，就是 Linux 的绑定挂载（bind mount）机制。它的主要作用就是，允许你将一个目录或者文件，而不是整个设备，挂载到一个指定的目录上。并且，这时你在该挂载点上进行的任何操作，只是发生在被挂载的目录或者文件上，而原挂载点的内容则会被隐藏起来且不受影响。
其实，如果你了解 Linux 内核的话，就会明白，绑定挂载实际上是一个 inode 替换的过程。在 Linux 操作系统中，inode 可以理解为存放文件内容的“对象”，而 dentry，也叫目录项，就是访问这个 inode 所使用的“指针”。

正如上图所示，mount –bind /home /test，会将 /home 挂载到 /test 上。其实相当于将 /test 的 dentry，重定向到了 /home 的 inode。这样当我们修改 /test 目录时，实际修改的是 /home 目录的 inode。这也就是为何，一旦执行 umount 命令，/test 目录原先的内容就会恢复：因为修改真正发生在的，是 /home 目录里。
所以，在一个正确的时机，进行一次绑定挂载，Docker 就可以成功地将一个宿主机上的目录或文件，不动声色地挂载到容器中。
这样，进程在容器里对这个 /test 目录进行的所有操作，都实际发生在宿主机的对应目录（比如，/home，或者 /var/lib/docker/volumes/[VOLUME_ID]/_data）里，而不会影响容器镜像的内容。
那么，这个 /test 目录里的内容，既然挂载在容器 rootfs 的可读写层，它会不会被 docker commit 提交掉呢？
也不会。
这个原因其实我们前面已经提到过。容器的镜像操作，比如 docker commit，都是发生在宿主机空间的。而由于 Mount Namespace 的隔离作用，宿主机并不知道这个绑定挂载的存在。所以，在宿主机看来，容器中可读写层的 /test 目录（/var/lib/docker/aufs/mnt/[可读写层 ID]/test），始终是空的。
不过，由于 Docker 一开始还是要创建 /test 这个目录作为挂载点，所以执行了 docker commit 之后，你会发现新产生的镜像里，会多出来一个空的 /test 目录。毕竟，新建目录操作，又不是挂载操作，Mount Namespace 对它可起不到“障眼法”的作用。
结合以上的讲解，我们现在来亲自验证一下：
首先，启动一个 helloworld 容器，给它声明一个 Volume，挂载在容器里的 /test 目录上：

$ docker run -d -v /test helloworld

容器启动之后，我们来查看一下这个 Volume 的 ID：

$ docker volume ls
DRIVER              VOLUME NAME
local               cb1c2f7221fa9b0971cc35f68aa1034824755ac44a034c0c0a1dd318838d3a6d

然后，使用这个 ID，可以找到它在 Docker 工作目录下的 volumes 路径：

$ ls /var/lib/docker/volumes/cb1c2f7221fa/_data/

这个 _data 文件夹，就是这个容器的 Volume 在宿主机上对应的临时目录了。
接下来，我们在容器的 Volume 里，添加一个文件 text.txt：

$ docker exec -it cf53b766fa6f /bin/sh

这时，我们再回到宿主机，就会发现 text.txt 已经出现在了宿主机上对应的临时目录里：

$ ls /var/lib/docker/volumes/cb1c2f7221fa/_data/

可是，如果你在宿主机上查看该容器的可读写层，虽然可以看到这个 /test 目录，但其内容是空的（关于如何找到这个 AuFS 文件系统的路径，请参考我上一次分享的内容）：

$ ls /var/lib/docker/aufs/mnt/6780d0778b8a/test

可以确认，容器 Volume 里的信息，并不会被 docker commit 提交掉；但这个挂载点目录 /test 本身，则会出现在新的镜像当中。
以上内容，就是 Docker Volume 的核心原理了。