容器created状态_测试必会 | 通过容器化 Python Web 掌握 Docker 容器核心技能下

本篇文章将通过一个非常典型的 Python Web 应用作为案例，讲解 Docker 容器使用的主要场景。包括构建镜像、启动镜像、分享镜像、在镜像中操作、在镜像中挂载宿主机目录、对容器使用的资源进行限制、管理容器的状态和如何保持容器始终运行。熟悉了这些操作，你也就基本上摸清了 Docker 容器的核心功能。

前期准备：需要一台已经安装了 Docker 的 Linux 虚拟机。

容器与宿主机之间如何共享文件

容器技术使用了 rootfs 机制和 Mount Namespace，构建出了一个同宿主机完全隔离开的文件系统环境。但是我们使用过程中经常会遇到这样两个问题：

• 容器里进程新建的文件，怎么才能让宿主机获取到？
• 宿主机上的文件和目录，怎么才能让容器里的进程访问到？

这正是 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 目录上。

启动容器时，给他声明一个 volume

docker run -d -v /test helloworld  

容器启动之后，我们来查看一下这个容器 的 Volume 在宿主机上的对应的目录:

docker volume ls  DRIVER              VOLUME NAME  local               dc195c8ad14ad505832461d9f37da889c54ef284ebaf777a100e10a932217ad3  

或者执行docker inspect CONTAINER_ID命令查看，命令输出的 Mounts 字段中 Source 的值就是宿主机上的目录：

"Mounts": [   {   "Type": "volume",   "Name": "dc195c8ad14ad505832461d9f37da889c54ef284ebaf777a100e10a932217ad3",   "Source": "/var/lib/docker/volumes/dc195c8ad14ad505832461d9f37da889c54ef284ebaf777a100e10a932217ad3/_data",   "Destination": "/test",   "Driver": "local",   "Mode": "",   "RW": true,   "Propagation": ""   }   ],  

然后，查看宿主机上的路径：

ls /var/lib/docker/volumes/dc195c8ad14ad505832461d9f37da889c54ef284ebaf777a100e10a932217ad3/_data  

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

docker exec -it cf53b766fa6f /bin/sh  cd test/  touch text.txt  

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

ls /var/lib/docker/volumes/dc195c8ad14ad505832461d9f37da889c54ef284ebaf777a100e10a932217ad3/_data  text.txt  

因为容器运行时产生的文件，在容器停止后将会消失。因此，将容器的目录映射到宿主机的某个目录，一个重要使用场景是持久化容器中产生的文件，比如应用的日志。

给容器加上资源限制

其实容器是运行在宿主机上的特殊进程，多个容器之间是共享宿主机的操作系统内核的。默认情况下，容器并没有被设定使用操作系统资源的上限。

有些情况下，我们需要限制容器启动后占用的宿主机操作系统的资源。Docker 可以利用 Linux Cgroups 机制可以给容器设置资源使用限制。

Linux Cgroups 的全称是 Linux Control Group。它最主要的作用，就是限制一个进程组能够使用的资源上限，包括 CPU、内存、磁盘、网络带宽等等。Docker 正是利用这个特性限制容器使用宿主上的 CPU、内存。

下面启动容器的方式，给这个 Python 应用加上 CPU 和 Memory 限制：

docker run -it --cpu-period=100000 --cpu-quota=20000 -m 300M helloworld  

–cpu-period 和–cpu-quota 组合使用来限制容器使用的 CPU 时间。表示在–cpu-period 的一段时间内，容器只能被分配到总量为 --cpu-quota 的 CPU 时间。-m 选项则限制了容器使用宿主机内存的上限。

上面启动容器的命令，将容器使用的 CPU 限制设定在最高 20%，内存使用最多是 300MB。

容器的启动、重启、停止与删除

前面我们使用过docker ps 查看当前运行中的容器，如果加上 -a 选项，则可以查看运行中和已经停止的所有容器。现在，看一下我的系统中目前的所有容器：

$ docker ps -a  CONTAINER ID   IMAGE        COMMAND          CREATED      STATUS                 PORTS                  NAMES  525a8c3fc769   helloworld   "python app.py"  4 hours ago  Up 3 minutes           80/tcp                 hardcore_feistel  1695ed10e2cb   helloworld   "python app.py"  4 hours ago  Up 3 minutes           0.0.0.0:5000->80/tcp   focused_margulis7  a242ecaf6cf6   helloworld   "python app.py"  5 hours ago  Exited (0) 4 hours ago                        dazzling_khayyam  be0439b30b2a   helloworld   "python app.py"  5 hours ago  Created                                       vigilant_lalande  

从输出中可以看到目前有四个容器，有两个容器处于 Up 状态，也就是处于运行中的状态，一个容器处于 Exited(0) 状态，也就是退出状态，一个处于 Created 状态。

这里补充说明一下 docker ps -a 的输出结果，一共包含 7 列数据，分别是 CONTAINER ID、IMAGE、COMMAND、CREATED、STATUS、PORTS 和 NAMES。这些列的含义分别如下所示：

• CONTAINER ID：容器 ID，唯一标识容器
• IMAGE：创建容器时所用的镜像
• COMMAND：在容器最后运行的命令
• CREATED：容器创建的时间
• STATUS：容器的状态
• PORTS：对外开放的端口号
• NAMES：容器名(具有唯一性，docker 负责命名)
  获取到容器的 ID 之后，可以对容器的状态进行修改，比如容器 1695ed10e2cb 进行停止、启动、重启：

docker stop 1695ed10e2cb  docker start 1695ed10e2cb  docker restart 1695ed10e2cb  

删除容器，有两种操作：

docker rm 1695ed10e2cb  docker rm -f 1695ed10e2cb  

不带-f 选项，只能删除处于非 Up 状态的容器，带上-f 则可以删除处于任何状态下的容器。

Docker 容器状态的流转关系，可以下面这张图：

这张图对容器的生命周期有了清晰的描述，总结了容器各种状态之间是如何转换的。

需要注意一点是容器可以先创建容器，稍后再启动。也就是可以先执行docker create 创建容器(处于 Created 状态)，再通过docker start 以后台方式启动容器。docker run 命令实际上是 docker create 和 docker start 的组合。

维持容器始终保持运行状态

docker run 指令有一个参数--restart，在容器中启动的进程正常退出或发生 OOM 时， docker 会根据 --restart 的策略判断是否需要重启容器。但如果容器是因为执行 docker stop 或 docker kill 退出，则不会自动重启。

docker 支持如下 restart 策略：

• no – 容器退出时不要自动重启。这个是默认值。
• on-failure[:max-retries] – 只在容器以非 0 状态码退出时重启。可选的，可以退出 docker daemon 尝试重启容器的次数。
• always – 不管退出状态码是什么始终重启容器。当指定 always 时，docker daemon 将无限次数地重启容器。容器也会在 daemon 启动时尝试重启容器，不管容器当时的状态如何。
• unless-stopped – 不管退出状态码是什么始终重启容器。不过当 daemon 启动时，如果容器之前已经为停止状态，不启动它。

在每次重启容器之前，不断地增加重启延迟(上一次重启的双倍延迟，从 100 毫秒开始)，来防止影响服务器。这意味着 daemon 将等待 100ms, 然后 200 ms, 400 ms, 800 ms, 1600 ms 等等，直到超过 on-failure 限制，或执行 docker stop 或 docker rm -f。

如果容器重启成功(容器启动后并运行至少 10 秒)，然后 delay 重置为默认的 100ms。

重启策略示例：

docker run --restart=always 1695ed10e2cb # restart 策略为 always，使得容器退出时 ,docker 将重启它。并且是无限制次数重启。  docker run --restart=on-failure:10 redis #restart 策略为 on-failure, 最大重启次数为 10 的次。容器以非 0 状态连续退出超过 10 次，docker 将中断尝试重启这个容器。  

可以通过 docker inspect 来查看已经尝试重启容器了多少次。例如，获取容器 1695ed10e2cb 的重启次数:

docker inspect -f "{{ .RestartCount }}" 1695ed10e2cb  

或者获取上一次容器重启时间：

docker inspect -f "{{ .State.StartedAt }}" 1695ed10e2cb  

以上，欢迎大家留言探讨。

本文首发于 liuchunming.net ，作者授权发布。

(文章来源于霍格沃兹测试学院)