DevOps技术实践中的一些总结

狂风中的少年 提交于 2021-01-03 15:42:02
         嘿嘿嘿 点击上方可以订阅哦!


     

作者

泽阳,运维工程师,实际工作经验4-5年,经历了传统运维到自动化运维整个过程。整理分享DevOps、CICD、编程开发、监控、日志等相关技术实践!定期更新,来吧一起踏上技术的征途!整理的最新Jenkins实践文档 http://zeyangli.github.io

公众号:devopsadmin    微信:proc_code  定期分享技术实践!


     

1

简介


上周做了点什么呢? 最近经常健忘~~~,所以必须得动笔了,正式开战 哈哈

  • 容器构建资源池的部署

  • 制品库管理试运行

  • JenkinsShareLibrary优化

简单做个总结,给自己一个交代,也许对于阅读的你也会有帮助。


2

容器构建资源池的部署


构建平台是部署在vm中,一个生产的Master和N多个Slave。由于构建项目的增加,平台现有项目1k+,并发数量也增加了很多。问题也来了。磁盘空间不足/构建执行器不足等等问题。


原因分析:

1. 并行数量增多。

2. 构建与部署在同节点完成,节点压力大。

3. 每个slave默认配置15个执行器,不够用。


解决思路:

1. 构建与发布在不同的节点完成。(CICD分离)

2. 将构建节点固定在容器中。(解决系统资源不足问题)


具体实施:

1. 创建通用的JenkinsSlave镜像。(slave启动密钥能够通过环境变量传入)

按照openshift官方提供的slave镜像更改或自行制作

将构建工具(maven/ant/gradle/jdk)纳入镜像中。

将agent.jar包纳入镜像中。

2. 在OpenShift中部署slave。

将调度的节点创建label。

为serviceaccount授权允许root运行。

创建持久化PV并创建PVC绑定(构建缓存)

编写Deployment Configuration 设置RC为1

3. Jenkins配置

master节点创建新的slave指定标签名称并创建label。


通过上述操作能够实现 Jenkins master能够正常的连接到容器中的Slave节点。我们尝试过通过Jenkins中的K8S插件来动态生成Slave节点,但每次生成的等待时间有点长。所以采用固定的Slave方式。

3

制品库管理试运行


制品库的管理涉及到很多内容,对于项目的构建依赖,我们代理了官方的Maven/Gradle等仓库。当前的流水线的制品并没有保存,而是直接构建并发布完成后直接删除制品

。无法完成版本的追溯和及时回滚。


问题分析:

1. 重复构建(原本预生产与生产部署的是相同的制品却需要再次编译构建发布)

2. 变更追溯(无法实现制品与代码基线的关联) 


解决方法:

1. 定义制品版本号规范(例如:maven项目中的pom文件中的version定义规则)

2. 配置流水线中制品库上传之前的质量关卡。

3. 流水线中添加制品与代码关联步骤(通过质量关卡后创建代码Tag与制品库的版本关联)


具体实施:

1. 按照不同的环境和技术类型创建公共的存储仓库。

2. 借助Artifactory插件完成制品的上传(定义上传目录和包的名称)。

3. 通过GitlabAPi创建代码Tag标签。


以上是我们通过在流水线中增加上传步骤实现的代码基线与制品的关联,便于追溯。

4

JenkinsShareLibrary优化



参数化构建,根据参数执行不同的流水线。可以使用When语法实现根据参数执行不同的步骤,也可以使用IF判断实现根据参数执行不同的流水线。前者是根据stage的编排,后者针对的是pipeline。来说下我的做法吧。


共享库结构

src/xxx/xxx/xxx.groovy

vars/

ciPipeline.groovy

cdPipeline.groovy

ciCdPipeline.groovy

gitCommitPipeline.groovy


以上vars里面每个文件中都包含一条流水线。而实际的Jenkinsfile可能就10几行的代码了。


例如以下Jenkinfile脚本.其实实现的方式有很多种,这种情况会有一些重复的代码量。但这样可能最好的效果是能够使流水线更加灵活,比如根据某个部门特殊的配置一条特色的流水线。又或者在容器方面的CICD的时候也可以根据容器的特点来扩展。总之现在的方案是根据pipeline为单位的扩展。


#!groovy@Library("Jlibrary@master") _String runModes = "${env.runModes}"switch("${runModes}"){    case "CI":        ciPipeline()
    case "CD":        cdPipeline()
    case "CICD":        ciCdPipeline()
    case "GitCommit"        gitCommitPipeline()
    default:        defaultPipeline()}


5

总结


文件结尾了,在实施中有很多坑点。比如Jenkinsfile中处理Json数据,其实我们使用readJSON这个插件就能解决序列化的问题。哈哈,实施完成后回过头想想真是有意思。今天分享就在这里了,希望通过此总结给正在实施中的伙伴减少坑点,给还未遇到这些问题的伙伴一个假想。感谢各位。


感谢您的查阅,也非常希望您能将内容分享给他人,有问题可在公众号回复。



        

往期内容推荐

Kubernetes中pod资源对象管理

SonarQube代码扫描模式

Gitlab+Drbd高可用方案(主备模式)


DevOps持续集成

更多精彩 请关注公众号


本文分享自微信公众号 - DevOps云学堂(idevopsvip)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!