在继续探索持续交付步骤之前，应该讨论一下Docker Swarm引入的部署上的变化。我们之前认为，每个版本都意味着一个新的部署，而Docker Swarm并非如此。在Docker Swarm中，我们是在更新服务，而不是在部署每个版本。在构建Docker镜像之后，所要做的就是更新已经运行的服务。大多数情况下，所有要做的就是运行docker service update--image <IMAGE> <SERVICE_NAME>命令。该服务已经拥有了它需要的所有信息，现在所要做的就是将镜像更改为新版本。
为了更新服务，得先有一个服务，我们需要创建它，并确保它有需要的所有信息。换句话说，我们只创建一次服务并用每个版本来更新服务，这样极大地简化了发布流程。
由于服务仅创建一次，因此，自动执行此步骤对我们而言投资回报率（ROI）太低。请记住，我们希望自动化多次执行的流程。仅做一次的事情不值得自动化，创建服务就是其中之一。我们仍然手动运行所有的命令，所以把它看成是第6章将会自动化整个过程的一个说明。
让我们创建构成go-demo应用程序的服务。我们需要proxy、go-demo服务和对应的数据库。和以前一样，必须创建go-demo和proxy网络。由于之前已经做过好几次，所以将通过scripts/dm-test-swarm-services.sh（https：//github．com/vfarcic/ cloud-provisioning/blob/master/scripts/dm-test-swarm-services.sh）脚本来执行所有命令。它以与以前几乎相同的方式创建服务，唯一的区别是这里用了prod-like标签来限制服务仅应用于类生产部署的节点，如图5-3所示。
service ls命令的输出如下（为简洁起见，删除了ID）：
图5-3 在标记为prod-like的节点上运行服务的集群
请注意，本地主机上的代理重新配置端口已设置为8090，我们必须将其与测试环境中运行go-demo服务时使用的端口8080区分开来。
一方面，我们希望类生产集群中的服务尽可能地与生产集群中的服务一致。另一方面，我们不希望浪费资源来复制整个生产环境。出于这个原因，我们运行proxy和去go-demo服务的两个实例（副本）。只运行一个服务实例的话，与生产环境中的服务应该能够缩放的思路偏离太远。每个服务两个副本让我们能够测试缩放服务是否能如预期的那样工作。即使我们在生产环境中运行更多的实例，两个也足以模拟缩放行为。由于我们仍然无法设置数据库副本，因此目前仅运行一个MongoDB实例。
可以通过向go-demo发送一个请求来确认所有的服务确实被成功创建和集成：
我们还会在生产集群中创建相同的服务，唯一的区别是副本的数量（会更多），并且不会对其进行限制（见图5-4）。由于这和之前做过的没有太大区别，我们将会使用scripts/dm-swarm-services.sh（https：//github．com/vfarcic/cloud-provisioning/blob/master/scripts/dm-swarm-services.sh）脚本来加快进度：
service ls的输出如下（为简洁起见，删除了ID）：(www.xing528.com)
图5-4 运行服务的CD和生产集群
既然已经在这两个集群中创建了服务，那么可以开始进行持续交付步骤了。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
