Docker和持续交付部署类型

在本篇博文的姊妹篇《五步走战略建立良好的持续交付流程》中，我们看到了高性能IT团队如何采用Docker来实现持续交付（CD）的最佳实践。其中，CD可以通过大量的部署方法实现，而Docker只是帮助实现必要的可定制的“基于工作流”的集成/构建过程的一种工具而已。

持续交付部署类型

下面，我们就四种主要的部署类型，来聊一聊它们各自的优缺点。

服务内最小部署

应用程序滚动部署

蓝/绿部署

A / B测试

这四种部署类型又可分为两个子类别：应用程序和基础架构部署。

服务内最小部署

通过这种方法，我们指定了在更新剩余百分比的同时保持在服务状态的应用程序中的最小实例数，因此可以部署到尽可能多的目标。重复此过程，直到所有服务器都更新为新版本。

例如：如果我们有5个容器，每个容器运行我们当前的应用程序A，那么我们设置我们的策略以保持继续提供服务的数量最小为2。我们使3个服务器离线，以将它们更新到我们的新版本B。一旦这些完成并正常对外提供服务，我们就可以更新剩下的2个了。

缺点

这个过程存在多个阶段，所以需要以Swarm之外的监控和健康检查的形式进行支持

对于基础设施发生变化的情况下，效果不好

对正在运行的服务器进行更改——万一发生故障，恢复时间可能会很长

优点

组件更新少，意味着可测性的提高；在正常提供服务的过程中进行应用程序和代码更改

无需停服务，没有额外的基础设施成本

这个过程通常比滚动部署更快（见下面）

滚动部署

考虑将滚动部署作为最小服务内容的扩展。但是，我们并没有定义应该保持联机状态的容器数量，而是指定最大数量的容器进行更新。

例如：我们有和前面一样的5个容器，但是这次我们通过指定可以同时更新的容器的数量来初始化滚动更新，例如2个。这个过程一次移动两个容器的更新，直到集群中的所有服务器被更新。

注意：Docker Swarm支持滚动更新。默认情况下是一次更新一个容器。也可以自定义，使用 -update-parallelism参数设置即可。

缺点

Docker滚动更新有两种方式来处理部署过程失败的情况：

通过暂停，允许人为介入并回滚修复

或忽略报错继续执行，这意味着你可能错过在容器运行过程中出现的问题

比服务中最小部署（见上面）更复杂

在部署时间方面可能是效率最低的；时间长短取决于每个阶段更新的时间

我再次推荐Swarm之外的监控和健康检查

优点

不用停机

可以暂停，允许有限的多版本测试

允许进行自动化测试——在继续之前评估部署目标

蓝/绿部署

当遵循蓝/绿（又名红/黑）方法时，我们短时间复制我们的“整个”基础设施。复制的基础架构托管新的应用程序，而旧的基础架构继续运行，直到测试完成并切到新的系统。这种部署方式已经存在很长一段时间，但在云之前，这是一个非常昂贵的部署方法。现在，我们可以将系统部署到一个全新的环境中，从而实现独立的评估，并且由于Cloud的原因，成本也将大大降低。一旦测试完成，我们将应用程序切换到新版本并关闭旧版系统。

如图所示，蓝色表示你当前的环境版本，而你要部署的新变体是“绿色”。通常，蓝绿切换源于DNS的更改，尽管你也可以通过修改Auto Scaling来部署Blue / Green。

缺点

需要高级编排工具

就像数据库一样风险是存在的

在短时间内会产生一些额外的成本

非自然的用户流量会使你的服务器不稳定，这也是一个风险点

优点

由于基础设施不动，所以降低了风险

接近零停机，无需停服务

使用DNS更改时，交换机是干净的并受控制的

过程是完全自动化的，并提供一个更好的验证窗口

在切换之前可以测试整个环境的健康和性能

A / B测试

A / B部署与Blue / Green几乎完全相同，但是在这种方法中，我们只将少部分流量发送到我们的新环境（绿色）。这种方法能够切换环境，同时改变基础设施，但比Blue / Green部署更精确。

缺点

与前述的部署方法相比，需要移动很多部件

更复杂，风险更高

需要完全自动化一切操作

优点

蓝/绿部署的所有好处，plus：

我们可以提前预知规模和在生产中进行灰度发布

用来测试新功能并逐步评估性能，稳定性和健康状况

方便获得客户反馈，同时减少致命的影响和低级的错误

综上所述，那生产上选择哪种部署方法最合适呢？这取决于哪种方法最适合你的业务和技术需求。如果你的应用程序对用户群强依赖，我们强烈建议尽可能利用A / B测试。

如果你希望将整个过程自动化，那么我们希望邀请你查看我们的SaaS平台Caylent，以便在你的云中部署应用程序（如WordPress）。我们的DevOps容器管理系统可以自动完成上面说的整个流程以及更多你需要的。