清理 Jenkins 主目录

Posted 2023-03-06

【中文标题】清理 Jenkins 主目录

【英文标题】：Cleanup Jenkins home directory

【发布时间】：2020-10-21 01:51:09

【问题描述】：

我们从过去几个月开始使用 jenkins，现在主目录的大小约为 50GB。我注意到 Jobs 和 workspace 目录的大小分别约为 20 GB。我怎样才能清洁它们？我应该使用什么样的策略？

【参考方案1】：

考虑倾向于过度增长的各种 Jenkins 领域。关键区域是：系统日志、作业日志、工件存储和作业工作区。这将详细介绍最佳管理这些选项的选项。

系统日志

系统日志可以在<JENKINS_HOME>/logs 或/var/log/jenkins/jenkins.log 中找到，具体取决于您的安装。默认情况下，Jenkins 并不总是包含日志轮换 (logrotate)，尤其是在直接从战争中运行的情况下。解决方法是添加logrotate。此 Cloudbees 帖子和我的 S/O response 添加详细信息。

您还可以设置 Jenkins 系统属性 hudson.triggers.SafeTimerTask.logsTargetDir 以将 logs 重新定位到 <JENKINS_HOME> 之外。为什么稍后回答。

工作日志

每个作业都可以选择[ X ] Discard old builds。截至LTS 2.222.1，Jenkins 引入了一个全局构建丢弃器（pull #4368)，具有类似的选项和默认操作。这是一个全局设置，在此之前，作业日志（和工件）默认永久保留（不好）。

高级选项可以管理工件保留（来自构建后操作，分别“归档工件”。

---

Jobs 目录中有什么？

Jobs 目录包含每个作业的目录（以及文件夹，如果您使用它们）。目录内部是作业config.xml（大小为几KB），外加一个目录builds。 builds 有一个编号目录，其中包含每个保留构建的构建日志、运行时 config.xml 的副本以及可能的一些其他记录文件（changelog.xml、injectEnvVars.txt）。如果您选择Archive the artifacts option，还有一个archive 目录，其中包含来自该构建的工件。

Jenkins 系统属性 jenkins.model.Jenkins.buildsDir，可让您将 builds 重新定位到 <JENKINS_HOME> 之外

为什么要将日志迁移到 之外？

我强烈建议重新定位系统日志和作业/构建日志（和工件）。通过将系统日志和构建日志（和工件，如果勾选）移到<JENKINS_HOME> 之外，剩下的就是在发生灾难或迁移时支持和恢复 Jenkins 和作业的真正重要的东西。仔细阅读并理解“支持迁移现有构建记录”的步骤，以避免与构建相关的错误。它还可以更轻松地分析哪些作业日志占用了所有空间以及原因（即：日志与工件）。

工作区

工作区是签出源代码和执行作业（构建）的地方。工作区应该是短暂的。 Best Practices是从一个空的工作区开始，完成后清理 - 除非必要，请使用 Workspace Cleanup ( cleanWS() ) plugun。

Jenkins 控制器中工作区的 OP 指示表明作业正在主服务器上运行。说这不是一个好的（或安全的）实践，除了轻量级管道总是在 master 上执行。错误配置的作业管道也将退回到 master（将尝试查找参考）。您可以设置一个与主服务器在同一台服务器上物理运行的节点，以获得更好的安全性。

如果删除全部不可行，您可以使用cleanws() EXCLUDE 和 INCLUDE 模式选择性地清理工作区。

有两个 Jenkins 系统属性来控制workspace 目录的位置。对于主节点：jenkins.model.Jenkins.workspacesDir，对于节点/代理：hudson.model.Slave.workspaceRoot。同样，由于这些是短暂的，请将它们从 <JENKINS_HOME> 中删除，以便您更好地管理和监控。

---

最后，还有一个空间考虑... 本地存储库中的 maven 和 npm 缓存工件。通常位于用户的$HOME 目录中。如果经常增加版本，该内容将变得陈旧和臃肿。它是一个缓存，所以每隔一段时间花点时间来清除它或以其他方式管理内容。 但是，可以通过 maven 和 npm 设置将缓存重新定位到其他地方。此外，如果运行 maven 步骤，则每个步骤都有高级选项以拥有一个私有存储库。它位于工作的工作区内。好处是你知道你的构建正在使用什么；没有污染。但是，如果所有作业都有私有存储库并且您从不清理它们或删除工作区，或者如果您清理了每次都需要更长的构建时间，那么不利的一面是大量重复和浪费空间。根据需要考虑使用cleanWS() 或单独的作业来清除。

【参考方案2】：

可以在任何执行之后和/或之前清理工作区。我建议在执行之前和之后执行此操作。构建后，仅在成功构建时执行此操作。如果出现错误，您可以进入工作区并在那里检查是否有任何线索。您可以使用 CleanWs() 命令在管道上执行此操作。

对于作业目录，您可以在作业中选择要存储的时间量/最大执行次数。这更复杂，因为它取决于您要保存的内容。例如，如果有很多构建并且您不介意删除该信息，您可以在 30 天内保存 10 个构建。该配置位于作业属性下的作业配置中，并搜索“放弃旧构建”和“要保留构建的天数”和“要保留的最大构建数”。

我的建议是你先使用更大的数字，然后你可以测试它的行为