示范持续交付步骤：微服务运维实战

现在已经知道持续交付流程所需的所有步骤，每个步骤我们都至少做了一次。在第1章中介绍了其中的一些。毕竟，持续交付是“扩展的”持续集成，或者是目标明确的持续集成。

我们在之前的章节中运行了这些步骤，知道了如何创建，更重要的是如何更新Swarm集群内的服务，这里不再赘述。可以把这一节当成到目前为止所有内容的一个回顾。

首先检出用于持续交付流程的服务的代码：

接下来，运行单元测试并编译服务的二进制文件：

请注意，这里使用了swarm-test-1节点。尽管它属于Swarm集群，但我们在“传统”模式下使用它（见图5-5）。

图5-5　在swarm-test-1节点中运行单元测试

编译完成之后，可以构建Docker镜像（见图5-6）：

图5-6　在swarm-test-1节点中运行构建

在构建好镜像之后，可以运行预备性的依赖和功能测试（见图5-7），并在完成后销毁所有内容：

图5-7　在Swarm-test-1节点中运行预备或功能测试

现在确信新版本应该会按预期工作，可以将镜像推送到注册表中：

我们运行了单元测试，构建了二进制文件，构建了镜像，执行了功能测试，并将这些镜像推送到了注册表中。一方面，这个版本很可能按预期工作，但是检验的唯一标准是该版本是否在生产环境中正常工作。没有比这更可靠或有价值的标准了。另一方面，我们希望能够放心地进入生产环境。可以通过使用在合理范围内尽可能接近生产环境的swarm-test集群来平衡这两个需求。

现在，go-demo服务在swarm-test集群中运行1.0版本。下面可以通过观察service ps命令的输出来确认：

输出如下（为简洁起见，删除了ID）：

让我们将当前运行的版本更新到刚刚构建的1.1版本中：

请注意，该服务最初是使用--update-delay 5s参数创建的。这意味着每个更新将在每个副本集上持续5秒（再加上几分钟以拉取镜像并初始化容器）。

稍等片刻（约6秒）后，service ps命令的输出应如下所示（为简洁起见，删除了ID）：

如果你笔记本电脑上的输出跟上面不一样，请稍等片刻，然后再次执行service ps命令。

如你所见，镜像更改为localhost：5000/go-demo：1.1，表示新版本确实已启动并正在运行。

请注意，由于该服务是使用--constraint 'node.labels.env==prod-like'参数创建的，新版本仍然只在标记为prod-like的节点中运行（见图5-8）。这显示出Docker Swarm提供的最大优势之一。我们使用定义其完整行为的所有参数创建服务，从那之后，所要做的就是更新每个版本的镜像。当开始执行缩放和其他一些操作时，事情会变得更加复杂。但是，逻辑基本上是一样的。我们需要的大部分参数只要通过服务创建命令定义一次。

图5-8　更新了CD集群中prod-like节点内部的服务

现在准备运行一些生产测试，我们对在生产环境运行这些仍然没有足够的信心，首先想看看测试是否能够在类似生产集群中执行通过。

将要运行的生产测试和之前运行的其他类型的测试没什么区别，Docker客户端仍然指向swarm-test-1节点，因此，我们使用Docker Compose运行的任何内容都将继续在该服务器内执行。

让我们快速查看下docker-compose-test-local.yml文件中定义的production服务（https：//github．com/vfarcic/go-demo/blob/master/docker-compose-test-local.yml）：

production服务扩展了unit服务。这意味着它继承了unit服务的所有属性，使得我们免于重复自己。

接下来，添加环境变量HOST_IP，将要运行的测试会使用该变量来推断被go-demo测试的服务的地址。(www.xing528.com)

最后覆盖unit服务中使用的命令。新命令下载go依赖关系go get-d-v-t并执行标记为integration的所有测试go test-tags integration-v。现在来看看这个服务是否确实可以在swarm-test集群中运行：

指定被测服务的IP为localhost。由于运行测试的节点swarm-test-1属于集群，因此ingress网络将请求转发给代理服务，然后代理服务再转发给go-demo服务。

输出的最后一行如下：

所有的集成测试都通过了，整个过程花了不到0.2秒（见图5-9）。

图5-9　在CD集群中更新之后的服务上运行生产测试

从现在开始，我们基本上可以确信发布版本已准备好投入生产。我们运行了部署前的单元测试，构建了镜像，运行了预备测试，更新了类似生产集群，并运行了一系列集成测试。

持续交付步骤已正式完成，发布已准备就绪，只等有人决定更新生产中运行的服务。换句话说，此时持续交付已完成，只等待有人按下按钮以更新生产集群中的服务。

没有理由止步于此，我们拥有将此过程从持续交付转换为持续部署所需的全部知识，所要做的就是重复生产集群内的最后几条命令。