GitLab项目中的作业产物(Job Artifacts)管理指南

GitLab项目中的作业产物(Job Artifacts)管理指南

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq

前言

在现代CI/CD流程中，作业产物(Job Artifacts)是一个非常重要的功能。它允许我们在流水线作业完成后保留和共享生成的文件，如编译后的二进制文件、测试报告、日志等。本文将深入探讨GitLab项目中作业产物的管理方法，包括存储配置、迁移策略以及最佳实践。

作业产物基础概念

作业产物是指作业完成后附加到该作业的文件和目录列表。在GitLab中，这个功能默认是启用的，具有以下特点：

• 产物可以在作业成功、失败或始终保留
• 产物可以设置过期时间
• 产物支持本地存储和对象存储两种方式
• 产物可以被后续作业或用户下载使用

禁用作业产物功能

虽然作业产物功能默认启用，但在某些特殊场景下可能需要全局禁用。以下是不同安装方式下的禁用方法：

Omnibus安装方式

1. 编辑配置文件/etc/gitlab/gitlab.rb：

   gitlab_rails['artifacts_enabled'] = false
   

2. 保存并重新配置GitLab：

   sudo gitlab-ctl reconfigure
   

源码编译安装方式

1. 编辑配置文件/home/git/gitlab/config/gitlab.yml：

   production: &base
     artifacts:
       enabled: false
   

2. 保存并重启GitLab服务

作业产物存储配置

本地存储配置

默认情况下，作业产物存储在本地文件系统中。对于Omnibus安装，默认路径是/var/opt/gitlab/gitlab-rails/shared/artifacts。

要修改存储路径（例如改为/mnt/storage/artifacts）：

1. 编辑对应配置文件
2. 设置新的存储路径
3. 重新配置或重启GitLab服务

对象存储配置

对于生产环境，建议使用对象存储（如AWS S3）来存储作业产物，这能提供更好的可靠性和扩展性。

配置对象存储时需要注意：

1. 建议使用统一的对象存储配置
2. 在多服务器环境中，需要配置作业日志也使用对象存储
3. 迁移过程需要特别注意数据一致性

存储迁移策略

从本地迁移到对象存储

迁移作业产物到对象存储是一个后台操作，无需停机：

1. 首先配置好对象存储
2. 执行迁移命令（不同安装方式命令略有不同）
3. 验证迁移结果：
   • 通过PostgreSQL查询确认所有产物已迁移
   • 检查本地artifacts目录确认无残留文件
   • 如果启用了Geo，需要重新验证所有站点

从对象存储迁移回本地

如果需要回迁到本地存储：

1. 运行迁移命令
2. 选择性禁用特定功能的对象存储
3. 重新配置GitLab

产物过期管理

作业产物可以设置过期时间，未明确设置的将使用默认过期设置。过期产物由Sidekiq的定时任务清理，默认每7分钟运行一次。

要修改清理任务的执行频率：

1. 编辑对应配置文件
2. 设置新的Cron表达式
3. 重新配置或重启服务

高级配置

设置产物最大文件大小

管理员可以在管理区域设置作业产物的最大文件大小限制，这对控制存储使用非常有用。

存储统计查看

可以通过以下方式查看作业产物占用的存储空间：

• 管理员区域
• 群组和项目API

技术实现细节

GitLab处理作业产物时采用了一些优化策略：

1. 接收产物归档时同时生成元数据文件
2. 不直接解压归档文件以节省资源
3. 按需提取特定文件进行下载

这种实现方式在处理大量或大体积产物时特别高效，能显著降低存储和I/O开销。

最佳实践建议

1. 生产环境建议使用对象存储
2. 合理设置产物过期时间
3. 定期检查产物存储使用情况
4. 迁移操作前做好备份
5. 多服务器环境特别注意日志存储配置

通过合理配置和管理作业产物，可以确保CI/CD流程的高效运行，同时控制存储成本。

gitlabhq GitLab CE Mirror | Please open new issues in our issue tracker on GitLab.com 项目地址: https://gitcode.com/gh_mirrors/gi/gitlabhq