本章的初衷是在继续深入研究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/ubuntu
50aff78429b1: Pull complete
f6d82e297bce: Pull complete
275abb2c8a6f: Pull complete
9f15a39356d6: Pull complete
fc0342a94c89: Pull complete
Digest: sha256:fbaf303...c0ea5d1212
Status: 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.exe
Windows PowerShell
Copyright (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 CMD
4 S root 1 0 0 - 4560 wait 13:38 ? 00:00:00 /bin/bash
0 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 CMD
4 S root 1 0 0 - 9407 - 00:00:03 /sbin/init
1 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 ls
CONTAINER 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 or container-id>
<command/app>
。在示例中,将本地Shell连接到容器是通过-it
参数实现的。本例中使用名称引用容器,并且告诉Docker运行Bash Shell(在Windows示例中是PowerShell)。使用十六进制ID的方式也可以很容易地引用具体容器。
再次使用Ctrl-PQ组合键
退出容器。
Shell提示符应当退回到Docker主机中。
再次运行docker container ls
命令来确认容器仍处于运行状态。
$ docker container ls
CONTAINER 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 -a
CONTAINER 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 Dockerfile
FROM alpine
LABEL maintainer="nigelpoulton@hotmail.com"
RUN apk add --update nodejs nodejs-npm
COPY . /src
WORKDIR /src
RUN npm install
EXPOSE 8080
ENTRYPOINT ["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/alpine
88286f41530e: Pull complete
Digest: 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 SIZE
Test 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项目