基于Jenkins的项目持续交付实践分享
摘要
部门项目由于需要管理多个服务，同时服务依赖的基础环境较为复杂，导致项目工程管理起来比较负责。所以采用devops的方式进行工程项目管理，包括代码构建、自动化测试、镜像打包、部署等功能，实现自动化运维管理。
持续部署实践
主要涉及以下几个部分：
项目管理：分为代码管理（包含分支管理），镜像管理（含版本管理），配置管理（包含部署服务器、参数等管理）
DevOps：主要通过工具实现从集成、测试、构建到部署的流程，其工作流程如下:
1、持续集成，基于gitlab实现代码管理，包括代码分支开发管理、代码审计管理、代码构建等功能;
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分钟左右。
这套流程还在改进中，也希望感兴趣的同学一起学习交流。
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
