江苏龙网

  1. 首页 > 人文 > >

对DevOps流水线设计的优化和改进实践( 二 )


因此我们还是重新回顾下我们建立的各个任务操作节点 。
对DevOps流水线设计的优化和改进实践文章插图
构建操作：构建我们通常采用Maven进行自动化构建 ， 构建完成输出一个或多个Jar包或War包 。
注：对于编译构建操作 ， 我们看到重点就是指定具体的git库和分支路径 ， 然后采用默认标准的maven构建方式进行编译构建 。 那么在这种方式下 ， 我们完全可以将类似Git库配置信息配置到具体的项目基本属性里面 ， 这样编译构建操作同样可以通用 。
注意常规方式下构建完执行进行部署操作 ， 部署操作一般就是将构建的结果拷贝到我们的测试环境服务器 ， 同时对初始化脚本进行启动等 。 而在DevOps下 ， 该操作会变成两个操作 ， 即一个打包 ， 一个部署 。 打包是将构建完成的内容制作为镜像 ， 部署是将镜像部署到具体的资源池和指定集群 。
打包操作：实际上即基于构建完成的部署包来生成镜像 。 该操作一般首先基于一个基础镜像文件基础上进行 ， 在基础镜像文件上拷贝和写入具体的部署包文件 ， 同时在启动相应的初始化脚本 。
那么首先要考虑构建操作和打包操作如何松耦合开 。
打包操作简单来就是就是一个镜像制作 ， 需要的是构建操作产生的输出 。 我们可以对其输出和需要拷贝的内容在构建的时候进行约定 。 而打包任务则是一个标准化的镜像制作任务 ， 我们需要考虑的仅仅是基于1）基于哪个基础镜像 2）中间件容器默认目录设置 3）初始化启动命令 。
即在实际的打包任务设计的时候 ， 我们不会指定具体的部署包和部署文件 ， 这个完全由编排的时候由上游输入 。
注：在前期流水线设计的时候 ， 为了考虑灵活性 ， 我们往往会对打包过程的脚本自定义完全放开 ， 包括基于哪个dockerfile制作镜像 ， 镜像制作过程中需要运行哪些指定的脚本文件 ， 进行哪些文件拷贝操作等 。 但是为了考虑灵活性 ， 这些都必须提前进行约定 ， 即打包操作中都统一调用一个标准命名的初始化脚本文件 。
部署操作：部署操作相当更加简单 ， 重点就是将镜像部署到哪个资源池 ， 哪个集群节点 ， 初始化的节点配置等 。 具体部署哪个镜像不要指定 ， 而是由上游任务节点输入 。
经过上面的思考 ， 我们希望达到一个目的就是我们会形成标准的任务操作节点 ， 完全适用于多个不同的微服务和应用项目 。 而不再需要针对每个项目都去建立不同的任务操作节点 。
比如对于部署操作 ， 我们如果有两种资源调度策略 ， 那么我们创建两个部署操作任务模板即可 。 对于打包操作 ， 我们根据不同的开发语言 ， 构建不同的打包操作模板即可 。
任务节点间松耦合设计的意义
这种松耦合设计才能够使流水线编排更加灵活 。
比如我们在进行了构建打包后 ， 我们希望同时将打包内容部署到开发环境和测试环境 。 那么则是打包动作完成后需要对接两个应用部署任务 。 这两个部署任务都依托上面的打包结果进行自动化部署 ， 可以并行进行 。
对于测试环境部署完成后 ， 我们需要进行测试人员手工验证测试 ， 如果测试通过 ， 我们打标签后希望能够直接发布到UAT环境 。 而这种操作我们也希望在一个流水线来设计和完成 。 这样我们更加容易在持续集成看板上看到整个版本构建和迁移的完整过程 。
如果这是在一个大流水线里面 ， 那么对于UAT环境部署更多只是一个镜像的迁移操作 ， 因此就需要一直去追溯流水线上的最近的一个打包任务节点 ， 同时取该任务节点产生的输出来进行相应的环境部署操作 。
在谈DevOps的时候 ， 一个重点就是和QA和QC的协同 ， 因此在流水线编排的时候一定要考虑各类测试节点 ， 包括静态代码检查 ， 自动化的单元测试 ， 人工的测试验证 。 同时最好基于持续集成实践 ， 能够将测试过程和整个自动化构建过程紧密结合起来 。


推荐阅读


上一篇：基于 kNN 特征扩增的多维分类

下一篇：长虹·美菱国羽荣光新品发布 110吋8K巨幕登陆观音桥苏宁