CentOS下GitLab升级步骤
一 升级前准备
- 备份数据与配置：执行备份命令并将关键配置离线保存。命令示例：sudo gitlab-rake gitlab:backup:create（备份默认位于**/var/opt/gitlab/backups/）；同时备份配置文件/etc/gitlab/gitlab.rb与/etc/gitlab/gitlab-secrets.json**。如磁盘空间紧张，可清理旧备份，但务必保留最近一次可用备份。
- 检查当前版本与升级路径：查看版本信息（sudo gitlab-rake gitlab:env:info），并对照官方升级路径工具选择目标版本，避免跨多版本跳跃升级。
- 系统与依赖检查：确保系统软件包为较新状态（sudo yum update -y），并确认依赖（如 policycoreutils、openssh-server、postfix 等）已安装；如系统库版本较低，考虑使用容器化部署规避兼容性问题。
- 维护窗口与可用性：单节点升级期间会出现短暂不可用（如显示“Deploy in progress”或502），请提前通知用户并选择合适时间窗口。
二 标准升级步骤（Omnibus RPM 包，推荐）
- 更新本地软件索引与仓库元数据：sudo yum update -y。
- 可选 指定版本升级：先查询可用版本（yum --showduplicates list gitlab-ce），再安装目标版本（sudo yum install gitlab-ce-<版本号> -y）。
- 执行重新配置以应用新版本：sudo gitlab-ctl reconfigure。
- 重启服务并验证：sudo gitlab-ctl restart；检查状态（sudo gitlab-ctl status），确认各组件（如 nginx、puma/sidekiq、postgresql 等）均为run状态；登录管理界面或执行 sudo gitlab-rake gitlab:env:info 确认版本号。
- 如曾手动停止服务，也可在升级前执行：sudo gitlab-ctl stop unicorn && sudo gitlab-ctl stop sidekiq（nginx 可按需停止）。
三 手动 RPM 升级（无外网或仓库不可达时）
- 下载对应系统的 RPM 包（如 gitlab-ce-.el7.x86_64.rpm），建议先校验包的完整性与来源可信度。
- 停止相关服务：sudo gitlab-ctl stop unicorn && sudo gitlab-ctl stop sidekiq（可按需停 nginx）。
- 执行升级安装：sudo rpm -Uvh gitlab-ce-.rpm。
- 重新配置并启动：sudo gitlab-ctl reconfigure && sudo gitlab-ctl start；随后用 sudo gitlab-ctl status 与版本查询确认升级成功。
四 升级后验证与回滚
- 运行配置与数据一致性检查：sudo gitlab-rake gitlab:check SANITIZE=true；如曾中断升级或出现异常，检查后台迁移状态（sudo gitlab-rake db:migrate:status），必要时执行 sudo gitlab-rake db:migrate 完成迁移。
- 访问实例页面与 API，确认版本号、项目/仓库、CI/CD、Webhooks、LDAP/SSO 等功能正常；检查系统资源与日志（/var/log/gitlab/）是否有报错。
- 回滚方案：若升级失败或异常，先恢复最近一次备份（sudo gitlab-rake gitlab:backup:restore BACKUP=<时间戳>），再重启服务（sudo gitlab-ctl restart）。建议先在测试环境演练升级与回滚流程。
五 注意事项与常见问题
- 升级节奏与兼容性：严格遵循官方升级路径，避免跨多版本直接升级；在主要/次要版本之间留出足够时间完成后台迁移；如底层库（如 glibc）不满足新版本要求，优先考虑容器化部署。
- 多节点/分布式架构：先升级Gitaly节点，再升级应用节点，避免 gRPC 不兼容。
- 500 错误与数据库：升级后出现500多与数据库迁移未完成或失败有关，优先检查迁移状态并执行迁移。
- 服务占用与锁冲突：reconfigure 卡住时，排查是否有残留的 Chef/puma/sidekiq 进程并清理后再执行。
- 备份策略：生产环境务必在升级前完成备份，并保留至少一份离线/异地副本。