一，简介
使用服务仍能够配置大多数熟悉的容器属性，比如容器名、端口映射、接入网络和镜像。此外还增加了额外的特性，比如可以声明应用服务的期望状态，将其告知 Docker 后，Docker 会负责进行服务的部署和管理。
举例说明，假如某应用有一个 Web 前端服务，该服务有相应的镜像。测试表明对于正常的流量来说 5 个实例可以应对。那么就可以将这一需求转换为一个服务，该服务声明了容器使用的镜像，并且服务应该总是有 5 个运行中的副本。
下面通过示例来看看如何创建刚刚描述的内容。
使用 docker service create 命令创建一个新的服务。
在 Windows 上创建新服务的命令也是一样的。然而本例中使用的是 Linux 镜像，它在 Windows 上并不能运行。请使用 Windows 的小伙伴将镜像替换为一个 Windows Web Server 的镜像，以便能正常运行。
二，创建服务
docker service create --name web-fe -p 8080:8080 --replicas 5 nigelpoulton/pluralsight-docker-ci
#replicas指定水平部署数量
需要注意的是，该命令与熟悉的 docker container run 命令的许多参数是相同的。这个例子中，使用 --name 和 -p 定义服务的方式，与单机启动容器的定义方式是一样的。
通过上面的命令和输出可以看出。使用 docker service creale 命令告知 Docker 正在声明一个新服务，并传递 --name 参数将其命名为 web-fe。将每个节点上的 8080 端口映射到服务副本内部的 8080 端口。接下来，使用 --replicas 参数告知 Docker 应该总是有 5 个此服务的副本。最后，告知 Docker 哪个镜像用于副本，重要的是，要了解所有的服务副本使用相同的镜像和配置。
敲击回车键之后，主管理节点会在 Swarm 中实例化 5 个副本，管理节点也会作为工作节点运行。相关各工作节点或管理节点会拉取镜像，然后启动一个运行在 8080 端口上的容器。
这还没有结束。所有的服务都会被 Swarm 持续监控，Swarm 会在后台进行轮训检查（Reconciliation Loop），来持续比较服务的实际状态和期望状态是否一致。如果一致，则无须任何额外操作；如果不一致，Swarm 会使其一致。换句话说，Swarm 会一直确保实际状态能够满足期望状态的要求。
举例说明，假如运行有 web-fe 副本的某个工作节点宕机了，则 web-fe 的实际状态从 5 个副本降为 4 个，从而不能满足期望状态的要求。Docker 变回启动一个新的 web-fe 副本来使实际状态与期望状态保持一致。这一特性功能强大，使得服务在面对节点宕机等问题时具有自愈能力。
三，查看服务
3.1访问服务实例
由于我们部署的实例遍布在三台主机中，到底用哪个主机访问呢？我们分别试下
http://192.168.1.50:8080/ http://192.168.1.51:8080/ http://192.168.1.52:8080/
发现都能正常访问。这是为什么呢？我们后面的文章再说。
3.1查看服务和实例
docker service ls
docker service ps web-fe
通过命令我们可以看到有worker1 运行了一个实例，worker2运行了两个实例，manager运行了两个实例。
3.2 修改实例数量（水平扩展）
扩展到10个实例
docker service scale web-fe=10
3.2 模拟实例挂掉
我们切换的51（worker1）查看有几个正在运行的实例我们找一个stop掉
切换回50（manager1）,因为worker节点不能执行管理命令
我们发现正在运行的实例仍然是10个，其中有一个是已经停止的，有一个是在一分钟内启动的。
这时候我们在去把之前的实例启动起来，切换到 51（worker1）
在切换到50（manager1）查看，发现仍然是10个实例
3.3 模拟主机挂掉
下面我们直接模拟一个worker节点挂掉,我们把51 (worker1)关机
切换到worker1，执行关机命令halt
切换到50（manager1）查看节点和实例
发现实例仍然是10个，节点处于了Down状态。
然后我们开机(恢复)，等待若干秒。启动中。。。启动完成。
发现节点已经启动，但是实例仍然在worker2和manager1上，manager上没有实例运行。
至此我们已经完成了服务构建和水平扩展。
