CoreOS实践指南（七）：Docker容器管理服务

$ docker run --name node-app -p 3000 --link mongo-ins:mongo -it node /bin/bashroot@e73e7d7836a6:/#  <— 已经进入容器中的Bash>

-it 实际上是 -i -t 的简便写法，表示启用交互式模式和启用显示终端，这样我们可以进入容器中做一些手工操作。而参数 --link 用来将两个容器进行关联，关于Docker Link的用法可以参考 Docker的相关文档 。简单来说，Link的参数 mongo-ins:mongo 表示将容器 mongo-ins 引入到正在建立的容器镜像中，并将其称为 mongo。这样做的结果是，在新建的 node-app 容器实例中，能够访问到两个全局环境变量： $MONGO_PORT_27017_TCP_ADDR 和 $MONGO_PORT_27017_TCP_PORT，分别是用来访问 MongoDB 的 IP 地址和端口。

作为演示，我们将在容器中部署一个从Github获取的简单示例。

$ git clone

https://github.com/ijason/NodeJS-Sample-App.git

$ sed -i -e "s/27017/process.env.MONGO_PORT_27017_TCP_PORT/" -e "s/'localhost'/process.env.MONGO_PORT_27017_TCP_ADDR/" app.js

$ exit

上面的第三条命令将原本容器中指定的 MongoDB 位置改成了从另一个容器中暴露的IP地址和端口。至此这个node-app容器已经部署好了一个名为 Employees 的示例应用，接下来将它生成镜像并放到集群的每个节点上。

三、 生成并提交镜像

为了在集群里对容器中的服务提供横向扩展能力，需要将定制好的容器在集群的所有节点共享。

首先需要一个存放共享镜像的地方，在企业环境可以使用私有的镜像仓库，但为了演示简便起见，我们直接使用Docker的公共仓库。首先需要在 Docker Hub 注册一个用户，然后使用 docker login 命令登陆到仓库服务器。

$ docker login

Username: linfan

Password:

Email: linfan@******.com

Login Succeeded

然后我们需要将本地修改过的容器使用 docker commit 命令生成一个本地的镜像。注意，由于之后需要将镜像提交至Docker Hub，这里镜像的名字必须以自己的Docker Hub用户名作为前缀，否则在后面的 push 时候会遇到 403 “Access Denied: Not allowed to create Repo at given location” 错误。例如名为 linfan/employees。

$ docker commit node-app linfan/employees

a4281aa8baf9aee1173509b30b26b17fd1bb2de62d4d90fa31b86779dd15109b

$ docker images

REPOSITORY  TAG  IMAGE ID  CREATED  VIRTUAL SIZE

linfan/employees  latest  a4281aa8baf9  14 seconds ago  696.2 MB

最后，使用 docker push 命令将这个准备好的镜像提交到Docker Hub仓库中。

$ docker push linfan/employees

The push refers to a repository [linfan/employees] (len: 1)

Sending image list

...

Pushing tag for rev [5577d6743652] on {https://cdn-registry-1.docker.io/v1/repositories/linfan/employees/tags/latest}

提交完成后，在其他节点就可以使用 docker pull 命令获取到这个镜像了。

注意：严格来说，将数据库服务容器通过Docker Link暴露给应用服务容器的方法并不符合分布式应用的 12条准则 ，因为通过Docker Link连接的两个容器必须运行在同一个物理主机上，数据与应用不能在集群中分别独立的部署或横向扩展。

• 使用 Fleet 启动服务容器

一、 编写 Unit 文件

有了相应的服务容器后，在CoreOS中正确启动服务的方法应该是通过Fleet来管理。通过合理使用 Unit 的 X-Fleet 配置，能够很好的解决容器直接相互依赖的问题。

用 vagrant ssh 进入一个 CoreOS 的 Shell 中，创建以下两个服务 Unit 文件。

首先是mongo.service

[Unit]

Description=General MongoDB Service

After=docker.service

[Service]

TimeoutStartSec=0

ExecStart=/opt/bin/docker-run.sh --name mongo-ins -d mongo

ExecStop=/usr/bin/docker stop mongo-ins

然后是employees.service，请注意它的 Unit 和 X-Fleet 段的内容。在Unit段指定了这个服务启动前必须首先启动 mongo.service 服务，而在 X-Fleet 段指定了自己需要运行在与 mongo.service 相同的服务节点上。

[Unit]

Description=Employee Information Management Service

After=docker.service

After=mongo.service

[Service]

TimeoutStartSec=0

ExecStart=/opt/bin/docker-run.sh -p 3000:3000 --link mongo-ins:mongo -d --name node-app node-app node /NodeJS-Sample-App/EmployeeDB/app.js

ExecStop=/usr/bin/docker stop mongo-ins

[X-Fleet]

X-ConditionMachineOf=mongo.service

上面的两个 Unit 文件都使用到了一个 /opt/bin/docker-run.sh 脚本，用于替代 docker run 命令。这个脚本需要额外创建并放置到 /opt/bin 目录下面，其作用是检测是否已经有一个同名的容器在运行了，如果没有则执行相应的 docker run 命令，否则直接使用 docker start 命令启动已经存在的容器。其内容如下：

#!/bin/bash

PARA="${*}"

NAME=$(echo "${PARA}" | grep '/-/-name' | sed 's/.*--name /([^ ]*/).*//1/g')

if [ "${NAME}" == "" ]; then

echo "[ERROR] Must specify a name to the container!";

exit -1;

fi

EXIST=$(sudo docker ps -a | grep "${NAME}[ ]*$")

if [ "${EXIST}" == "" ]; then

sudo docker run ${PARA}

else

sudo docker start ${NAME}

fi

二、 启动服务

通过 fleetctl 命令启动服务，具体的用法在系列前面的内容里面已经介绍过了。

fleetctl start ./mongo.service

这里为了简便直接用了 fleetctl start 命令，更推荐的启动服务方法请参考系列中关于Fleet的一篇。

到这一步，这个部署在容器中的服务已经可以使用了。从外部访问服务器的 3000 端口即可打开下面这个页面，并向MongoDB服务中的数据库中添加员工信息了。

• 管理容器运行状态

最后，再来看一些用于检测容器运行状态和日常管理的Docker命令。

一、查看运行日志

容器通过 -d 参数进入后台运行之后，其中服务输出的日志内容可以通过 docker logs 命令查看到。

$ docker logs mongo-ins

二、 容器实例列表

命令 docker ps 能够列出所有当前正在运行的容器的基本信息。

$ docker ps

CONTAINER ID  IMAGE  COMMAND  CREATED   STATUS  PORTS  NAMES

d9bba1bfc8be  mongo:2  "/entrypoint.sh"  4 minutes ago  Up 4 minutes  27017/tcp  mongo-ins

22de21d77174  node:0  "/bin/bash"  3 minutes ago  Up 5 minutes  node-app

...

三、 容器实例详情

使用 docker inspect 命令能够查看到指定一个容器的详细运行信息。

$ docker inspect mongo-ins{ ... }

四、备份和还原容器

简单的提一下，用来将现有的本地镜像打包备份和还原的命令是 docker save 和 docker load 。也可以直接将容器实例打包，相关命令是 docker export 和 docker import ，注意 import 之后会将备份的数据恢复成一个新的本地镜像，而不是容器实例。

这两个命令的使用可以 参考文档 。只额外说明一个问题，既然两种还原都会将备份的内容还原为容器，为什么需要两种还原命令呢？原因在于使用 save 和 export 生成的打包效果是不太一样的，简单说就是 export 生成的备份会丢弃所有的镜像分层结构，而 save 生成的备份不会。镜像分层结构有利于减少相似镜像本地存储所需的空间，细节可参考这篇文章。

以上介绍的这些命令仅仅是Docker强大功能的冰山一角，网络上已经有许多十分优秀的Docker使用教程，作为学习Docker和应用容器都是极好的途径。这里推荐一个Dockerone翻译的 Docker系列文章 。

后话

事实上，随着CoreOS的独立容器项目 Rocket 的发起，Docker 在未来将不再是 CoreOS 和其他Linux操作系统设计容器方案的唯一选择。但作为 CoreOS 乃至整个 Linux 生态圈的应用容器服务佼佼者，Docker的王者地位还会持续很长的时间，而CoreOS始终会保持对Docker容器的一流支持（见CoreOS关于 Rocket博客中的F&Q ）。

正值提笔写这篇文章的那天，Bing的首页内容是泰国的曼谷港，这幅画面与Docker的Logo颇有几分神似。如此的巧合，使人不由的联想，这艘万吨货轮底下是否也正藏着一只蓄势待发的蓝鲸呢。

在这一篇内容中，将重点放在了使用Docker容器管理服务的介绍，正如文章中已经指出的，例子中的有些实践（使用docker commit创建镜像，以及fleet start直接启动服务等）并不适合在实际的项目中使用。从下下篇的文章起，我们将讲解几个完整的，符合产品应用的例子。在进入正式的综合实例前，在下一篇中，会对 Systemd 和 Fleet 使用的 Unit 文件做一个更深入的探索。（作者/林帆 责编/周小璐）

系列链接：

漫步云端：CoreOS实践指南（一）

CoreOS实践指南（二）：架设CoreOS集群

CoreOS实践指南（三）：系统服务管家Systemd

CoreOS实践指南（四）：集群的指挥所Fleet

CoreOS实践指南（五）：分布式数据存储Etcd（上）

CoreOS实践指南（六）：分布式数据存储Etcd（下）

如需要了解更多Docker相关的资讯或是技术文档可访问Docker技术社区；如有更多的疑问请在Dcoker技术论坛提出，我们会邀请专家回答。CSDN Docker技术交流QQ群：303806405。