登录注册
最新博客
最新资源下载
微服务镜像化提测系列-基于Docker&Jenkins镜像自动化构建&部署实践
阿凡达2018-07-04 09:08
前言：
近几年，微服务浪潮从普及概念到广泛应用，速度惊人。这不但揭示了微服务架构在开发、部署、运维、发布的流程中发挥了积极有效的作用，更提醒了所有互联网人微服务在技术架构中的重要地位。
在一个大力实践微服务、应用微服务并同时提供“微服务工具”的产品项目中，面对产品日益庞大的微服务集群，深深的体会到微服务对测试人员所带来的技术挑战，举个例子：当产品只有各位数应用的时候，我们依然可以按照老办法部署、管理、测试代码和持续集成的pipeline；但当产品的微服务数量上升到几十个的时候，这些日常的测试工作就会变得十分繁重。
因此，如何高效分配、部署、管理测试环境机器？如何管理微服务应用？如何做微服务功能测试？如何敏捷完成自动化、持续集成？等等，这些问题跟随着微服务化的深入，渐渐变的紧迫起来。
本文为大家介绍微服务测试的一角：镜像化提测结合Jenkins做容器镜像的自动化构建和测试环境部署的实践。
查阅下面的内容建议可以先看下晓晴阿姨之前的佳作，了解下微服务和镜像化提测的背景
那么为什么要镜像化提测？
首先我们来看下为什么要镜像化提测。
回顾下老的环境部署和提测方式：
从上图可以看到：
1. 开发和QA要分别进行代码构建部署对应环境执行测试
2. 提交测试后开发分支可能已经有了新提交的代码（这里我们指的是多模块集成开发的功能）
这个流程针对于单体或少数应用时并没有太大的问题，但是当应用集群比较庞大，提测功能通常依赖多个模块时， 单纯一个很基础的代码构建操作时间就会长的惊人，如果在部署测试环境时又遇到了一些配置、编译错误或者缺陷时，那么测试人员在准备测试阶段所花费的时间就会指数增加。
那么当测试、生产环境微服务容器化后，构建代码和部署环境演变成了构建容器镜像和启动容器，按着这个思路，提交测试就可以按着容器的粒度进行了，这样可以带来几个好处：
1. 减少重复构建镜像的时间
2. 提交测试的产物实例化，更好的便于版本的测试结果管理
结合Jenkins&Kubernetes开展镜像化的持续集成流程
确立了镜像化提测的方式，持续集成的开展模式也基于这个思路。预告下整体流程：
相比传统的CI流程，有如下结果变化：
1. 新增了镜像构建环节
2. 原有的部署环境JOB职责变为了通过Kubernetes OpenAPI做容器化的环境部署（Kubernetes是自动部署、扩展和管理容器化应用程序的开放工具，这里不做详解了）
逐一来看下这两步是如何实现的：
一、自动化构建镜像
按照倒叙的思路来看下Jenkins Job里面怎么实现：首先通过执行一个构建镜像脚本将单体微服务的镜像构建出来并在文件中存储镜像地址，最终通过变量传递给部署Job
1. 构建镜像脚本
2. JenkinsJob间传递变量
这里我们采用的是profile方式
- 静态代码检查job里配置环境、项目代码信息（如果只用与部署环境可以再构建Job中设置）
- JenkinsShell中写入变量到profile.txt文件，并在构建后传递变量
二、自动化部署容器测试环境
同样部署环境依然通过脚本来部署，但这里要引入前面提到的容器集群管理工具-Kubernetes：
简单的说K8S通过yaml文件来配置副本，从而管理容器实例，K8S提供了丰富的API，我们可以通过调用接口来更新副本从而实现容器的更新操作。
在Jenkins中执行以下内容完成整部署流程：
总结
整个流程依赖于容器化的环境，本文只举例了单体微服务的部署，所以可以看出适用的项目不局限与高度微服务化的产品。
虽然初步实践了容器化持续集成，但对于镜像化提测依然有很多挑战：如何管理镜像，自动化管理镜像测试结果，发布镜像，等等。 有机会继续分享后续进展，同时欢迎感兴趣的同学一起交流，分享经验。
本文来自网易实践者社区，经作者张雨授权发布。
分享至：
