使用Docker Stack部署应用( 三 ) _Docker

该服务还在deploy关键字下定义了部署约束。这样保证了当前服务只会运行在Swarm集群的worker节点之上。
deploy:placement:constraints:- 'node.role == worker'部署约束是一种拓扑感知定时任务，是一种很好的优化调度选择的方式。Swarm目前允许通过如下几种方式进行调度。

节点ID，如node.id==o2p4kw2uuw2a 。
节点名称，如node.hostname==wrk-12 。
节点角色，如node.role!=manager 。
节点引擎标签，如engine.labels.operatingsystem==ubuntu16.04 。
节点自定义标签，如node.labels.zone==prod1 。

注意==和!=操作符均支持。
（3）appserver服务
appserver服务使用了一个镜像，连接到3个网络，并且挂载了一个密钥。此外appserver服务还在deploy关键字下引入了一些额外的特性。

appserver:image: dockersamples/atsea_appnetworks:- front-tier- back-tier- paymentdeploy:replicas: 2update_config:parallelism: 2failure_action: rollbackplacement:constraints:- 'node.role == worker'restart_policy:condition: on-failuredelay: 5smax_attempts: 3window: 120ssecrets:- postgres_password

接下来进一步了解deploy关键字中新增的内容。
首先，services.appserver.deploy.replicas = 2设置期望服务的副本数量为2 。缺省情况下，默认值为1 。如果服务正在运行，并且需要修改副本数，则读者需要显示声明该值。这意味着需要更新stack文件中的services.appserver.deploy.replicas，设置一个新值，然后重新部署当前stack 。后面会进行具体展示，但是重新部署stack并不会影响那些没有改动的服务。
services.appserver.deploy.update_config定义了Docker在服务滚动升级的时候具体如何操作。对于当前服务，Docker每次会更新两个副本（parallelism），并且在升级失败后自动回滚。回滚会基于之前的服务定义启动新的副本。failure_action的默认操作是pause，会在服务升级失败后阻止其他副本的升级。failure_action还支持continue 。
update_config:parallelism: 2failure_action: rollbackservices.appserver.deploy.restart-policy定义了Swarm针对容器异常退出的重启策略。当前服务的重启策略是，如果某个副本以非0返回值退出（condition: onfailure），会立即重启当前副本。重启最多重试3次，每次都会等待至多120s来检测是否启动成功。每次重启的间隔是5s 。
restart_policy:condition: on-failuredelay: 5smax_attempts: 3window: 120s（4）visualizer服务
visualizer服务中指定了镜像，定义了端口映射规则、更新配置以及部署约束。此外还挂载了一个指定卷，并且定义了容器的优雅停止方式。

visualizer:image: dockersamples/visualizer:stableports:- "8001:8080"stop_grace_period: 1m30svolumes:- "/var/run/docker.sock:/var/run/docker.sock"deploy:update_config:failure_action: rollbackplacement:constraints:- 'node.role == manager'

当Docker停止某个容器的时候，会给容器内部PID为1的进程发送SIGTERM信号。容器内PID为1的进程会有10s的优雅停止时间来执行一些清理操作。如果进程没有处理该信号，则10s后就会被SIGKILL信号强制结束。stop_grace_period属性可以调整默认为10s的优雅停止时长。
volumes关键字用于挂载提前创建的卷或者主机目录到某个服务副本当中。在本例中，会挂载Docker主机的/var/run/docker.sock目录到每个服务副本的/var/run/docker.sock路径。这意味着在服务副本中任何对/var/run/docker.sock的读写操作都会实际指向Docker主机的对应目录中。
/var/run/docker.sock恰巧是Docker提供的IPC套接字，Docker daemon通过该套接字对其他进程暴露其API终端。这意味着如果给某个容器访问该文件的权限，就是允许该容器接收全部的API终端，即等价于给予了容器查询和管理Docker daemon的能力。在大部分场景下这是决不允许的。但是，这是一个实验室环境中的示例应用。
该服务需要Docker套接字访问权限的原因是需要以图形化方式展示当前Swarm中服务。为了实现这个目标，当前服务需要能访问管理节点的Docker daemon 。为了确保能访问管理节点Docker daemon，当前服务通过部署约束的方式，强制服务副本只能部署在管理节点之上，同时将Docker套接字绑定挂载到每个服务副本中。绑定挂载如图14.3所示。