DockOne微信分享(一零八):基于Jenkins和Kubernetes的CI工作流

  • 时间:
  • 浏览:0
  • 来源:uu快3IOS下载_uu快3app下载_和值

原文发布时间为:2017-03-01

而Kubernetes随着版本迭代的速率单位单位先要快,在容器圈内的热度也先要高,一块儿每次版本发布,所新增的功能然后断增加。做为当前主流的容器管理平台,其强大的能力太久在此多做介绍。

应用容器化和应用微服务化设计思考

容器化不导致 微服务化,传统单体应用可不上能否容器化,然后先要享受到容器化后带来的好处。微服务化也也有一定要容器化,应用拆解为微服务后,一样可不能否不利用容器然后通过传统的运维来完成系统构建和部署。当微服务化和容器化相结合事先,就能充分利用各方优势,带来了弹性伸缩,僵化 部署,易于扩展,技术兼容等优点。

大伙 在针对应用进行微服务化拆分的过程中,主要先考虑到的是功能点、控制对象、开发组的人员配置安排,产品路线图规划等。之类,针对现有开发组人员人数、分配和每每每每个人的技能熟练程度,就可不能否考虑到服务模块数量的控制,安排好服务模块开发小组;针对功能点和化远期产品规划,就可不能否将特定功能归纳到有有有有一个 服务模块中,并在版本开发迭代的过程中,通过扩展这种服务模块的能力,来完成产品功能的开发,不可能 暂时将主次功能整合在有有有有一个 模块中,随着功能增加或迭代开发,再进行进一步的模块拆分或拆解。对于模块开发的要求,不可能 使用了容器技术,对于开发语言或特定框架的选型,可不能否交给具体的模块开发人员。在团队内,大伙 不做强制要求,然后做建议要求,防止老出太久的技术栈,导致 后期的维护困难。在大伙 团队内,就只集中在一种后端开发语言的使用,相应的框架或主要的开发库,也也有相应然后明确的选泽。对于模块的API接口,使用REST,然后大慨按照成长期的句子的句子期期是什么是什么度模型LEVEL2提供API。

容器环境下的编译和单元测试

大伙 整个CI工作流的驱动,也有由Jenkins完成,然后使用了Jenkins Pipeline。第一,Pipeline可不能否更好的组合job内的stage,重复利用模块间相同的主次,然后随着开发僵化 度的增加来逐步增加扩展stage,实现更多所需的功能;第二,将Pipeline Groovy脚曾经源设置为源代码内,可不能否根据源代码功能点来控制流程,一块儿也完成了对脚本的版本管理。

不可能 有容器先要个工具,大伙 各个模块的编译环境,单元测试环境,也都放上了容器中。各个模块均可不能否安装自身模块的运行行态或环境要求,准备自身的编译环境、单元测试环境、运行环境,然后,代码库内会分别留存相应的Dockerfile,通过不同的Dockerfile完成不同环境镜像的准备。一块儿,Jenkins现在可不上能否通过Docker Pipeline插件,支持在容器内运行step,然后大伙 利用其功能完成的实际的编译和测试流程是曾经的:

  1. 使用编译环境的Dockerfile构建编译环境镜像。
  2. 使用编译环境镜像启动容器并在容器内完成编译,完成编译的后面 产物也暂所处Workspace中。
  3. 使用测试环境的Dockerfile构件单元测试环境镜像。
  4. 使用单元测试环境镜像启动容器并在容器内运行单元测试,单元测试脚曾经源于代码库,一块儿也使用到编译时生成的后面 产物。
  5. 使用发布Dockerfile构建实际发布镜像并上传镜像库。
其中不可能 编译环境和单元测试环境也有一直变更,可不上能否抽出编译环境镜像准备和单元测试环境镜像准备有有有有一个 步骤放上独立的CI job中去,都要时手工触发即可。

服务部署和升级

对于CI流程,在完成编译和打包后,都要做的然后服务启动和测试了。大伙 利用的是Kubernetes Deployment和service,在每次CI流程完成编译和打包后,通过拿到Build号,作为镜像的tag,完成镜像的上传归档;一块儿利用tag,修改Kubernetes中不可能 创建的Deployment,利用Deployment的Rolling Update,完成升级。

测试脚本的来源,主次是从各模块代码库中,由各模块开发人员提交的针对自身模块的API测试,主次是由测试人员完成撰写提交的针对跨模块的测试。针对自动化测试这块,大伙 的完成度并也有很高,仅仅是搭建起了基本的运行框架,可不能否与整个流程对接上。

版本发布

不可能 开发的产品一种然后由若干镜像构成,然后产品发布,可不能否归结为镜像的发布。在测试通事先,可不能否简单的利用镜像基因重组能力,将测试通过的相关镜像的版本,通过镜像库间的基因重组,由开发测试所用的内部人员镜像库,基因重组到内部人员发布镜像库,就可不能否完成版本发布,一块儿可不能否通过基因重组时的tag控制,发布为指定的版本号。

对于Deployment升级所需的镜像tag修改,都要每次随着CI生成了新的镜像tag而做变更,因而每次都要修改相应yaml文件内的镜像tag,修改为实际CI流程中生成的值,然后再使用升级功能完成服务升级。针对那先 问题 ,大伙 使用了一套文本模板引擎,部署或升级用的yaml文件一种写成为模板,不可能 有变化不可能 都要根据CI流程变化的位置,使用模板标识占位,而具体的模板数据内容,则不可能 通过Jenkins的CI流程获取,不可能 使用特定的配置文件读取,不可能 从具体的输入参数来获取;一块儿,模板数据内容,也会在实际部署时,做为Kubernetes的Configmap设置到系统中,然后数据内容可不上能否通过Kubernetes使用Configmap的最好的方式来用到环境变量或启动命令中。通过文本模板引擎,将模板和数据合并后,生成的yaml文件,再作为后续Kubernetes操作所使用的内容。通过利用这种最好的方式,大伙 把都要部署的内容分离成了模板和配置;模板一般在服务架构,使用的镜像名,启动最好的方式或配置参数先要大的变化的情況下保持不变,而通过不同配置的灵活使用,完成服务升级或拉起新部署,完成不同数据存储使用的指向,完成对各模块内部人员配置的修改。通过利用这种最好的方式,大伙 的可修改的内容,从Configmap一种只有覆盖到的环境变量或启动命令这块,扩展到了启动名称、Label、镜像等YAML文件内的各个可填值处,以此来防止同名,镜像修改,Label增加或变更等各种使用Kubernetes时碰到的问题 。

自动化测试

在通过Jenkins拉动完成编译打包和服务升级部署后,就可不能否拉动自动化测试了。测试框架大伙 选泽了使用Robotframework。测试脚本通过Kubernetes service获取到服务的具体暴露端口,然后再根据测试脚本依次执行针对API的测试。

本文作者:黄文俊

以上内容根据2017年2月28日晚微信群分享内容埋点。分享人黄文俊,有容云资深系统架构师。主要负责容器云平台产品架构及设计,8年工作经验,有着企业级存储,云计算防止方案相关理解。关注于微服务设计思考,开发流程优化,Docker及Kubernetes技术在实际环境中的应用。 DockOne每周一定会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听语句题不可能 想分享语句题都可不能否给大伙 留言。

本文来自云栖社区媒体媒体合作伙伴Dockerone.io,了解相关信息可不能否关注Dockerone.io。

原文标题:DockOne微信分享(一零八):基于Jenkins和Kubernetes的CI工作流