网站开发工程师和软件工程,德宏州乡城建设局网站,尚硅谷培训机构官网,创业网站搭建设计方案本文目录#xff1a; 一、背景 二、我们的需求是什么#xff1f; 三、概念澄清 四、概念模型 五、总体设计 六、关键点设计 七、总结 一、背景 说到自动化部署#xff0c;大家肯定都会想到一些配置管理工具#xff0c;像ansible,chef,puppet, saltstack等等。虽然这些工具给… 本文目录 一、背景 二、我们的需求是什么 三、概念澄清 四、概念模型 五、总体设计 六、关键点设计 七、总结 一、背景 说到自动化部署大家肯定都会想到一些配置管理工具像ansible,chef,puppet, saltstack等等。虽然这些工具给运维效率和安全性带来了很多好处。但是实际工作中我们还是会遇到一些问题 这些工具无法普及到开发、测试人员经常找运维帮忙无法自助 项目人员无法直观的参看到系统的部署架构设计及架构的演进过程 从物理架构设计到最终上线无法形成闭环 受差异性的基础设施影响较大。 二、我们的需求是什么 我们DevOps平台的部署模块就克服上面这些问题为实现DevOps以产品为核心以项目管理为驱动将需求、设计、交付、运维整个链路打通这一目标提供有力支持。具体来看其需求涵盖一下几点 将架构设计纳入DevOps管理过程中支持架构设计版本化 一次架构设计多次部署 以最佳实践为基础实现架构设计模版重用 多环境部署同时支持应用在虚拟机、容器上的部署 支持多种部署模式单机、高可用、部署策略全新、蓝绿、滚动升级、回滚 三、概念澄清 在正式讲解我们的设计之前我们想澄清CI/CD的基本概念因为本次的主题和持续集成、持续交付和持续部署这些名词总有些渊源。 1、什么是持续集成 持续集成Continuous Integration指的是频繁地将代码集成到主干以便快速发现错误、防止分支大幅度偏离主干。 持续集成的目的就是在产品快速迭代的同时保持代码质量它的核心措施主要有两点 1代码集成到主干之前必须通过自动化测试只要有一个测试用例失败就不能集成。 2通过Code Review、代码质量分析工具对代码质量进行把关以便确定是否能够集成。 Martin Flower说过 “持续集成并不能消除Bug而是让他们非常容易发现和改正。” 2、什么是持续交付 持续交付Continuous Delivery指的是新版本为了能够快速安全的交付到生产环境中需要将新版本先交付到类生产Production-like环境中如UATStagingLab环境以便进行相应的业务验证、安全验证、性能验证等过程。 一旦类生产环境验证通过新版本就进入到生产阶段。 持续交付可以看作是持续集成的进一步。它强调的是不管怎么更新软件是随时随地可以交付的。 3、什么是持续部署 持续部署Continuous Deployment指的是新版本通过类生产环境的验证后自动部署到生产环境中。 持续部署可以看成持续交付的进一步。持续部署的前提是自动化完成测试、构建、验证等步骤。 持续部署的目标是代码在任何时刻都可以进入自动地进入生产阶段为最终用户提供服务。 持续交付和持续部署的区别可以参考下图 点击可放大查看 从上图中我们可以看出 持续交付流程将自动的测试新版本应用但是否将新版本交付到生产环境中是一个手动过程。持续部署则是自动地将新版本交付到生产环境中去。 关于持续交付持续部署我们不能说哪一个是最好的方案。对于不同的组织适合的就是最好的。 4、什么是自动化部署 自动化部署Automatic Deployment指的是通过自动化工具将应用介质部署到指定环境中去。 自动化部署只是持续交付和持续部署流程中的一个功能单元。 自动化部署工具Ansible、Puppet、SaltStack等等。 通过以上概念的澄清我们了解了什么是持续集成、持续交付、持续部署以及自动化部署。 本文的主题不是介绍持续集成、持续交付、持续部署的Pipeline与实现而是介绍DevOps平台中在传统自动化部署工具之上的自动化部署框架的设计与实现。而自动化部署模块也是我们DevOps平台中的CI/CD的底层能力。 下面我们就来聊聊具体的设计。 四、概念模型 点击可放大查看 除了系统内置的一些模版概念我们将自动化部署流程分为三个阶段即设计、转换、运维。每个阶段都会有相应的基本模型。 下面我们分阶段的去解释一下这些概念模型。 1、设计阶段 设计Design是在装配Assembly内对应用/系统的架构的描述而应用/系统是由含有多个组件Component的系统Platform组成的。 Design阶段的基本流程 1创建装配Assembly 通过选择可用的系统模版(Platform Template)添加一个新的Platform 每一个Platform都对应一种应用如mysqltomcatspringbootnginx 每一个Platform都是有一组组件Component组成的并且已定义好了组件之间的依赖关系 在Assembly内用户可以通过设置Platform Link设置各个Platform之间的关系 2配置系统Platform内的组件Component的属性值 Component是最底层的部署或者配置单元如springboot中的secgroup, compute, os, jdk, fatjar, lb都是一个组件 每一个Component都有相应的配置模版 3提交设计 提交的过程是将已经完成的设计做一次Commit做一次归档。 2、转换阶段 转换Transition是在Assembly内对应用/系统在某一Environment内的部署过程。 Transition阶段的基本流程 1创建部署环境Deploy Environment 根据环境类型(如dev, test, prod等)添加属于某个Assembly的部署环境 部署之前部署环境是应用/系统用于部署的配置的抽象 部署之后部署环境就是管理和监控应用/系统的具体实例的集合 2配置部署环境 设置每个Platform关联的资源vm/container、部署模式单点高可用 3选择Assembly内的一个或多个Platform生成并提交执行计划 根据部署策略不同一个Platform的执行计划可能包含几个子计划 4执行部署 每个Assembly/Environment/Platform下面的每个Component都有一个instance这些instance可以进行单独Repair 3、运维阶段 运维Operation是在Assembly内对各个部署环境内Instances的管理和监控。 Operation阶段的基本任务 1组件实例运维例如 Compute: Status, Reboot, upgrade-os-security, powercycel, repair, upgrade-os-all Tomcat/Jboss: Status, Stop, Start, Restart, Repair, Debug Artifact: Repair, Redeploy, Custom User Attachment 2展现正在部署的操作有可能还会Replace或Cancel其中一项组件部署或整个部署 3展示Assembly某一Environment下的组件实例图谱 4日志查询 对基本的概念模型有了基本认识后我们来看一下自动化部署框架的总体思路。 五、总体思路 DevOps自动化部署框架采用DevOps平台设计Jenkins执行的方式完成。 DevOps的职责 完成部署架构设计 根据部署架构设计和部署环境的配置创建生成相应的执行计划及子执行计划每一个子计 划对应一个Jenkins pipeline job配置文件(config.xml) 查询Jenkins执行job的实时进度与结果。 Jenkins的职责 根据config.xml创建Jenkins Pipeline Job 执行pipeline job Jenkins job 通过pipeline script中ansibleopenshift命令进行相应的部署等执行操作 提供查询job执行情况的Rest API。 结合上面提到的三个阶段具体的流程如下所示 点击可放大查看 下面是具体的部署视图 点击可放大查看 看完整体思路和部署视图大家肯定会问为什么选择jenkins作为具体的执行引擎 首先jenkins支持master/slave架构能根据性能需求水平扩张slave又可以支持多种环境可以将不同的job分配到不同的slave节点。 还有非常重要的一点就是Jenkins Pipeline的能力。 Jenkins中pipeline的设计理念是实现基于groovy脚本灵活可扩展的工作流。 durable持久性在jenkins的master按计划和非计划的重启后pipeline的job仍然能够工作不受影响。 可暂停性pipeline基于groovy可以实现job的暂停和等待用户的输入或批准然后继续执行。 更灵活的并行执行更强的依赖控制通过groovy脚本可以实现stepstage间的并行执行和更复杂的相互依赖关系。 可扩展性通过groovy的编程更容易的扩展插件。 丰富插件Jenkins已经支持通过groovy命令调用git、maven、npm、gradle、shell、junit、sonarqube、ansible、docker、openshift、kubernetes等插件不需要我们再单独实现集成。 Rest APIJenkins提供通过Rest API的方式获取每一个stage的执行情况。 由于我们最终会将应用部署到虚拟机和容器云中虚拟机部署主要通过jenkins中提供的ansible插件jenkins pipeline script来实现容器云部署则根据具体的容器云通过openshift插件会有一定扩展或者http request插件jenkins pipeline script来实现。 下面我们来看一下Jenkins2的主要概念。 step, 其实跟jenkins1中的概念一样 是jenkins里job中的最小单位可以认为是一个脚本的调用和一个插件的调用。比如通过git拉取代码就是一个stepmvn clean package也是一个step一个http远程调用等等。 node, 是pipleline里groovy的一个概念node可以给定参数用来选择agentnode里的steps将会运行在node选择的agent上。这里与jenkins1的区别是一个 job里可以有多个node将job的steps按照需求运行在不同的机器上。例如一个job里有好几个测试集合需要同时运行在不同的机器上。 stage, 是pipeline里groovy里引入的一个虚拟的概念是一些step的集合通过stage我们可以将job的所有steps划分为不同的stage使得整个job像管道一样更容易维护。pipleline还有针对stage改进过的view使得监控更清楚。这里补充一句多个stage可以在一个node里定义及执行一个stage内的多个step可以分到不同的node上执行。 六、关键点设计 前面我们说的都是概念和流程上的东西那么用户该如何进行部署架构设计部署架构设计完成后如何提交呢 如何将提交的设计在具体的部署环境中转换成执行计划与子执行计划呢子计划又如何与jenkins pipeline job映射呢这就是我们下面要介绍的一些关键点设计。 1、模块化 点击可放大查看 前面提到当用户创建Platform时我们的DevOps平台提供可选的Platform TemplatePlatform Template定义了其中可以包含的组件类型(Component Template)等信息。也就是说我们的平台提供了一种基于最佳实践的方式帮助用户完成系统的架构设计。不仅如此通过对Platform Template/Component Template等相关数据准备的介绍也对以后用户扩展添加新的组件类型提供了充足依据。基本思路如下 1定义不同的系统模版Platform Template(见表DPS_DLV_PLATFORM_TEMPLATE)。系统模版就是我们通过最佳实践的方式提供了一套应用中间件系统的模版。如tomcatnginx、springboot、mysql等。 一个Platform Template定义了这个模版中包含的组件模版定义了组件模版之间的依赖关系(见表DPS_DLV_COM_RELATION_DEFINITION)以及每一种组件类型所在的层以及每一种组件类型允许添加的组件的个数(见表DPS_DLV_COMP_CONTAINER_DEFINITION)。当用户添加一个Platform时必须要选择一种Platform Template。 2根据不同的部署模式单节点、高可用、不同的目标资源虚拟机、容器、不同的部署策略全新、蓝绿、滚动升级、回滚一个系统模版会对应到多个执行计划模版 (见表DPS_DLV_PLATFORM_ACTION_PLAN_TEMPLATE)。 3一个系统由多个组件组成因此系统模版和组件模版之间也是多对多的关系。例如springboot模版对应的组件模版有secgroup模版、os模版、jdk模版、java application模版等等。 组件模版Component Template(见表DPS_DLV_COMP_TEMPLATE)以及组件的所有属性(见表DPS_DLV_COMP_ATTRIBUTE_DEFINITION)。组件模版就是组件的元数据为Platform添加的Component都是源于Component Template。 4为每个Component Template定义Operation模版(见表DPS_DLV_COMP_OPERATION)以便对单个组件实例进行操作如restart, repair, stop等。 通过以上4步系统预置的Platform Template和Component Template以及相应的数据就可以提供给用户添加一个Platform了。这些预置数据也为后面生成部署计划Deploy Plan做好的准备。 2、变量管理 在需求分析中我们就提出希望一次设计多次部署。但是在设计阶段设置各个组件属性时并不能确定在不同的部署环境中其值是一致的并且一个系统的不同组件的属性也可能是共用一个值。这时候我们就需要引入变量管理。变量管理的主要思路如下 1设计阶段为系统定义一些变量ConfigMeta并设置一个默认值如install_dir。然后在设置某个组件属性值时可以用P{install_dir}来表示。 2提交设计时也一同将变量定义作为设计的一部分进行提交。 3转换阶段在部署环境中为每一个变量设置当前环境下的值ConfigValue。当创建执行计划时会将属性P{install_dir}替换为当前环境的值。 不仅Platform内可以定义变量供该Platform下的Component使用我们也可以给Assembly定义变量供所有Platform及其组件使用, 形如A{assembly_var}。 3、设计提交 点击可放大查看 当用户设计完部署架构、设置每个组件属性及变量后需要将当前的设计指定好版本进行提交即归档。只有提交的设计才能在部署环境中获取的到指定的版本。通过版本化我们可以设计的不同版本做相关的对比。 上面的表结构是比较清晰的表述。 4、执行计划 根据不同的部署模式单节点、高可用、不同的目标资源虚拟机、容器、不同的部署策略全新、蓝绿、滚动升级、回滚一个系统模版会对应到多个执行计划模版并且计划模版之间有父子关系。 每一个子执行模版就是一个jenkins pipeline script模版。 当用户在部署环境中选择某个具体系统及部署策略生成相应的执行计划含子计划时每一个子计划的jenkins pipeline script就是将具体的组件属性注入到执行模版中生成的。 另外为什么需要显示的创建出子计划呢例如对于一个高可用的应用除了要部署具体的应用还需要更新load balance配置而这两者之间可能需要加入一些人工活动。所以我们通过显示的创建处子计划支持用户按子计划一步步的来做。 而jenkins pipeline script的stage几乎都对应到一个具体的组件具体可以看下图。 点击可放大查看 5、部署策略 前面我们提到了“部署策略”这个词除了全新部署我们常见的部署策略有蓝绿发布、滚动升级、灰度发布金丝雀发布、回滚。下面来看看我们的相应解决方案。每一种部署策略都会有相应的执行计划模版含子计划。 蓝绿发布 什么是蓝绿发布 在发布的过程中用户无感知服务的重启通常情况下是通过新旧版本并存的方式实现也就是说在发布的流程中新的版本和旧的版本是相互热备的通过切换路由权重的方式非0即100实现不同的应用的上线或者下线。 前提条件 双份资源 or 支持双端口模式 负载均衡服务 操作API接口 实施方案 第一步设置系统将要部署的资源列表。 第二步将新版本部署容器部署到资源列表中。 第三步调用负载均衡服务的API接口更新负责均衡配置。第四步更新资源的标签。 考虑到用户可能会手工介入确定是否需要更新负载配置我们会将第二步、第三步分为两个子执行计划。 滚动升级 什么是滚动升级 滚动发布一般是取出一个或者多个服务器停止服务执行更新并重新将其投入使用。周而复始直到集群中所有的实例都更新成新版本。 这种部署方式相对于蓝绿部署更加节约资源——它不需要运行两个集群、两倍的实例数。我们可以部分部署例如每次只取出集群的20%进行升级。 前提条件 负载均衡服务 操作API 接口 实施方案 第一步设置滚动升级系数步进如20%n个。 第二步依次将20%的部署容器移除负载然后在原资源处部署新版本然后加入负载。 灰度发布金丝雀发布 什么是灰度发布金丝雀发布 灰度发布是增量发布的一种类型它的执行方式是在原有软件生产版本可用的情况下同时部署一个新的版本。同时运行同一个软件产品的多个版本。 其实灰度发布是滚动升级的一种变体其实灰度发布是先划分出新版本的路由权重新版本在真实数据验证通过后在进行剩余老版本的升级。 前提条件 负载均衡服务 操作API 接口 实施方案 第一步设置新老版本的路由权重如90%的用户维持使用老版本10%的用户使用新版本。 第二步将10%的部署容器移除负载然后在原资源处部署新版本然后加入负载。 第三步待真实数据验证通过后再进行剩余老版本的滚动升级。 回滚 什么是回滚 回滚是指将应用服务回退到上一可用版本并使之可用。 我们暂时只支持针对蓝绿发布的回滚。 前提条件 新版本是基于蓝绿发布策略完成的部署。 负载均衡服务操作API接口。 实施方案 更新负载配置 七、总结 本文大致向大家介绍了我们的DevOps平台中自动化部署框架的相关设计主要简单介绍了实现思路和几个关键点。 其中还有很多细节比如如何与CMDB集成如何与各种容器云集成以及我们实践过程中遇到的各种坑等等这里不再一一赘述有问题可在本文文末留言。 转载于:https://www.cnblogs.com/jiahe/p/6729261.html
