DevOps平台中的自动化部署框架设计

转载本文需注明出处：微信公众号EAWorld，违者必究。

本文目录：

一、背景

二、我们的需求是什么？

三、概念澄清

四、概念模型

五、总体设计

六、关键点设计

七、总结

一、背景

说到自动化部署，大家肯定都会想到一些配置管理工具，像ansible,chef,puppet, saltstack等等。虽然这些工具给运维效率和安全性带来了很多好处。但是实际工作中，我们还是会遇到一些问题： 

• 这些工具无法普及到开发、测试人员，经常找运维帮忙，无法自助； 

• 项目人员无法直观的参看到系统的部署架构设计，及架构的演进过程； 

• 从物理架构设计到最终上线，无法形成闭环； 

• 受差异性的基础设施影响较大。

二、我们的需求是什么？

我们DevOps平台的部署模块就克服上面这些问题，为实现DevOps以产品为核心，以项目管理为驱动，将需求、设计、交付、运维整个链路打通这一目标提供有力支持。具体来看其需求涵盖一下几点： 

• 将架构设计纳入DevOps管理过程中，支持架构设计版本化； 

• 一次架构设计多次部署； 

• 以最佳实践为基础，实现架构设计模版重用； 

• 多环境部署，同时支持应用在虚拟机、容器上的部署； 

• 支持多种部署模式（单机、高可用）、部署策略（全新、蓝绿、滚动升级、回滚）

三、概念澄清

在正式讲解我们的设计之前，我们想澄清CI/CD的基本概念，因为本次的主题和持续集成、持续交付和持续部署这些名词总有些渊源。

1、什么是持续集成？

持续集成（Continuous Integration）指的是，频繁地将代码集成到主干，以便快速发现错误、防止分支大幅度偏离主干。 

持续集成的目的，就是在产品快速迭代的同时保持代码质量，它的核心措施主要有两点： 

1）代码集成到主干之前，必须通过自动化测试，只要有一个测试用例失败，就不能集成。 

2）通过Code Review、代码质量分析工具对代码质量进行把关，以便确定是否能够集成。

 

Martin Flower说过， “持续集成并不能消除Bug，而是让他们非常容易发现和改正。”

2、什么是持续交付？

持续交付（Continuous Delivery）指的是，新版本为了能够快速安全的交付到生产环境中，需要将新版本先交付到类生产（Production-like）环境中（如UAT／Staging／Lab环境），以便进行相应的业务验证、安全验证、性能验证等过程。 

一旦类生产环境验证通过，新版本就进入到生产阶段。 

持续交付可以看作是持续集成的进一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

3、什么是持续部署？

持续部署（Continuous Deployment）指的是，新版本通过类生产环境的验证后，自动部署到生产环境中。 

持续部署可以看成持续交付的进一步。持续部署的前提是自动化完成测试、构建、验证等步骤。 

持续部署的目标是，代码在任何时刻都可以进入自动地进入生产阶段，为最终用户提供服务。 

持续交付和持续部署的区别可以参考下图：