Docker＆持续交付部署类型

女主宣言

不知道大家在平时部署项目的时候，是采用什么方式来持续部署的呢。在本篇文章中，女主就给大家整理了一下，普遍使用的几种持续交付部署方式。以及各种方式的优缺点，供大家参考使用。

PS：丰富的一线技术、多元化的表现形式，尽在“HULK一线技术杂谈”，点关注哦！

我们发现如果想要使团队更高效，应该使用Docker来实现持续交付(CD)。CD可以使用多种部署方法实现，Docker只是帮助实现必要的“基于工作流”的集成/构建过程的一个工具。

持续交付部署类型

现在，我们将研究这四种主要的部署类型，并概述它们的优缺点。

它们分别是：

最小服务内部署

滚动应用更新

蓝 / 绿部署

A / B测试

这四种部署类型分为两类：应用程序和基础设施部署。

1

最小服务内部署

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

例如：如果我们有5个容器，每个容器运行我们当前的应用程序A，那么我们设置我们的策略以保持最小服务中数为2。我们使3个服务器脱机，以将它们更新到我们的新版本B。一旦这些完成并返回在线，我们可以更新剩下的2个。

缺点：

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

对于基础设施的变化，效果不好

在正在运行的服务器上进行更改，如果发生故障，需要时间恢复

优点：

运动部件少，意味着测试能力的提高；在过程中进行应用程序和代码更改

没有宕机和额外的基础设施成本

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

2

滚动应用更新

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

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

Docker Swarm支持滚动更新。 默认情况下是一次更新一个容器。 要修改这个，使用-update-parallelism设置

缺点：

Docker滚动更新以两种方式处理失败：

通过暂停，允许干预并回滚修复

或继续不管，这意味着可能不会在容器运行时发现问题

比最小服务内部署更复杂

在部署时间方面可能是效率最低的; 基于每个阶段更新的时间

我们再次推荐Swarm之外的协调和健康检查

优点：

不需要停机

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

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

3

蓝 / 绿部署

当遵循蓝/绿（又名红/黑）方法时，我们短时间复制我们的“整个”基础平台。复制的基础平台托管新的应用程序，而旧的基础平台继续运行，直到测试完成并采用新的堆栈。 实现这一目标的能力已经存在了很长一段时间，但在云之前，这是一个非常昂贵的部署方法。现在，我们可以将堆栈部署到一个全新的环境中，从而实现独立的评估，并以最低的成本感谢Cloud。一旦测试完成，我们将应用程序切换到新版本并关闭旧版堆栈。

如图所示，蓝色表示您当前的环境版本，而您要部署的新变体是绿色。通常，这发生在DNS更改的形式，尽管您也可以通过修改Auto Scaling组来部署Blue / Green。

缺点：

需要高级编排工具

一些数据库是必要的风险

产生了一些额外的成本，虽然仅在短时间内

非自然的用户流量会使您的服务器泛滥，这不是一切破坏的要点

优点：

由于基础设施变得不可变，所以降低了风险

提供接近零停机时间

使用DNS更改时，切换是干净可控的

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

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

4

A / B 测试

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

缺点：

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

更加复杂

需要一切完全自动化

非自然的用户流量会使您的服务器泛滥，这不是一切破坏的要点

优点：

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

我们可以预测规模能力和预热作业

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

我们获得客户验证，同时减轻爆炸影响和广泛的错误

总结

对于以上的部署方式的选择，归结为最适合你的业务和技术需求的方法才是最好的。如果这对您的应用程序和用户群体是有意义的，我们强烈建议尽可能利用A / B测试。