自动化持续部署的三种反模式及解决方案(1)
2016-02-20 19:33:43   来源： 老王 互联网运维杂谈    评论：0 点击：

一旦将应用程序部署到了试运行环境，我们常常会发现新的缺陷。遗憾的是，我们常常没有时间修复所有问题，因为最后期限马上就到了，而且项目进行到这个阶段时，推迟发布日期是不能被人接受的。所以，大多数严重缺陷被匆忙修复，而为了安全起见，项目经理会保存一份已知缺陷列表，可是当下一次发布开始时，这些缺陷的优先级还是常常被排得很低。

有的时候，情况会比这还糟，以下这些事情会使与发布相关的问题恶化：

◆假如一个应用程序是全新开发的，那么第一次将它部署到试运行环境时，可能会非常棘手。

◆发布周期越长，开发团队在部署前作出错误假设的时间就越长，修复这些问题的时间也就越长。

◆交付过程被划分到开发、DBA、运维、测试等部门的那些大型组织中，各部门之间的协作成本可能会非常高，有时甚至会将发布过程拖上“地狱列车”。此时为了完成某个部署任务(更糟糕的情况是为了解决部署过程中出现的问题)，开发人员、测试人员和运维人员总是高举着问题单(不断地互发电子邮件)。

◆开发环境与生产环境差异性越大，开发过程中所做的那些假设与现实之间的差距就越大。虽然很难量化，但我敢说，如果在Windows系统上开发软件，而最终要部署在Solaris集群上，那么你会遇到很多意想不到的事情。

◆如果应用程序是由用户自行安装的(你可能没有太多权限来对用户的环境进行操作)，或者其中的某些组件不在企业控制范围之内，此时可能需要很多额外的测试工作。

三、反模式3：生产环境的手工配置管理

很多组织通过专门的运维团队来管理生产环境的配置。如果需要修改一些东西，比如修改数据库的连接配置或者增加应用服务器线程池中的线程数，就由这个团队登录到生产服务器上进行手工修改。如果把这样一个修改记录下来，那么就相当于是变更管理数据库中的一条记录了。这种反模式的特征如下：

◆多次部署到试运行环境都非常成功，但当部署到生产环境时就失败。

◆集群中各节点的行为有所不同。例如，与其他节点相比，某个节点所承担的负载少一些，或者处理请求的时间花得多一些。

◆运维团队需要较长时间为每次发布准备环境。

◆系统无法回滚到之前部署的某个配置，这些配置包括操作系统、应用服务器、关系型数据库管理系统、Web服务器或其他基础设施设置。

◆不知道从什么时候起，集群中的某些服务器所用的操作系统、第三方基础设施、依赖库的版本或补丁级别就不同了。

◆直接修改生产环境上的配置来改变系统配置。

运维的关键实践之一就是配置管理，其责任之一就是让你能够重复地创建那些你开发的应用程序所依赖的每个基础设施。这意味着操作系统、补丁级别、操作系 统配置、应用程序所依赖的其他软件及其配置、基础设施的配置等都应该处于受控状态。你应该具有重建生产环境的能力，最好是能通过自动化的方式重建生产环境。

我们也应该有能力在部署出错时，通过同一个自动化过程将系统回滚到之前的版本。

四、问题的答案：自动化部署

实现一个完善的自动构建、部署、测试和发布系统。为了让这个系统能够良好运行下去，我们还帮助他们采用了一些必要的开发实践和技术(大系统做小/维服务/灰度能力等等)。如何使用部署流水线，将高度自动化的测试和部署以及全面的配置管理结合在一起，实现一键式软件发布。也就是说，只需要点击一下鼠标，就可以将软件部署到任何目标环境，包括开发环境、测试环境或生产环境。

——————以上观点摘自《持续交付》

见到的通行做法是三种：

1.自动化脚本来封装，用expect+ssh；

2.用配置管理工具来实现；

3.在Jenkins中写插件来实现。

但我依然觉得，这不是我要的可视化+自动化部署系统，一般都选择自己实现。

1.YY包部署系统

缺点：

A、对配置管理支持的不是很好

B、环境管理能力很弱

C、没有以应用维度进行管理

2.UC的持续部署系统

这是利用公司另外一个系统基础上修改过来的，支持了游戏业务的特殊发布场景，做了一些优化，但还是有一些缺点。

缺点：

A、应用程序和底层Agent的耦合太重，Agent的异常会影响应用程序的工作。

B、系统架构设计很复杂，涉及组件过多，基于CF修改过来的。

C、基于CF的PAAS平台每支持一种语言就要重新开发。

D、对于包的抽象能力不够，管理能力需要在Agent层封装。当然这个能力可以更上层实现，兼容各种操作场景。

3.新持续部署系统(doing)

基于包的全新抽象，支持各种语言；开放包的管理能力给用户，适应各种场景；支持对包/配置/环境的可视化管理；支持灰度，支持快速回滚....等等。

【编辑推荐】