jenkins持续集成DevOPS程序员

基于Jenkins的项目持续交付实践分享

2019-10-29  本文已影响0人  Here魏Go

摘要

部门项目由于需要管理多个服务,同时服务依赖的基础环境较为复杂,导致项目工程管理起来比较负责。所以采用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分钟左右。

这套流程还在改进中,也希望感兴趣的同学一起学习交流。

上一篇下一篇

猜你喜欢

热点阅读