持续集成的容器化实践

阿凡达2018-07-09 11:14

前言

Docker技术的兴起,推动了很多技术的革新与发展.有我们熟知的微服务架构、DevOps(微服务的好基友)另外一个就是持续集成与持续交付的流程衍变.

对于持续集成的定义有很多种, 这里把它总结为:指开发人员将代码定期合入到中央仓库后触发的一系列构建、静态代码检查、 单元测试、 部署、接口测试等一系列构建或集成的行为。 主要目标是更快发现并解决缺陷,提高软件质量,并减少验证和发布新软件更新所需的时间

一. 传统持续集成的流程


从图中我们回顾一下传统的持续集成的流程:

  • 首先我们在事先搭建好的持续集成环境中配置好一系列的测试Jobs即pipeline;并且配置好测试的触发条件

    具体的测试任务内容会由于产品的形态和发展阶段进行定制, 举一个当前在使用的pipeline的内容: 静态代码检查->单元测试->测试环境部署->结果反馈和展示
    
  • 当开发小明提交了一次代码的时候, JenkinsMaster检测到代码的变更触发了测试

  • 当测试执行完毕之后将测试结果反馈给测试/开发/运维人员, 最终人为的去部署预发布或者线上环境

当前持续集成测试存在的问题

  • 部署环境的成本较高 (包含持续集成本身) 以持续集成环境搭建为例 已上面流程图中的持续集成环境搭建为例子, 我们可以看到搭建一套持续集成环境的必经步骤

  • 测试环境的不一致性相信我们遇到过同一个问题在测试同学发现并反馈到开发同学这里,很难复现.甚至需要开发和测试一起去定位排查问题,最终花费了很多时间结果是由于环境问题导致的.

  • 相对开发周期较长最终的直接影响就是导致开发周期变长

二. 持续集成的容器化实践

容器和微服务的发展, 让我们经常被问到微服务的测试要怎么做, 怎么样结合docker去做测试甚至是持续集成? 下面就跟大家分享下其中的一个实践: 

可以看到这个图与上面的图有哪些比较大的变化?

  1. 首先是持续集成的环境我们改为容器化部署(根据产品的情况我们可以将测试环境也实现容器化,这里就不举例了)
  2. 另外我们创建了一个支持持续集成功能的仓库

  3. 最后持续集成执行的测试结果不仅是一个result, 还有一个镜像形式的交付,这个镜像实际上是源码和环境的捆绑内容

再来看一下这个流程:

  • 还是这个小明提交了一次代码到git仓库,JenkinsMaster检测到代码的变更触发了测试
  • 同时这次代码的变更,触发了一次镜像的构建, 并将这个镜像保存到私有的镜像仓库中待部署.
  • 当测试执行完毕之后通过JenkinsFile(可以理解为pipeline as code进行的持续集成的一系列编排)根据测试结果判断是否将通过测试的镜像部署到预发布环境或者进行下一轮的测试

具体实现

这里以网易云基础服务提供的容器云为例直观的去理解

  1. 创建两个容器部署持续集成环境, 官方提供的镜像中已经预安装好了所需要的依赖和工具.只需要通过设置环境变量的方式使得Jenkins slave注册到master上面,部署持续集成的环境已简化为 
  2. 创建支持持续集成功能的镜像仓库,配置绑定git上的源码
  3. 在Jenkins上面创建pipeline选用pipeline script from SCM方式, 指定源代码路径下面上传好的Jenkinsfile

怎样通过Jenkinsfile来实现持续集成测试的编排呢

  1. 首先我们创建一个pipeline
  2. 填入开发源码git路径
  3. 选择触发方式,这里用的是Poll SCM每隔20分钟检查下代码仓库是否有新的提交
  4. 并填入JenkinsFile的路径(源码git目录下)
  5. JenkinsFile的持续集成编排内容 Jenkinsfile 是一种基于 Groovy 的 DSL,简单的来说我们通过Jenkinsfile中的不同阶段来定义我们的持续集成的pipeline的实现.大家可以通过这里进一步研究.

三. 容器化实践后的思考

1. 优点

容器化的实践不仅在资源上节省了开销,并且由于容器本身的优势为部署上也带来了便捷. 同时结合了网易云基础平台的持续集成镜像仓库及API等服务, 让容器化的交付成为了可能.一方面解决了部分由环境一致性带来的问题,同时也为持续集成的编排增加了更多的灵活性. 总结了一下主要有已下几点:

  • 节省资源
  • 版本的镜像化管理
  • 容器化交付
  • 更好的保证环境的一致性
  • 通过API脚本方式来编排CI/CD

2. 问题分析

持续集成在本次实践的过程中,我们借助了网易云的平台,并且同时引进了Jenkinsfile的pipeline编排方法.这对于传统的用户来说,迁移过程中需要有一定的时间去消化并解决实践过程中的种种问题,甚至在微服务化的过程中同时考虑微服务测试的难易程度做适当的调整;另外持续集成和持续交付在容器化的进程中还未达成一个明确的交付标准.这些都需要更多的开发者和测试同学去实践,从而积累更多的经验去总结得出.

  • CI容器化实践的成本
  • 持续集成/持续交付的流程标准化

本文来自网易实践者社区,经作者张雨授权发布。