您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
持续交付流水线的敏捷利器:环境配置管理与应用部署自动化
 
   次浏览      
 2019-4-17 
 
编辑推荐:
本文来自于dbaplus.cn,文中主要讲解了传统环境配置管理存在的问题,以及具体的应用管理。

业界关于持续交付有如下图所示的5级能力成熟度模型:

今天我们就来聊聊持续交付流水线中的环境配置管理工作。

DevOps、持续交付、环境配置管理

持续交付作为DevOps的核心实践,涵盖了从开发到测试到部署上线的过程,是持续集成的延伸,持续交付流水线中涉及很多环节,而每个环节基本上都跟环境配置管理相关。

例如开发阶段的构建环境、联调环境、测试阶段的功能测试环境、性能测试环境、安全测试环境、兼容性测试环境,发布生产前的准生产部署环境等。

整个开发环境可分为本地开发环境,测试环境,准生产环境,生产环境。当产品通过了各种测试,例如: 功能测试,性能测试,系统测试等等,需要部署到准生产环境,其特点是与生产环境参数基本一致,在用户接受测试通过之后,可根据业务需求或决策部署在生产环境了。

传统模式下的环境配置管理问题

DevOps的目标是通过建立并不断完善持续交付的流水线,最终达到无需人工干预的持续交付过程。从代码开发到持续集成,创建测试环境,运行测试并报告结果,完成各种测试计划中任务,最后是业务决策交付或部署上线。

下图是一个典型的持续交付流水线,可以看到流水线经过了好几套环境的测试、验证,可见环境配置管理工作的重要性。

传统模式下的环境配置管理通常存在以下问题:

1、手工准备环境,对冲突无控制。

软件安装麻烦、来源不一致、安装方式不一致、杂乱无章。

共用一个服务器开发环境,隔离性差,互相冲突。

可移植性差,例如和生产环境不一致,开发人员之间也无法共享;新人入职通常又折腾一遍开发环境,无法快速搭建。

2、基础设施环境的准备工作繁琐,跨部门流程冗长

3、手工部署软件

部署和发布过程以及发布后的验证都依赖人工进行,容易出错,并且效率有待提升。

4、环境资源无法共享

环境资源缺乏动态调配能力,造成资源浪费。

环境配置管理与应用部署自动化

为了有效解决上述问题,提高持续交付流水线的效率,我们需要开展环境集中配置管理的工作。主要从以下几方面入手:

基础设施环境配置管理

基础设施(Infrastructure)代表了你所在组织中的所有环境,以及支持其运行的所有服务,如DNS服务器、防火墙、路由器、版本控制库、存储、监控应用、邮件服务器,等等。

基础设施管理的基本原则:

(1)使用保存于版本控制库中的配置信息来指定基础设施所处的状态;

(2)基础设施应该具有自治特性,即它应该自动地将自己设定为所需状态;

基础设施不但应该具有自治特性,而且应该是非常容易重新搭建的。当出现硬件或其它问题时,就能迅速重建一个全新的已知状态的环境配置。所以,基础设施的准备工作也应该是一个自动化过程。自动化的准备工作与自治性的维护相结合,可保证一旦出现问题就能在可预见的时间内重建基础设施。

(3)通过监测手段,应该每时每刻都能掌握基础设施的实时状况。

应该与交付流程的其它方面一样,把创建和维护基础设施需要的所有内容都进行版本控制:

(1)操作系统的安装定义项(例如使用Debian Preseed、RedHat Kickstart和Solaris Jumpstart)。

(2)数据中心自动化工具的配置信息,例如Puppet、CfEngine等。

(3)通用基础设施配置信息,例如DNS区域文件、DHCP和SMTP服务器配置文件、防火墙配置文件等。

(4)用于管理基础设施的所有脚本。

部署流水线的基础设施变更管理工作:

(1)对于任何基础设施的变更部署到生产环境之前,应该验证所有的应用程序在这些变更之后也能正常工作,并确保在该新版本的基础设施之上,所有受到影响的应用程序的功能和非功能测试都能成功通过。

(2)将这些变更应用到测试和生产环境上。

(3)流水线应该执行部署测试,确保新的基础设施配置已成功部署。

基础设施的版本配置管理工作还包括:

管理应用程序和应用程序所依赖的基础设施之间的版本依赖。也就是说,为了能够正常工作,就要记录每个应用程序需要哪个版本的基础设施。

应用部署与发布管理

良好的环境配置管理能为应用部署和发布创造高效的环境,而应用部署与发布工作本身也应该做集中化的配置管理工作。例如,制定完善的发布计划:

1、第一次部署应用程序时所需的步骤;

2、作为部署过程的一部分,如何对应用程序以及他所使用的服务进行冒烟测试;

3、如果部署出现问题,需要哪些步骤来撤销部署;

4、对应用程序的状态进行备份和恢复的步骤是什么;

5、在不破坏应用程序状态的前提下,升级应用程序所需要的步骤是什么;

6、日志文件放在哪里,以及他包含什么样的信息描述;

7、如何对应用程序进行监控;

8、作为发布的一部分,对必要的数据进行迁移的步骤有哪些;

9、前一次部署中存在问题的记录以及他们的解决方案是什么。

对发布过程进行建模并让构建晋级:

1、为了达到发布质量,一个构建版本要通过哪些测试阶段(例如集成测试、QA验收测试、用户验收测试、试运行以及生产环境)

2、每个阶段需要设置什么样的晋级门槛或需要什么样的签字许可。

3、对于每个晋级门槛来说,谁有权批准让某个构建通过该阶段。

最后,还需要建立高效的自动化部署机制:

每个需要部署应用程序的人都能用这种自动化部署机制,而不需要了解部署本身相关的任何技术知识,一旦部署完成后,自动运行一个冒烟测试来验证部署成功与否,这样,做应用部署操作的人(包括分析人员、测试人员或运维人员)就可以确认该系统运行正常,即使不能正常运行,也很容易找到原因。

1、选择需要部署的应用程序版本之后自动执行后续的部署步骤。

2、环境及相关基础设施的准备应该以完全自动化的方式进行。

3、部署应用程序的二进制包应该从制品库中拿到,而不是每次部署时重新构建出来。

4、对应用程序进行配置。应用程序的配置信息应该以某种统一的方式来管理,并在部署和运行时使用。

5、准备或迁移该应用程序所管理的数据。

6、对部署进行冒烟测试。

7、执行测试(可能是手工的,也可能是自动化的)

8、如果应用程序的这个构建版本通过了这些测试,允许其晋级到下一个环境中。

9、如果应用程序的这个构建版本没能通过这些测试,记录一下是什么原因。

小结

本文简述了传统环境配置管理存在的问题,以及在持续交付流水线工作模式下的环境配置管理的具体做法。

随着Puppet、Ansible、SaltStack,持续集成、持续交付、DevOps,Docker、开发测试云平台等技术和方法的日渐成熟和被企业所接受,相信越往后边,持续交付流水线的环境配置管理、应用部署管理工作将越自动化、敏捷化!

   
次浏览       
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试