Docker和持续交付部署类型

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

持续交付部署类型

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

服务内最小部署
应用程序滚动部署
蓝/绿部署
A / B测试

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

服务内最小部署

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

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

缺点

这个过程存在多个阶段，所以需要以Swarm之外的监控和健康检查的形式进行支持
对于基础设施发生变化的情况下，效果不好
对正在运行的服务器进行更改——万一发生故障，恢复时间可能会很长

优点

组件更新少，意味着可测性的提高；在正常提供服务的过程中进行应用程序和代码更改
无需停服务，没有额外的基础设施成本
这个过程通常比滚动部署更快（见下面）

滚动部署

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

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

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

缺点

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

通过暂停，允许人为介入并回滚修复
或忽略报错继续执行，这意味着你可能错过在容器运行过程中出现的问题

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

在部署时间方面可能是效率最低的；时间长短取决于每个阶段更新的时间
我再次推荐Swarm之外的监控和健康检查

优点

不用停机
可以暂停，允许有限的多版本测试
允许进行自动化测试——在继续之前评估部署目标

蓝/绿部署

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