基于Jenkins的项目持续交付实践分享
摘要
部门项目由于需要管理多个服务,同时服务依赖的基础环境较为复杂,导致项目工程管理起来比较负责。所以采用devops的方式进行工程项目管理,包括代码构建、自动化测试、镜像打包、部署等功能,实现自动化运维管理。
持续部署实践
主要涉及以下几个部分:
项目管理:分为代码管理(包含分支管理),镜像管理(含版本管理),配置管理(包含部署服务器、参数等管理)
DevOps:主要通过工具实现从集成、测试、构建到部署的流程,其工作流程如下:
1、持续集成,基于Bitbucket实现代码管理,包括代码分支开发管理、代码审计管理、代码构建等功能;
2、持续测试,基于jenkins、junit实现自动化测试;
3、持续构建,基于docker、harbor实现docker镜像的封装和docker镜像的管理;
4、持续部署,基于配置管理实现参数统一配置,并采用kubenetes实现自动化部署功能。
实现流程
通过Jenkins实现各环节的调度
【持续集成】
代码使用Bitbucket工具做管理,Bitbucket提供基于Pull Request的代码评审功能,在此将项目开发源码与配置文件都放在Bitbucket上做管理,每次构建时Jenkins会从配置文件库中拉取最新的配置文件,从代码库中拉取指定分支的代码,再执行后续的任务。
因为采用的开发语言为Golang,我们使用了Go自身的vendor功能做包依赖管理。所以这里不涉及如nexus等第三方包管理工具。
【持续测试】
项目采用beego框架,单元测试采用go test框架测试,集成测试调用独立的测试工程;
【持续构建】
在执行构建时,首先由Jenkins拉取最新的配置文件(包括需要部署到哪一个环境,项目中存在两套Kubernetes环境),根据选择的所要部署的不同的环境,生成不同的配置文件。采用Harbor开源工具做镜像管理,每次执行Dockfile生成的镜像会被推送到本地的镜像库。
【持续部署】
将容器配置通过ssh插件推送到远端的部署服务器(部署到哪一台服务器由上游job传参确定),在远程服务器中从镜像库中拉取镜像,执行yaml文件,启动pod。
逻辑架构
逻辑架构方面,分为代码管理、镜像管理、
代码管理--分支开发(采用分支开发,主干发布模式),配置文件仓库
镜像管理--主要负责镜像构建、上传、下载以及镜像的版本管理
部署管理--管理配置文件,如Dockerfile、yaml、bash等脚本文件。
部署路由--依据上游选择的环境不同,选择部署到不同的环境中,目前采用的是固定IP方式,下一阶段采用路由方式选择不同的部署环境。目前项目组中实现的是测试环境和开发环境的持续部署,由于生产环境相对独立,所以在客户提供的服务器或环境中采用半自动的方式部署,即镜像结合yaml文件部署。
技术架构
本次实践从技术架构层面,主要分为以下几个层面:
镜像管理:主要分为基础镜像管理(操作系统、基础环境依赖的软件),以及应用镜像:
部署平台镜像、管理平台镜像、浏览器平台镜像、Portal镜像,这四个镜像四个独立的应用模块。
实现架构
具体的代码实现,可以参考下下面的结构,项目中的所有涉及环境及配置相关的文体均在此统一管理维护。
部署方式如下图,整体通过Jenkins调度,两套K8s的master节点,一台Harbor服务器,部署通过Jenkins中的ssh插件方式推送,每次执行前通过选择所需要部署到的服务器点击构建执行,上游的job会将所要部署的服务器的IP传参到下游的job中,实现一键部署。
总结
目前项目中存在一套开发环境和一套测试环境,均可通过一键部署方式将最新的代码以pod方式部署到各自的环境中,也可手动执行,选择更新哪一个模块的代码,解决了人工部署可能出现的操作问题以及缩短了部署时间,目前从代码更新到应用运行使用仅需2分钟左右。
这套流程还在改进中,也希望感兴趣的同学一起学习交流。