玩Devops的小伙伴应该对Jenkins都有了解。
Github上16.8k的Star的项目，1500+的构建、发布等自动化插件可供选择，事实上的业界CICD标准领导者。
JFrog、Coding等一众你能见到的企业级的Devops解决方案基本上都是用Jenkins做引擎。
产研流水线用Jenkins可以说真的很香。但是前几天它突然不听话了，它也有不香的时候，手动裂开。
前几天在做一个jenkins job的迁移，由于是第一次搞，在迁移的过程中遇到了小意外，出了点小插曲。
起因是在迁移的过程中发现一个历史的ci的pipeline job对应build目录特别大，执行下面的命令压缩备份起来异常耗时，等的花儿都谢了。
# tar -czvf a-jobs-bak.tar.gz a-jobs
熟悉jenkins的同学都应该知道build目录是用来存放job的历史构建记录的，于是进去之后执行下面的命令发现有近 N w个历史构建记录的文件夹没删除。
# ls | wc -l
所以就到job的配置页面查看job的配置，发现该job并没有配置丢弃旧的构建的策略。
然后愉快的给该job配置了一个丢弃旧的构建的策略
g
本以为万事大吉，静静的等着jenkins清理历史构建记录即可，不想一会儿，就有不少同事反馈构建的流水线响应缓慢，有不少超时。
于是赶紧在浏览器中访问jenkins，这个时候发现jenkins页面加载已经异常缓慢，基本上已经打不开了。
没有多想，第一反应就是刚配置的丢弃旧的构建策略生效后由于文件过多，整个jenkins都在删文件导致的，所以就赶紧重启jenkins。
# systemctl restart jenkins
起来之后发现，浏览器中可以访问jenkis，但是依然比较缓慢，这个时候感觉上面配置的丢弃旧的构建的策略依然在起作用，服务器依然在忙于删文件。
然后就立即删除上面给这个job配置的丢弃旧的构建的策略，紧接着再次重启jenkins服务，服务起来后没有再次出现响应缓慢卡顿的现象，同事们反馈所有研发的流水线恢复正常，问题得到解决。
这里要说明的是设置丢弃旧的构建策略在提交之后并不会立即生效，而是在有新的任务进来并且执行完成之后才会触发。
由于上面操作的是生产的ci，所有研发人员的构建部署事件都会通过中间件向上面提交，配置的丢弃旧的构建的策略提交之后立马会有任务进来。
这个时候就触发了丢弃旧的构建的执行，于是jenkins就开始忙于删除数以万计的文件，然后就出现了上文中所述的问题。
<span style="font-size: 16px;color: rgb(123, 12, 0);">总结一下本次得到的教训就是在正常的jenkins服务时间内一定要谨慎的设置或者修改job的的丢弃旧的构建策略来让jenkins去主动去删除大量的历史构建记录，这会是个灾难，会引起你的服务不可用。</span>
所以我们在给有需要job配置丢弃旧的构建策略之前一定要先确定下服务器上历史构建记录的数量。
如果该job下历史构建记录较多，达到了以万计，<span style="font-size: 16px;color: rgb(123, 12, 0);">建议你选择在正常的jenkins服务时间内手动分批删除，或者在服务使用量低峰或者服务维护时间进行删除操作。</span>
如果需要删除的文件数较少，你可以通过设置或者修改job的丢弃旧的构建策略等待jenkins自动删除。
<span style="font-size: 16px;color: rgb(123, 12, 0);">更推荐的做法是在job创建之初就给job配置丢弃旧的构建策略并且指定保持构建的最大次数为一个较小的值。</span>
网友评论