以运维和开发的视角纵观Docker

本章的初衷是在继续深入研究Docker之前，对Docker进行一个整体介绍。

本章主要包含两部分内容。

• 运维（Ops）视角。

• 开发（Dev）视角。

在运维视角中，主要包括下载镜像、运行新的容器、登录新容器、在容器内运行命令，以及销毁容器。

在开发视角中，更多关注与应用相关的内容。本书会从GitHub拉取一些应用代码，解释其中的Dockerfile，将应用容器化，并在容器中运行它们。

通过上面两部分内容，读者可以从整体上理解Docker究竟是什么，以及主要组件之间是如何相互配合的。推荐读者对开发和运维两部分内容都要阅读。

读者无须因为不了解本章部分内容而担心。本书并不准备通过本章的介绍让读者成为专家。本章主要目的是给读者一个宏观概念——这样在后续章节中介绍更细节的内容时，读者能明白各部分之间是如何交互的。

为了能完成本章节阅读，读者只需一个可连接到互联网的Docker主机。Docker节点可以是Linux或者Windows，并且无论这个节点是笔记本上的虚拟机，还是公有云上的一个实例，亦或是数据中心的物理机都没有关系。只需要这个节点能运行Docker并且连接到互联网即可。本书接下来的例子涵盖了Linux和Windows！

此外还有一种快速启动Docker的方式，是Play With Docker（PWD）。Play With Docker是一个基于Web界面的Docker环境，并且可以免费使用。只需要浏览器就可以使用（可能需要读者用Docker Hub账户登录）。这也是我最喜欢的启动临时Docker环境的方式。

4.1　运维视角

当读者安装Docker的时候，会涉及两个主要组件：Docker客户端和Docker daemon（有时也被称为“服务端”或者“引擎”）。

daemon实现了Docker引擎的API。

使用Linux默认安装时，客户端与daemon之间的通信是通过本地IPC/UNIX Socket完成的（/var/run/docker.sock）；在Windows上是通过名为npipe:////./pipe/docker_engine的管道（pipe）完成的。读者可以使用docker version命令来检测客户端和服务端是否都已经成功运行，并且可以互相通信。

> docker version
Client:
 Version:       18.01.0-ce
 API version:   1.35
 Go version:    go1.9.2
 Git commit:    03596f5
 Built: Wed Jan 10 20:11:05 2018
 OS/Arch:       linux/amd64
 Experimental:  false
 Orchestrator:  swarm

Server:
 Engine:
  Version:      18.01.0-ce
  API version:  1.35 (minimum version 1.12)
  Go version:   go1.9.2
  Git commit:   03596f5
  Built:        Wed Jan 10 20:09:37 2018
  OS/Arch:      linux/amd64
  Experimental: false

如果读者能成功获取来自客户端和服务端的响应，那么可以继续后面的操作。如果读者正在使用 Linux，并且服务端返回了异常响应，则可尝试在命令的前面加上 sudo——sudo docker version。如果加上sudo之后命令正常运行，那么读者需要将当前用户加入到docker用户组，或者给本书后面的命令都加上sudo前缀。

4.1.1　镜像

将Docker镜像理解为一个包含了OS文件系统和应用的对象会很有帮助。如果读者实际操作过，就会认为与虚拟机模板类似。虚拟机模板本质上是处于关机状态的虚拟机。在Docker世界中，镜像实际上等价于未运行的容器。如果读者是一名开发者，可以将镜像比作类（Class）。

在Docker主机上运行docker image ls命令。

$ docker image ls
REPOSITORY    TAG     IMAGE ID     CREATED     SIZE

如果读者运行命令环境是刚完成Docker安装的主机，或者是Play With Docker，那么Docker主机中应当没有任何镜像，命令输出内容会如上所示。

在Docker主机上获取镜像的操作被称为拉取（pulling）。如果使用Linux，那么会拉取ubuntu:latest镜像；如果使用Windows，则会拉取microsoft/powershell:nanoserver镜像。

latest: Pulling from library/ubuntu50aff78429b1: Pull completef6d82e297bce: Pull complete275abb2c8a6f: Pull complete9f15a39356d6: Pull completefc0342a94c89: Pull completeDigest: sha256:fbaf303...c0ea5d1212Status: Downloaded newer image for ubuntu:latest

再次运行docker image ls命令来查看刚刚拉取的镜像。

$ docker images
REPOSITORY       TAG      IMAGE ID       CREATED       SIZE
ubuntu           latest   00fd29ccc6f1   3 weeks ago   111MB

关于镜像的存储位置以及镜像内部构成，本书会在后续的章节中详细介绍。现在，读者只需知道镜像包含了基础操作系统，以及应用程序运行所需的代码和依赖包。刚才拉取的ubuntu镜像有一个精简版的Ubuntu Linux文件系统，其中包含部分Ubuntu常用工具。而Windows示例中拉取的microsoft/powershell镜像，则包含了带有PowerShell的Windows Nano Server操作系统。

如果拉取了如nginx或者microsoft/iis这样的应用容器，则读者会得到一个包含操作系统的镜像，并且在镜像中还包括了运行Nginx或IIS所需的代码。

重要的是，Docker的每个镜像都有自己的唯一ID。用户可以通过引用镜像的ID或名称来使用镜像。如果用户选择使用镜像ID，通常只需要输入ID开头的几个字符即可——因为ID是唯一的，Docker知道用户想引用的具体镜像是哪个。

4.1.2　容器

到目前为止，读者已经拥有一个拉取到本地的镜像，可以使用docker container run命令从镜像来启动容器。

在Linux中启动容器的命令如下。

$ docker container run -it ubuntu:latest /bin/bash
root@6dc20d508db0:/#

在Windows中启动容器的命令如下。

> docker container run -it microsoft/powershell:nanoserver pwsh.exeWindows PowerShellCopyright (C) 2016 Microsoft Corporation. All rights reserved.PS C:\>

仔细观察上面命令的输出内容，会注意到每个实例中的提示符都发生了变化。这是因为-it参数会将Shell切换到容器终端——现在已经位于容器内部了！

接下来分析一下docker container run命令。docker container run告诉Docker daemon启动新的容器。其中-it参数告诉Docker开启容器的交互模式并将读者当前的Shell连接到容器终端（在容器章节中会详细介绍）。接下来，命令告诉Docker，用户想基于ubuntu:latest镜像启动容器（如果用户使用Windows，则是基于microsoft/powershell:nanoserver镜像）。最后，命令告诉Docker，用户想要在容器内部运行哪个进程。对于Linux示例来说是运行Bash Shell，对于Windows示例来说则是运行PowerShell。

在容器内部运行ps命令查看当前正在运行的全部进程。

Linux示例如下。

root@6dc20d508db0:/# ps -elf
F S UID    PID  PPID   NI ADDR SZ WCHAN  STIME TTY  TIME CMD4 S root     1     0    0 -  4560 wait   13:38 ?    00:00:00 /bin/bash0 R root     9     1    0 -  8606 -      13:38 ?    00:00:00 ps -elf

Windows示例如下。

PS C:\> ps

Handles   NPM(K)   PM(K)   WS(K)   CPU(s)     Id   SI ProcessName
-------   ------   -----   -----   ------     --   -- -----------      0        5     964    1292     0.00   4716    4 CExecSvc      0        5     592     956     0.00   4524    4 csrss      0        0       0       4               0    0 Idle      0       18    3984    8624     0.13    700    4 lsass      0       52   26624   19400     1.64   2100    4 powershell      0       38   28324   49616     1.69   4464    4 powershell      0        8    1488    3032     0.06   2488    4 services      0        2     288     504     0.00   4508    0 smss      0        8    1600    3004     0.03    908    4 svchost      0       12    1492    3504     0.06   4572    4 svchost      0       15   20284   23428     5.64   4628    4 svchost      0       15    3704    7536     0.09   4688    4 svchost      0       28    5708    6588     0.45   4712    4 svchost      0       10    2028    4736     0.03   4840    4 svchost      0       11    5364    4824     0.08   4928    4 svchost      0        0     128     136    37.02      4    0 System      0        7     920    1832     0.02   3752    4 wininit      0        8    5472   11124     0.77   5568    4 WmiPrvSE

Linux容器中仅包含两个进程。

• PID 1：代表/bin/bash进程，该进程是通过docker container run命令来通知容器运行的。

• PID 9：代表ps -elf进程，查看当前运行中进程所使用的命令/程序。

命令输出中展示的ps -elf进程存在一定的误导，因为这个程序在ps命令退出后就结束了。这意味着容器内长期运行的进程其实只有/bin/bash。

Windows 容器运行中的进程会更多，这是由 Windows 操作系统工作方式决定的。虽然Windows容器中的进程比Linux容器要多，但与常见的Windows服务器相比，其进程数量却是明显偏少的。

按Ctrl-PQ组合键，可以在退出容器的同时还保持容器运行。这样Shell就会返回到Docker主机终端。可以通过查看Shell提示符来确认。

现在读者已经返回到Docker主机的Shell提示符，再次运行ps命令。

Linux示例如下。

$ ps -elf
F S UID       PID  PPID    NI ADDR SZ WCHAN  TIME CMD4 S root        1     0     0 -  9407 -      00:00:03 /sbin/init1 S root        2     0     0 -     0 -      00:00:00 [kthreadd]1 S root        3     2     0 -     0 -      00:00:00 [ksoftirqd/0]1 S root        5     2     -20     0 -      00:00:00 [kworker/0:0H]1 S root        7     2    -0 -     0 -      00:00:00 [rcu_sched]
<snip>0 R ubuntu  22783 22475     0 -  9021 -      00:00:00 ps -elf

Windows示例如下。

> ps
Handles   NPM(K)    PM(K)    WS(K)    CPU(s)     Id  SI ProcessName
-------   ------    -----    -----    ------     --  -- -----------    220       11     7396     7872      0.33   1732   0 amazon-ssm-agen     84        5      908     2096      0.00   2428   3 CExecSvc     87        5      936     1336      0.00   4716   4 CExecSvc    203       13     3600    13132      2.53   3192   2 conhost    210       13     3768    22948      0.08   5260   2 conhost    257       11     1808      992      0.64    524   0 csrss    116        8     1348       580     0.08    592   1 csrss     85        5      532      1136     0.23   2440   3 csrss    242       11     1848       952     0.42   2708   2 csrss     95        5      592       980     0.00   4524   4 csrss    137        9     7784      6776     0.05   5080   2 docker    401       17    22744     14016    28.59   1748   0 dockerd    307       18    13344      1628     0.17    936   1 dwm
    <snip>   1888        0      128       136    37.17      4   0 System    272       15     3372      2452     0.23   3340   2 TabTip     72        7     1184         8     0.00   3400   2 TabTip32    244       16     2676      3148     0.06   1880   2 taskhostw    142        7     6172      6680     0.78   4952   3 WmiPrvSE    148        8     5620     11028     0.77   5568   4 WmiPrvSE

可以看到与容器相比，Docker主机中运行的进程数要多很多。Windows容器中运行的进程要远少于Windows主机，Linux容器中的进程数也远少于Linux主机。

在之前的步骤当中，是使用Ctrl-PQ组合键来退出容器的。在容器内部使用该操作可以退出当前容器，但不会杀死容器进程。读者可以通过docker container ls命令查看系统内全部处于运行状态的容器。

$ docker container lsCONTAINER ID   IMAGE          COMMAND      CREATED  STATUS    NAMES
e2b69eeb55cb   ubuntu:latest  "/bin/bash"  7 mins   Up 7 min  vigilant_borg

上述的输出显示只有一个运行中的容器。这就是前面示例中创建的那个容器。输出中有该容器，证明了容器在退出后依然是运行的。读者可以看到这个进程是7min之前创建的，并且一直在运行。

4.1.3　连接到运行中的容器

执行docker container exec命令，可以将Shell连接到一个运行中的容器终端。因为之前示例中的容器仍在运行，所以下面的示例会创建到该容器的新连接。

Linux示例如下。

$ docker container exec -it vigilant_borg bash
root@e2b69eeb55cb:/#

示例中的容器名为“vigilant_brog”。读者环境中的容器名称会不同，所以请记得将“vigilant_brog”替换为自己Docker主机上运行中的容器名称或者ID。

Windows示例如下。

> docker container exec -it pensive_hamilton pwsh.exe

Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. All rights reserved.
PS C:\>

本例中使用的容器为“pensive_hamilton”。同样，读者环境中的容器名称会不同，所以请记得将“pensive_hamilton”替换为自己Docker主机上运行中的容器名称或者ID。

注意，Shell提示符又发生了变化。此时已登录到了容器内部。

docker container exec命令的格式是docker container exec <options> <container-name container&#45;id="" or=""> <command>。在示例中，将本地Shell连接到容器是通过-it参数实现的。本例中使用名称引用容器，并且告诉Docker运行Bash Shell（在Windows示例中是PowerShell）。使用十六进制ID的方式也可以很容易地引用具体容器。

再次使用Ctrl-PQ组合键退出容器。

Shell提示符应当退回到Docker主机中。

再次运行docker container ls命令来确认容器仍处于运行状态。

$ docker container lsCONTAINER ID   IMAGE          COMMAND      CREATED  STATUS    NAMES
e2b69eeb55cb   ubuntu:latest  "/bin/bash"  9 mins   Up 9 min  vigilant_borg

通过docker container stop和docker container rm命令来停止并杀死容器。切记需要将示例中的名称/ID替换为读者自己的容器对应的名称和ID。

$ docker container stop vigilant_borg
vigilant_borg

$ docker container rm vigilant_borg
vigilant_borg

通过运行docker container ls命令，并指定-a参数来确认容器已经被成功删除。添加-a的作用是让Docker列出所有容器，甚至包括那些处于停止状态的。

$ docker container ls -aCONTAINER ID    IMAGE    COMMAND    CREATED    STATUS    PORTS    NAMES

4.2　开发视角

容器即应用！

在本节中，会分析一份应用代码中的Dockerfile并将其容器化，最终以容器的方式运行。相关代码可从本书配套资源或我的Github主页中获取。

本节接下来的内容会基于 Linux 示例进行演示。但其实两个示例中都容器化了相同的Web 应用代码，所以步骤也是一样的。

进入到仓库文件目录之下，查看其内容。

$ cd psweb
$ ls -l
total 28-rw-rw-r-- 1 ubuntu ubuntu  341 Sep 29 12:15 app.js
-rw-rw-r-- 1 ubuntu ubuntu  216 Sep 29 12:15 circle.yml
-rw-rw-r-- 1 ubuntu ubuntu  338 Sep 29 12:15 Dockerfile
-rw-rw-r-- 1 ubuntu ubuntu  421 Sep 29 12:15 package.json
-rw-rw-r-- 1 ubuntu ubuntu  370 Sep 29 12:15 README.md
drwxrwxr-x 2 ubuntu ubuntu 4096 Sep 29 12:15 test
drwxrwxr-x 2 ubuntu ubuntu 4096 Sep 29 12:15 views

对于Windows示例，读者需要cd到dotnet-docker-samples\aspnetapp目录当中。

Linux的示例是一个简单的Node.js Web应用。Windows示例是一个简单的ASP.NET Web应用。

每个仓库中都包含一个名为Dockerfile的文件。Dockerfile是一个纯文本文件，其中描述了如何将应用构建到Docker镜像当中。

查看Dockerfile的全部内容。

$ cat DockerfileFROM alpineLABEL maintainer="nigelpoulton@hotmail.com"RUN apk add --update nodejs nodejs-npmCOPY . /srcWORKDIR /srcRUN  npm installEXPOSE  8080ENTRYPOINT ["node", "./app.js"]

Windows示例中的Dockerfile内容会有所不同。但是，这些区别在现阶段并不重要。关于Dockerfile的更多细节本书会在接下来的章节中进行详细介绍。现在，只需要知道Dockerfile的每一行都代表一个用于构建镜像的指令即可。

使用docker image build命令，根据Dockerfile中的指令来创建新的镜像。示例中新建的Docker镜像名为test:latest。

一定要在包含应用代码和Dockerfile的目录下执行这些命令。

$ docker image build -t test:latest .

Sending build context to Docker daemon 74.75kB
Step 1/8 : FROM alpine
latest: Pulling from library/alpine88286f41530e: Pull completeDigest: sha256:f006ecbb824...0c103f4820a417d
Status: Downloaded newer image for alpine:latest
 ---> 76da55c8019d<snip>Successfully built f154cb3ddbd4
Successfully tagged test:latest

{注：}　

Windows示例构建可能花费比较长的时间。构建时间长短是由构建过程中要拉取的镜像大小和复杂度决定的。

一旦构建完成，就可以确认主机上是否存在test:latest镜像。

$ docker image ls
REPO     TAG        IMAGE ID         CREATED         SIZETest     latest     f154cb3ddbd4     1 minute ago    55.6MB
...

读者现在已经拥有一个新的Docker镜像，其中包含了应用程序。

从镜像启动容器，并测试应用。

Linux代码如下。

$ docker container run -d \  --name web1 \
  --publish 8080:8080 \
  test:latest

打开Web浏览器，在地址栏中输入容器运行所在的Docker主机的DNS名称或者IP地址，并在后面加上端口号8080。然后就能看到图4.1的Web页面。

如果读者使用的是Windows示例或者Mac版Docker，则需要将地址替换为localhost:8080或者127.0.0.1:8080；如果读者使用的是Play with Docker，需要单击终端界面上的8080超链接。

图4.1　Linux系统测试应用Web界面

Windows代码如下。

> docker container run -d \  --name web1 \
  --publish 8080:80 \
  test:latest

打开Web浏览器，在地址栏中输入容器运行所在的Docker主机的DNS名称或者IP地址，并在后面加上端口号8080，然后就能看到图4.2的Web页面。

图4.2　Windows系统测试应用Web界面

如果读者使用的是Windows示例或者Mac版Docker，则可参考上面的规则。

读者已经成功将应用代码构建到了Docker镜像当中，然后以容器的方式启动该镜像，这个过程叫作“应用容器化”。

4.3　本章小结

在运维部分，我们下载了Docker镜像，启动容器并且登录到容器内部执行相应的命令，最后停止容器并删除。

在开发部分，我们完成了简单应用的容器化过程：从GitHub拉取应用源代码，并且通过Dockerfile中的指令，将应用代码构建到镜像之中。接着运行了该容器化应用。

本章的整体介绍能帮助读者更好地理解接下来的章节，包括镜像与容器相关细节。

本文摘自：《深入浅出Docke》

《深入浅出Docker》([英],Nigel,Poulton（奈吉尔·波尔顿）)

全书分为17章，从Docker概览和Docker技术两部分进行全面解析，深入浅出地介绍了Docker的相关知识，清晰详细的操作步骤结合大量的实际代码帮助读者学以致用，将Docker知识应用到真实的项目开发当中。

###本书特色

• 零基础起步，帮助读者快速建立Docker技术知识体系

• 抽丝剥茧，层层深入，清晰透彻地阐述复杂的逻辑

• 涵盖广泛，从安装入门到应用部署，展示Docker应用全景

###目录结构

版权声明 内容提要 前言 资源与支持 第1章　关于本书的对话 第2章　操作系统介绍 第1部分　虚拟化 第3章　关于虚拟化的对话 第4章　抽象：进程 第5章　插叙：进程API 第6章　机制：受限直接执行 第7章　进程调度：介绍 第8章　调度：多级反馈队列 第9章　调度：比例份额 第10章　多处理器调度（高级） 第11章　关于CPU虚拟化的总结对话 第12章　关于内存虚拟化的对话 第13章　抽象：地址空间 第14章　插叙：内存操作API 第15章　机制：地址转换 第16章　分段 第17章　空闲空间管理 第18章　分页：介绍 第19章　分页：快速地址转换（TLB） 第20章　分页：较小的表 第21章　超越物理内存：机制 第23章　VAX/VMS虚拟内存系统 第24章　内存虚拟化总结对话 第2部分　并发 第25章　关于并发的对话 第26章　并发：介绍 第27章　插叙：线程API 第28章　锁 第29章　基于锁的并发数据结构 第30章　条件变量 第31章　信号量 第32章　常见并发问题 第33章　基于事件的并发（进阶） 第34章　并发的总结对话 第3部分　持久性 第35章　关于持久性的对话 第36章　I/O设备 第37章　磁盘驱动器 第38章　廉价冗余磁盘阵列（RAID） 第39章　插叙：文件和目录 第40章　文件系统实现 第41章　局部性和快速文件系统 第42章　崩溃一致性：FSCK和日志 第43章　日志结构文件系统 第44章　数据完整性和保护 第45章　关于持久的总结对话 第46章　关于分布式的对话 第47章　分布式系统 第48章　Sun的网络文件系统（NFS） 第49章　Andrew文件系统（AFS） 第50章　关于分布式的总结对话 附录A　关于虚拟机监视器的对话 附录B　虚拟机监视器 附录C　关于监视器的对话 附录D　关于实验室的对话 附录E　实验室：指南 附录F　实验室：系统项目 附录G　实验室：xv6项目