关键Docker命令：使用Docker必须掌握的公认宝典

读者可以将下面的命令纲要当作成功使用Docker必须掌握的公认宝典——从搜索和构建镜像到创建自己的Dockerfile。我们先看一些简单的命令，然后在此基础上接触更复杂的命令。

7.1.1 docker search

docker search命令能够在Docker CLI上运行，以搜索Docker注册中心中可用的镜像：

docker search [options] term

基于图形界面的客户端也提供了搜索功能。

在图7-1展示的例子中，docker search mysql返回所有镜像名字中包含“mysql”的镜像。正如所见到的，它返回了前25个结果。基于图形界面的搜索提供了相似的结果，如图7-2所示。

图7-1 Docker搜索“mysql”的结果

图7-2 基于图形界面搜索“mysql”的结果

尽管像dockerizedrupal这样的一些结果是唯一的，但多数结果是重复的，因为这些镜像被不同用户上传，这些用户将镜像用于定制或者用于进行集成。当使用-s选项时，搜索只提供被广泛使用（基于其他用户的反馈）的文件：

docker search –s 50 mysql

该命令会返回镜像名中包含“mysql”并且反馈至少有50颗星的所有镜像，如图 7-3所示。

图7-3 镜像名字中有“mysql”并且反馈至少有50颗星的搜索结果

在这种情况下，只列出两条，因为超过50评级的只有两条。

注意　Docker一直以惊人的速度发展，因此命令、选项甚至特性和功能都在不同版本之间频繁变化。例如，在编写本书时，搜索的-s被废弃了，取而代之的是必须使用称为--filter的标志。对于filter选项，列出所有评价星级超过50颗的所有MySQL镜像的命令会是

docker search --filter stars=50 mysql

7.1.2 docker pull

docker pull命令将请求的镜像从Docker注册中心下载到本地机器：

docker pull image:tag

例如，如图7-4所示，docker pull mysql从注册中心拉取MySQL镜像。如果没有指定版本之类的标签，这个命令默认会附加“latest”标签，而不是拉取所有可用的MySQL镜像。这个命令等价于

docker pull MySQL:latest

图7-4 docker pull从注册中心拉取MySQL的latest镜像

7.1.3 docker images

docker images命令返回本地机器上可用的顶层镜像列表：

docker images[options]

例如，docker images-a展示所有顶层镜像列表，包括它们的仓库、标签、创建日期和虚拟尺寸，如图7-5所示，但它没有展示中间层的镜像。

图7-5 docke images-a命令展示所有顶层镜像列表，包括它们的仓库、标签、创建日期和虚拟尺寸

要记住的一件重要的事情是，当在本地机器上创建或构建Docker镜像时，也创建了各种中间层。例如，如果使用包含多个命令的Dockerfile构建镜像，则执行的每个命令都会产生一个镜像层，这是Docker的关键方面之一，这使容器轻量并且非常适合复用。

7.1.4 docker rmi

docker rmi命令从本地机器上删除所要求的镜像：

docker rmi[options] image [image, image...]

例如，图7-6所示的docker rmi mysql命令从宿主机上删除了MySQL镜像，包括安装的所有层。

图7-6 通过docker rmi mysql命令删除MySQL镜像

7.1.5 docker run

下载（拉取）了镜像之后，下一步就是执行（运行）镜像，这正是docker run命令所要做的事情：

docker run [options] image: tag [command, args]

这个命令使用容器自己的文件系统、端口和IP地址启动容器。我们还可以用一个或多个参数给run命令传递一些选项。下面是一些常用选项：

i切换到STDIN打开的交互模式；

t分配一个伪tty控制台终端。

docker run命令还有许多其他选项，例如，以分离（-d）状态（后台）启动进程，也就是说，容器会启动但不监听命令行。我们可以指定命令来覆盖想要运行的镜像自身的默认命令，也可以指定CPU和内存方面的运行时约束。

举个例子，让我们拉取Ubuntu镜像并执行run命令（见图7-7）：

docker pull ubuntu:latest

图7-7 从Docker Hub仓库下载Ubuntu镜像

该命令将最新的Ubuntu镜像拉取到本地主机上，如图7-8所示。

图7-8 拉取的最新Ubuntu镜像

现在，让我们用i和t选项在本地主机上运行Ubuntu。我们还指明了我们想要运行shell进程：

docker run –it ubuntu sh

现在我们在本地机器上运行了一个带有shell提示符入口的Ubuntu容器。从这里，我们可以运行我们想要的任何shell命令。图7-9展示了几个简单的例子。例如：

echo 'Learning Docker'；

ls；

cd bin（为了查看bin目录的内容）。

图7-9 运行交互式shell

正如所见，bin目录有系统运转所需的关键程序。

7.1.6 docker ps

docker ps命令列出所有正在运行的容器（见图7-10）：

docker ps [Options]

记住，每个容器运行且只运行一个进程。在这个例子中，没有正在运行的容器，因此展示了一个空列表。

图7-10 docker ps命令显示了所有当前正在运行的容器

让我们用-a选项再次运行ps命令，如图7-11所示，以查看所有容器，甚至是那些没有运行的容器。

图7-11 -a选项将不活跃的容器混合到结果中

正如所见，由于退出了shell提示符，Ubuntu容器不再运行或活跃，但是它并没有被删除，只是不活跃而已。如果愿意，我们可以重启容器，我们很快就会学到。

7.1.7 docker logs

docker ogs命令提供了指定容器的日志文件，该日志文件包含了容器的标准输出（stdout和stderr）：

docker logs [Options] Container

这一命令仅适用于带有JSON文件日志驱动的容器。举个例子，让我们用下面的命令运行shell进程：

docker run –it ubuntu sh

运行几个shell命令，如ls -a和cd bin，如图7-12所示。

图7-12 shell命令的一些例子

打开另一个终端窗口，通过下面的命令来查找我们刚刚启动的Ubuntu容器的容器ID（见图7-13）：

docker ps –a

图7-13 查找我们刚刚启动的Ubuntu容器的容器ID

复制运行的Ubuntu容器的容器ID。现在，我们可以执行log命令来查看这个特定容器的日志（见图7-14）：

docker log eded3539719c

我们能够看到日志的内容，在这个例子中是已经执行的命令的历史。

图7-14 执行log命令来查看容器的日志

举一个更复杂的例子。让我们先下载并创建MySQL容器。

首先，拉取最新的MySQL镜像（见图7-15）：

docker pull MySQL: latest

图7-15 拉取的最新MySQL镜像

下一步，使用run命令创建MySQL容器（见图7-16），并记录容器ID：

docker run --name myDatabase 
> -e MySQL_ROOT_PASSWORD=myPassword 
> -d MySQL:latest

这里，name是数据库名，e是指定数据库密码的环境变量的标志，docker run命令的d选项以分离模式启动进程。

图7-16 运行MySQL容器

接下来，验证容器进程：

docker ps

注意，容器启动并运行起来，如图7-17所示。

图7-17 验证容器进程

现在容器已经启动并运行起来，我们需要连接它。我们首先要知道的是端口。尽管我们知道默认端口是什么，但我们还是通过运行logs命令来检查一下日志文件：

docker logs fcb85434597b

这里，fcb85434597b是之前启动的容器的容器ID（见图7-18）。

图7-18 运行logs命令

如图7-19所示，我们看到MySQL的版本和正在监听的端口。请再次注意，Docker日志展示了容器的stdout和stderr的信息，不要将其与MySQL的标准日志文件混淆。

图7-19 MySQL的版本及正在监听的端口

注意　另一个检查容器正在监听什么端口的方法是查看docker ps输出。如果你有留意，图7-18中有一个PORTS列显示了3306/tcp，这表明MySQL将监听3306端口。

7.1.8 docker restart

docker restart命令会重启指定的容器：

docker restart [Options] Container ID (s)

让我们通过指定容器ID来重启Ubuntu容器，前面的例子中该容器ID是c8b9770c88e9，如图7-20所示。

图7-20 重启Ubuntu容器

如果再次运行ps命令，应该会看到一个活动的容器，如图7-21所示。

图7-21 ps命令显示了一个活动的容器

正如所见，我们没有得到shell提示符。我们可以通过运行docker attach命令来解决这个问题，接下来将讨论这个命令。

7.1.9 docker attach

docker attach命令允许使用者连接到指定的正在运行的容器上，以交互式地控制它或者查看正在进行的输出：

docker attach[Options] Container ID

运行这个命令，连接到c8b9770c88e9的Ubuntu容器，以与shell提示符交互，如图7-22所示。

图7-22 通过docker attach命令与shell提示符交互

注意，命令提示符回来了，我们可以继续了。另一个重要的方面是，无论什么时候重启这个容器，我们总是会得到shell提示符。我们无法改变其行为，因为这是最初在run命令中使用-it启动容器的方式。不过我们肯定可以使用不同的选项、参数和命令再次运行相同的Ubuntu镜像。这正是Docker的美妙之处。

7.1.10 docker rm

docker rm命令会删除一个或多个指定的容器：

docker rm [Options] Container(s)

例如，让我们尝试删除Ubuntu容器。在删除容器前必须停止容器，或者使用-f（强制）选项直接删除容器，这实际上会给容器内运行的进程发送SKGKILL，然后将容器删除：

docker stop [Options] Container(s)

图7-23展示了Ubuntu容器的状态。Ubuntu容器处于运行状态，并已经运行了38个小时，如状态属性所示。

图7-23 Ubuntu容器的状态

让我们运行stop命令并再次执行ps`` -``a，如图7-24所示。

图7-24 运行stop命令并再次执行ps -a

正如所见，容器不再运行，状态是以代码137退出，这意味着容器收到了SIGKILL命令。stop命令会在一定的宽限期之后发送SIGTERM和SIGKILL。我们可以用-t选项指定秒数来调整宽限期。当我们想让进程完成重要的请求时，时间选项对这样的实例可能是非常重要的，HTTP就是这种情况。

我们也可以使用docker kill命令，它直接发送SIGKILL。它不会给容器进程优雅地退出的机会，但它让我们可以向容器进程发送除SIGKILL之外的其他东西。

现在，容器停止了，让我们删除容器并再次执行ps -a，如图7-25所示。

图7-25 被删除的容器

注意，容器已经被完全删除，ps -a命令中已经没有任何踪迹。

7.1.11 docker inspect

docker inspect命令提供了关于容器或镜像的底层、深入的信息：

docker inspect [Options] Container ID/Image

让我们在MySQL容器上运行这个命令，如图7-26所示。回想一下，fcb85434597b是之前示例的容器ID：

docker inspect fcb85434597b

图7-26 docker inspect的结果

注意，这个命令返回了包含所有信息的完整的JSON数组。我们还可以指定其他格式或者查询某些特定信息，如数据库名、IP地址和端口信息。

下面这一命令将返回数据库名：

docker inspect –format='{{.Name}}' fcb85434597b

下面这一命令将返回MySQL容器的IP地址：

docker inspect 
> –format='{{.NetworkSettings.IPAddress}}' fcb85434597b

7.1.12 docker exec

docker exec命令可以在已经运行的容器中远程运行命令：

docker exec [Options] Container ID Command [Arg...]

让我们在Ubuntu容器中运行这个命令，如图7-27所示。c8b9770c88e9是之前示例的容器ID：

docker exec c8b9770c88e9 ls -a

图7-27 docker exec命令可以在已经运行的容器中运行命令

7.1.13 docker rename

是否已经厌倦了复制和粘贴容器ID？我们可以给容器起有意义的名字，这样可以更容易记忆和分类。使用docker rename命令可以重新命名已经运行的容器：

Usage: docker rename Container ID new_name

让我们重新给Ubuntu容器命名。先来查找已有的名字：

docker ps -a

注意，在图7-28中，容器当前的名字是jolly_gates。

图7-28 docker ps -a的结果

让我们执行rename命令：

docker rename e510f8e769fc Parminder

注意，在图7-29中，执行rename命令改变了容器的名字。

图7-29 容器重新命名成功

我们现在可以使用这个新名字运行其他各种命令，而不是使用8位数的ID，如图7-30所示。

图7-30 用新名字运行其他命令

7.1.14 docker cp

docker cp命令能够在容器和运行容器的机器之间复制文件。下面的命令形式将文件从容器复制到本地机器：

docker cp [OPTIONS] CONTAINER:SRC_PATH DEST_PATH

下面的命令形式将文件从本地机器复制到指定的容器：

docker cp [OPTIONS] SRC_PATH|- CONTAINER:DEST_PATH

让我们用Ubuntu容器运行第一个命令。图7-31展示了这个例子中要使用的sample.txt文件。

图7-31 我们将使用的sample.txt文件

Parminder是之前示例的容器名，下面是复制文件的命令（见图7-32）：

docker cp Parminder:/var/sample.txt .

图7-32 将文件从Parminder容器复制到本地机器

现在让我们尝试将文件从本地机器复制到容器的命令。这里，我们使用本地机器上名为MyFile.txt的示例文件，如图7-33所示。

图7-33 将MyFile.txt文件从本地机器复制到容器

下面的命令将MyFile.txt文件复制到名为Parminder的容器中并存放在/var目录下，如图7-34所示。Parminder是之前示例中的容器名：

docker cp MyFile.txt Parminder:/var

图7-34 将MyFile.txt从本地机器复制到名为Parminder的容器的/var目录下

7.1.15 docker pause/unpause

docker pause命令挂起指定容器内的所有进程：

docker pause CONTAINER [CONTAINER...]

在Linux中，这个命令使用了cgroups的freezer。docker unpause命令让容器再次运行：

docker unpause CONTAINER [CONTAINER...]

让我们用Ubuntu容器运行docker pause命令，如图7-35所示。Parminder是之前示例的容器名：

docker pause Parminder

图7-35 用Ubuntu容器运行docker pause命令

我们刚刚暂停了容器，有效地暂停了其中所有进程。尝试在容器内运行命令，会发现与图7-36所示的类似情况。

图7-36 尝试在已暂停的容器内运行命令

让我们取消暂停（见图7-37）：

docker unpause Parminder

图7-37 取消暂停的容器

由于我们刚刚取消容器的暂停，因此所有进程又再次恢复运行。挂起的ls命令（处于等待状态）也完成了运行，如图7-38所示。

图7-38 挂起的ls命令，之前处于等待状态，现在完成了执行

7.1.16 docker create

docker create命令在指定镜像之上创建可写的容器层并为运行指定的命令做好准备：

docker create [OPTIONS] IMAGE [COMMAND] [ARG...]

容器ID会作为结果输出。这个命令与运行docker run -d的细微差别在于容器并没有启动。接下来可以使用docker start命令启动容器。例如，当IT团队想要预先搭建一个容器，以便在准备好上线时可以随时启动的时候，这种创建容器却推迟启动的能力是很方便的。

让我们创建一个新容器（见图7-39）：

docker create -t -i fedora bash

图7-39 新创建的容器

注意，这个容器被创建了但并未启动。

7.1.17 docker commit

docker commit命令简单但却非常重要——它容许用容器的更改来创建新镜像：

docker commit{Options} Container [Repository:Tag]

当对容器进行了修改并且想将其作为新镜像发送给另一个开发者或测试团队时，这个命令可以从运行的容器创建新镜像。

7.1.18 docker diff

docker diff命令是另一个重要命令，它的功能不言而喻——列出容器文件系统中变化的文件和目录：

docker diff Container ID

随着时间推移，当对容器进行了修改时，这个命令会突出显示文件系统相对于基础镜像的差异。

本文摘自《微服务与容器》

本书作者长期担任系统架构和工程团队的领导者，他在本书中分析了两个最热的新技术趋势——微服务和容器。正如作者所展示的，微服务和Docker容器能够为应用开发和部署带来的敏捷性和伸缩性，特别是在速度是关键而小错误可能带来灾难性后果的复杂的大型项目中。

为了便于读者学习如何利用微服务和Docker 来驱动模块化架构设计、按需扩展、应用性能和可靠性、上市时间、代码复用以及DevOps 效能的指数级提升，作者不但提供了从单体架构迁移的详细指导和完整路线图，而且提供了一个带领读者了解企业级SOA 系统迁移的深入的案例研究。

本书对软件架构师/开发者、希望继续坚持使用旧方法的系统专业人员以及尝试*大化这些技术的业务价值的管理者，都是很宝贵的参考资料。

• 理解微服务如何能够让使用者将应用组织到易于管理、更新和扩展的独立组件中。
• 决定微服务和容器是否值得投入并管理与它们相关的组织学习曲线。
• 应用微服务之间进程间通信的*佳实践。
• 以有序的方式迁移单体系统。
• 理解Docker 容器，了解Docker的安装和Docker接口。
• 网络、编排和有效地管理Docker容器。
• 使用Docker*大化基于微服务的应用的扩展性。
• 通过深入、动手的案例研究来应用所学。