GitLab 在 CentOS 上的版本兼容性概览
系统版本与生命周期
- 传统 CentOS 6 的生命周期早已结束，GitLab 对它的支持也早已终止；历史资料显示 CentOS 6 最高仅能运行到 GitLab 9.5.x。在 CentOS 6 上曾可用的最后一批版本为 8.17.8 → 9.5.9，再往上的版本需要迁移到 CentOS 7 才能继续升级。对于仍在 CentOS 6 的环境，建议先规划迁移再升级 GitLab。
- CentOS 7 生命周期已于 2024-06 结束，但 GitLab 在 CentOS 7 上的兼容性总体良好，社区与企业长期在 CentOS 7 上运行 GitLab 15.x 等版本，实际案例与升级路径均有成熟实践。若需继续获得安全更新，建议规划迁移至受支持的替代发行版（如 AlmaLinux 8/9、Rocky Linux 8/9）。
- CentOS 8 已于 2021-12-31 停止维护。自 GitLab 14.5 起，官方在构建与兼容性上已将 AlmaLinux 纳入支持范围，实际部署中常见做法是在 AlmaLinux 8 上部署或迁移 GitLab 14.6.x 及更高版本，以获得更好的兼容性与后续支持。
包架构与依赖匹配
- 选择与系统匹配的 RHEL 兼容包（el7/el8）：CentOS 7 用 el7、CentOS 8/AlmaLinux 8 用 el8。安装时若遇到依赖报错，例如提示需要 policycoreutils-python（el7）或 policycoreutils-python-utils（el8），安装对应依赖即可完成安装或修复。此类报错通常与系统版本不匹配或未安装 SELinux 工具链有关。
- 升级或迁移时，保持 GitLab 版本与系统版本（el 系列）一致，可减少依赖冲突与运行期异常；跨系统迁移（如 CentOS 7 → AlmaLinux 8）在同版本 GitLab 下完成数据与配置的迁移，再在目标系统上按需升级，是较为稳妥的路径。
升级与迁移的兼容性原则
- 不支持跨主要版本直接升级，需按“同一主版本内先升级到该主版本的最新小版本，再升级到下一主版本”的顺序分阶段升级。例如社区实践中的路径：8.17.8 → 9.5.9 → 10.8.7 → 11.11.8 → 12.10.14。每一步升级后都建议进行可用性验证与备份，再继续下一步。
- 跨系统迁移建议先在同版本 GitLab 间完成（如 15.0.0 → 15.0.0），验证无误后再在目标系统上继续升级到更高版本。这样可把“系统差异”与“版本升级”解耦，降低风险。
实践建议
- 若仍在 CentOS 6/7：优先规划迁移至 AlmaLinux 8/9 或 Rocky Linux 8/9，再在目标系统上部署或升级 GitLab；短期无法迁移时，至少将 GitLab 保持在当前系统可支持的最高稳定版本，并严格限制外网暴露与加强备份。
- 若需在 CentOS 8 路线继续运行：考虑迁移到 AlmaLinux 8 并选择 GitLab 14.6.x 或更高版本，以获得更好的兼容性与后续维护空间。
- 统一 Runner 与 GitLab 版本系列（如均使用 17.x），并在升级前完成全量备份（配置与数据），升级后执行健康检查（如
gitlab-rake gitlab:check、gitlab-ctl status、gitlab-ctl tail）。
