一些构建失败,暴露 workspace 空间不足问题
原因分析:
业务间,编译环境不统一,不能跨业务共享
业务内,特定 jobs 直接绑定特定 slave,并发量受限于 executor 数目
Slave 上构建 workspace 的遗留,占用大量空间
业务量增大,新建 Jobs 增多,瓶颈出现
我们在使用 Jenkins 过程中暴露出一些问题,我们挂载的 Slave 很多,空闲的也很多,没有被充分利用起来。另外,挂载那么
多的 Slave,我们队列中等待构建的还很多,相当于那么多的 Slave 没有解决并发的问题,任务还在等待。还有一些构建失败
了,是因为 workspace 空间不足。
为什么会产生上述问题呢?
一个是业务间,编译环境不统一,不能跨业务共享。一台 Jenkins 上挂了那么多 Slave 给不同业务用,相对来说不同的业务只
能使用这么多 Slave 中的一些子集。
第二是业务内,有些业务的同学去配置 job 的时候,直接绑定特定的 Slave,相当于直接绑定那个 Slave 的 name,而不是
Lable,这些 job 所有的构建只依赖于这个 Slave,这个并发就受到被绑的 Slave 的 executor 数目限制。
第三,Slave 上构建 workspace 有遗留,占用大量空间。一个 job 构建结束后,编译的空间遗留在 Slave 上,除非在你的 job
里配置了清理规则。
此外,随着业务量增大,新建的 job 也多,慢慢瓶颈就出现了,问题也就都暴露出来了。
在座的同学随着你们公司业务的发展,这些问题可能都会遇到的。
2.3 优化改进
面对上述的问题我们改如何进行优化改进呢?我们做了四个方面的优化:
同质 slaves 添加相同 Label,同类型 jobs 使用 Label 进行构建
适量增大 slave 的 executor 数目
定时扫描清理 slaves 上的废弃 jobs 的遗留 workspace
业务 jobs 配置 workspace 清理规则
下面细说下。
我们把我们同质 Slaves 添加相同 Lable,用 Lable 来管理我的 Slaves,前面有说到我们的业务不同的产品线,相当于我们的
编译环境不一样,同一套产品,把同质 Slaves 通过 Lable 使用,同类型 jobs 可以使用 Lable 进行构建。
适量增大 executor 数目,一定会增大并发量。为什么是适量?编译相当于我们用物理机24线程并发去跑,根据业务的场景不
同,我们是适量的。比如原来一个物理机只配一个,根据有的产品线的 job 没有消耗那么多的 CPU、memory,编译时间要求
不高,有一些 Slave 从一个 executor 增加到两个,就能解决 job 并发量的问题。
第三个要解决 Slaves 上遗留的编译 workspace 的问题,定时扫描 Slave 上的 workspace。有两点要注意,一点是在你使用过