CentOS 7 手动安装 GitLab：RPM包全流程与离线部署详解

开头切入场景说明核心价值如果你做过一段时间的运维或者自己折腾服务器大概率会遇到这样一个场景公司内网要搭一套代码托管平台业务团队天天催着要 GitLab又或者你手里就一台 CentOS 7 老机器没有 Docker、不想折腾容器化就想简简单单把一个 GitLab 装起来用。搜了一圈教程发现大部分都在讲 yum 一行命令装完要么就是 docker-compose 一把梭。可到了真正需要离线部署、精确掌控版本、搞懂每个服务是怎么跑起来的时候这些教程就不太够用了。GitLab 本身是一个相当重的全家桶应用里面集成了 Nginx、PostgreSQL、Redis、Sidekiq、Puma以前是 Unicorn、GitLab Workhorse 等一堆组件。正因为它重所以从 RPM 包开始手动装反而是最快理解整个系统的方法。这个标题里写的是“RPM 包手动安装”说白了就是避开自动安装脚本和容器化方案自己掌握每一步——从系统准备、依赖处理、软件包下载到初始化配置、内存调优、备份恢复全程亲手操作。这篇文章的主线就是照着我在实际服务器上反复验证过的完整流程把 CentOS 7 下用 RPM 包装 GitLab 这件事一次讲透。文章适合三类读者一是需要在内网或离线环境部署 GitLab 的运维同学二是想摆脱“只会敲命令、不知道原理”状态的后端开发者三是用着低配机器、想榨干每一点资源来跑 GitLab 的个人站长。下面直接开始。1. 为什么非要手动装 RPM 包先搞清适用场景在动手之前我觉得有必要先说清楚一个很多教程里默认大家都知道、但新手最容易犯迷糊的问题既然 GitLab 官网推荐的是curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash一键安装那我们为什么还要绕一圈去手动下载 RPM 包1.1 三种安装方式的核心差异我简单用一个表格把主流安装方式的差异列出来后面再展开解释。安装方式优点缺点典型适用场景yum 自动安装Omnibus 仓库命令短、依赖自动解决、升级方便需要外网或可用软件源版本由源决定想固定特定版本反而麻烦有外网、想快速上手的开发机器Docker 容器化迁移方便、不污染宿主机、回滚容易需要 Docker 环境资源开销比裸装略大离线环境要额外搬运镜像有 Docker 基础设施的团队RPM 包手动安装可控性最强、版本锁定精确、可以离线部署、能摸清组件关系依赖需自己处理、reconfigure 排错要自己扛内网离线环境、生产服务器、想深入学习的人1.2 RPM 手动安装的本质GitLab 官方所谓的“RPM 包”是一个Omnibus 全栈包。你可以把它理解为GitLab 公司把 Ruby、Rails、PostgreSQL、Redis、Nginx、Gitaly、Sidekiq 等所有内部组件全部打包进了一个 RPM 包里装完之后统一由gitlab-ctl这个工具来管理和编排。但这不意味着这个 RPM 包是零依赖的。它仍然需要系统层面预装一些基础服务尤其是openssh-server、postfix、curl、policycoreutils-python这些。很多人执行rpm -ivh gitlab-ce-xxx.rpm时报错十有八九是卡在依赖解析这一步。也就是说所谓“手动安装”手动的主要是两部分一是系统依赖的准备二是 GitLab 本身的下载、安装、初始化。很多人装到一半卡住其实不是 GitLab 安装包的问题而是 CentOS 7 最小化安装后系统本身缺了一堆基础组件。1.3 版本选择别无脑上最新GitLab 的版本号和 CentOS 7 密切相关。CentOS 7 的系统库比较老glibc 2.17GitLab 从 16.x 开始对内存和系统组件的要求明显提高。如果你只是想在 2GB 内存的机器上跑一个轻量的 GitLab 服务我个人建议选择 GitLab 15.x 系列跑起来更省心如果机器配置在 8GB 内存以上再考虑 16.x/17.x 的最新版本。官方 RPM 包命名有规律比如gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm其中el7代表 CentOS 7 / RHEL 7 系列x86_64是架构ce是社区版。下载时一定要认准el7和x86_64这两个标识我就见过有人把 el8/el9 的包拖下来硬装结果依赖直接崩掉。2. 装机前的系统准备先把地基打牢很多人喜欢上来就敲安装命令结果装到一半发现连wget都没有或者rpm命令本身都找不着。别笑我在一台精简到极致的 CentOS 7 上就真遇到过“没找到 rpm 命令”的情况——这是系统安装时连基础工具链都没装全导致的。所以先把系统环境准备好这一步能帮你省下后面几小时的排错时间。2.1 基础依赖包按需补齐先用一个命令确认系统版本cat /etc/redhat-release如果是 CentOS Linux release 7.x继续往下走。建议把基础工具链先装齐yum install -y curl wget vim net-tools policycoreutils-python openssh-server postfix cronie这里逐个说下为什么需要policycoreutils-python如果系统开启了 SELinuxGitLab 在 reconfigure 时需要用到它来管理 SELinux 策略缺了会直接报错。openssh-serverGitLab 的 SSH 访问方式依赖它。CentOS 7 最小化安装不一定带 openssh-server务必确认sshd在运行。postfixGitLab 发邮件注册确认、通知、密码找回依赖一个本地 MTA。虽然也可以配置外部 SMTP但没有本地 postfix 时 reconfigure 过程会报 sendmail/postfix 相关的警告。cronieGitLab 内部一些计划任务依赖 cron没有它定时备份之类功能会异常。如果你的yum源因为 CentOS 7 进入维护期而失效了yum install报一堆 404 错误那先把源换成 vault 归档源再执行上面的命令。这一步属于系统基础操作我在这里就不展开讲具体源配置了思路就是让 yum 能正常解析和下载 rpm 依赖包。2.2 防火墙与 SELinux 的处理CentOS 7 默认开着 firewalld。如果你希望通过http://IP直接访问 GitLab 的 Web 界面需要放行 HTTP/HTTPS 端口默认是 80/443如果改过端口另行处理firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --reload至于 SSH 端口默认 22一般已经在放行名单里不用额外操作。关于 SELinux官方其实对 GitLab 有一定支持但在 CentOS 7 的某些版本组合下容易出奇怪问题。我的习惯是如果不是安全合规强制要求建议把 SELinux 设为 permissive也就是只记录不阻断。这个处理方式在 GitLab 官方 issue 里也经常被提到作为解决 Nginx 和 git 访问权限问题的前置手段之一。setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config注意setenforce 0是临时生效改selinux/config才是永久生效。如果公司安全规范要求必须 enforcing那也可以保留但后面遇到权限类问题时要第一时间怀疑它。2.3 内存、主机名与 hosts 解析GitLab 是吃内存大户。官方标注的最低内存是 4GB但那个标准跑起来其实是“能启动”而不是“流畅”。如果你的机器只有 2GB 内存强烈建议加 2GB swap否则后面前端页面经常 502、服务不时被 OOM 干掉体验非常难受。创建 swap 的通用做法针对 2GB 机器建议 4GB swapdd if/dev/zero of/swapfile bs1M count4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile然后把 swap 写进/etc/fstab/swapfile swap swap defaults 0 0接着配置主机名和 hosts。GitLab 强烈建议用域名或固定的主机名来访问而不是每次都用 IP。如果你没有内网 DNS可以自己定义一个虚拟域名比如gitlab.local然后把本机 IP 写进 hostshostnamectl set-hostname gitlab.local echo 192.168.1.100 gitlab.local /etc/hosts这一步看着不起眼但直接决定后面external_url怎么配。如果你跳过 hosts 配置后面前端页面上项目克隆地址会变成http://gitlab.local/xxx而不是服务器 IP那在内网环境里反而容易造成访问混乱。3. 一步步敲安装命令RPM 包下载、依赖解析与安装过程系统准备工作做完就可以正式进入安装环节了。这一步的核心任务是把 GitLab 的 RPM 包下载到本地解决它依赖的系统包然后执行安装和初始化。3.1 从哪里下载 RPM 包两个主流渠道任选其一。官方渠道packages.gitlab.comwget https://packages.gitlab.com/gitlab/gitlab-ce/packages/el/7/gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm/download.rpm国内镜像清华 TUNA清华镜像的逻辑目录是固定的路径里按版本号组织文件夹。比如wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm建议优先用清华源速度快很多尤其是 CentOS 7 老机器上从海外拉包慢起来真的让人抓狂。如果是在完全没有外网的内网环境部署那你需要先在一台能上网的机器上把所有依赖包下载好然后再搬运到内网机器上。这也就是很多人说的“离线部署”逻辑比在线安装多一步依赖收集# 在能上网的机器上执行下载 gitlab rpm 及其所有依赖 yum install -y yum-utils yumdownloader --resolve --destdir/tmp/gitlab-offline gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm把/tmp/gitlab-offline目录整个拷贝到内网机器然后在里面执行安装。yumdownloader --resolve是一个非常好用的工具会把当前 RPM 在 yum 源里能解析到的全部依赖一次拉齐。3.2 安装命令rpm -ivh 还是 yum localinstall这是新人最容易纠结的地方。直接用sudo rpm -ivh gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm如果系统没有任何缺失依赖这个命令会很顺利装完自动执行一段安装脚本最后输出类似gitlab-ce installed successfully的提示。但如果你在离线环境、或者系统包本身不全很可能遇到error: Failed dependencies: policycoreutils-python is needed by gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm这时候有两个选择按提示把对应依赖用yum install package名逐一装上再重新rpm -ivh。改用yum localinstall让 yum 从已配置的源里自动解析并安装依赖这也是比较省事的方式sudo yum localinstall -y gitlab-ce-17.0.0-ce.0.el7.x86_64.rpm注意yum localinstall的前提是 yum 源可用。离线环境下它依然会失败那就只能走yumdownloader --resolve的方式把依赖包全部搬回来再统一 rpm 安装。依赖全部装完以后RPM 包安装阶段才算结束。此时 GitLab 已经铺到了/opt/gitlab目录但服务还没真正跑起来。3.3 初始化命令 gitlab-ctl reconfigure 到底做了什么GitLab 装完后最核心的初始化动作是sudo gitlab-ctl reconfigure这条命令是 Omnibus 包的精髓。它在内部做了这些事根据/etc/gitlab/gitlab.rb里的配置生成各组件Nginx、PostgreSQL、Redis、Puma、Workhorse、Gitaly 等的配置文件。创建运行所需的用户、目录、日志目录、socket 文件。初始化数据库、迁移表结构。启动所有服务并把它们注册成 systemd 服务。如果 /etc/gitlab/gitlab.rb 没有做任何修改reconfigure 会用默认配置把整套服务拉起来。初次 reconfigure 耗时取决于机器性能我在 2C4G 的机器上实测大概 3 到 5 分钟中间会刷很多Running handlers之类的日志这是正常的。等它执行完再用下面命令确认服务状态sudo gitlab-ctl status正常输出类似于run: alertmanager: (pid 12345) 5678s; run: log: (pid 12344) 5678s run: gitaly: (pid 12346) 5678s; run: log: (pid 12343) 5678s run: gitlab-exporter: (pid 12347) 5678s; run: log: (pid 12342) 5678s run: gitlab-kas: (pid 12348) 5678s; run: log: (pid 12341) 5678s run: gitlab-workhorse: (pid 12349) 5678s; run: log: (pid 12340) 5678s run: logrotate: (pid 12350) 5678s; run: log: (pid 12339) 5678s run: nginx: (pid 12351) 5678s; run: log: (pid 12338) 5678s run: node-exporter: (pid 12352) 5678s; run: log: (pid 12337) 5678s run: postgresql: (pid 12353) 5678s; run: log: (pid 12336) 5678s run: prometheus: (pid 12354) 5678s; run: log: (pid 12335) 5678s run: puma: (pid 12355) 5678s; run: log: (pid 12334) 5678s run: redis: (pid 12356) 5678s; run: log: (pid 12333) 5678s run: sidekiq: (pid 12357) 5678s; run: log: (pid 12332) 5678s看到所有组件都是run状态说明这一阶段的安装已经成功。如果哪个组件是down比如常见的postgresql、puma起不来先别急着全网搜优先去看对应日志后面章节我会给到排查思路。4. 初始配置external_url、管理员密码和内存裁剪安装只是开始真正让 GitLab 变得可用的是配置阶段。这一章写的是上线前必须处理的几个核心配置项以及低配机器上怎么让 GitLab 别被内存拖垮。4.1 核心配置项解析external_url 与相关参数GitLab 的主配置文件是/etc/gitlab/gitlab.rb。这个文件默认规模很大里面全是注释初学者容易看懵。别慌真正需要主动改的配置并不多。最核心的一个是external_url。它决定了 GitLab 对外展示的访问地址会影响所有项目 clone 地址、webhook、SSH 地址的生成逻辑。如果你没有配置 DNS就把它指向上一步在 hosts 里定义的虚拟域名或服务器 IPexternal_url http://gitlab.local这里注意GitLab 默认会把 SSH clone 地址显示成gitgitlab.local:group/project.git。如果服务器的 SSH 端口不是默认 22还需要额外加一行指定 SSH 访问端口gitlab_rails[gitlab_shell_ssh_port] 2222这个配置我建议一开始就写清楚。很多人是装完以后才发现 SSH 端口不对每次 clone 都得手动改 URL团队成员一多就特别容易出错。另一个值得设置的参数是时区避免后面前端页面显示的时间和服务器本地时间不一致gitlab_rails[time_zone] Asia/Shanghai改完配置后一定要重新执行gitlab-ctl reconfigure让配置生效。只改文件不 reconfigure等于白改。4.2 首次登录与管理员密码处理服务起来以后用浏览器访问http://gitlab.local或http://服务器IP会跳转到用户登录页面。GitLab 初次安装时会自动生成一个随机管理员密码存在/etc/gitlab/initial_root_password文件里。文件内容格式大概是WARNING: This value is valid only in the first 24 hours after installation...注意这个文件在系统运行 24 小时后会被自动删除。所以要么在 24 小时内用这个密码登录并主动修改密码要么直接通过命令行重置密码。我个人的习惯是直接重置省得去翻文件sudo gitlab-rake gitlab:password:reset[root]执行后脚本会提示输入新密码并二次确认。完成后用root 新密码登录即可。登录之后第一件事不是急着建项目而是建议去Admin Area → Settings → General里把「Sign-up restrictions」的注册关闭避免内网随便谁都能注册账号。之后就是正常的用户管理、组管理了。4.3 低配机器上必做的内存裁剪方案GitLab 默认配置是按 4GB 以上内存机器调的2GB 机器直接跑默认配置大概率过不了多久就会出现 Puma 被杀、页面 502 的情况。下面这套是我在低配机器上实测有效的内存优化方案照抄可以直接用。编辑/etc/gitlab/gitlab.rb追加或修改以下内容# Puma 的 worker 数量2GB 内存建议 21GB 建议 1 puma[worker_processes] 2 puma[min_threads] 1 puma[max_threads] 4 # Sidekiq 并发数调低减少内存占用 sidekiq[max_concurrency] 5 # 关掉 Prometheus 监控系 prometheus_monitoring[enable] false # 关掉不需要的监控导出器 node_exporter[enable] false gitlab_exporter[enable] false另外生产环境如果是追求稳定而不是要监控面板那 Prometheus 这组服务其实可以直接不启动。它们占用的内存比较可观在低配机器上性价比不高。配置改完执行sudo gitlab-ctl reconfigure sudo gitlab-ctl restart如果你的机器低于 4GB关掉监控、把 worker 调到 2 以后内存占用能明显降下来。我曾经在 2GB 内存 4GB swap 的机器上用这套配置让 GitLab 跑了半年多日常内存占用稳定在 60% 左右基本能接受。还有一个补充操作是日志清理。GitLab 日志文件默认存在/var/log/gitlab下跑久了会非常占磁盘。经验值是每天能产生几百 MB 到 1GB 不等对于磁盘紧张的小机器来说伤害很大。建议打开自带的 logrotate 策略同时缩短日志保留天数logging[logrotate_frequency] daily logging[logrotate_rotate] 7这一步不用刻意追求把所有日志都留个底朝天至少保持最近一周的记录就够了。5. 上线前必须处理的问题502、SSH 端口与备份恢复装完、配完、能登录很多人就以为大功告成了。实际上 GitLab 这种东西真正考验人的反而是上线后的稳定性问题。这一章我把出现频率最高、并且跟“RPM 手动安装”方式强相关的问题集中梳理一遍。5.1 502 Bad Gateway先看服务再查日志遇到过 502 的人应该能体会那种郁闷页面打开就是502 Bad Gateway完全不知道问题出在哪一环。其实 GitLab 出现 502绝大多数原因是某个后端服务没有跑起来Nginx 反向代理到不了后端。排查链路我建议按这个顺序来能少走很多弯路第一步确认服务状态sudo gitlab-ctl status第二步如果某个服务是 down去/var/log/gitlab/服务名/目录下看对应日志。比较常出问题的两个服务是postgresql和puma# PostgreSQL 日志 sudo tail -100 /var/log/gitlab/postgresql/current # Puma 日志 sudo tail -100 /var/log/gitlab/puma/current第三步确认系统资源是否告急。内存满了、磁盘满了都会导致服务起不来df -h free -m根据我遇到的情况502 最常见的两个元凶依次是内存不足导致 puma 被杀、磁盘满导致 postgresql 无法写入。前者靠增加 swap 和调低 worker 解决后者靠清理日志和扩容解决。有几个自查命令也很有用# 检查服务监听端口 ss -lntp | grep -E 80|443|8080|5432|9168如果 80 端口没监听说明 nginx 大概率没起来或者配置文件有语法问题。如果 nginx 起来了但 5432postgresql没起来问题就在数据库。5.2 非默认 SSH 端口下的完整处理这个问题几乎每隔一阵就有人问。如果你的服务器 SSH 端口不是默认的 22比如改成了 2222那么 GitLab 默认生成的 SSH clone 地址gitgitlab.local:group/project.git在 clone 时其实会直接失败因为 Git 客户端会走 22 端口。解决思路是在配置里显式指定 SSH 端口。除了前面提到的gitlab_rails[gitlab_shell_ssh_port]还需要修改/etc/gitlab/gitlab.rb里的 Linux 包 Shell 配置项gitlab_rails[gitlab_shell_ssh_port] 2222 gitlab_shell[ssh_port] 2222改完一样是 reconfigure。重新生成后项目页面上的 clone 地址就会变成ssh://gitgitlab.local:2222/group/project.git这种带端口的格式团队成员直接复制就能用不用再手动改。这里我要额外提醒一点如果你通过改sshd_config的Port来改 SSH 端口记得同时把 firewalld 里的对应端口放行不然外部根本无法连接到 SSH。5.3 备份与恢复GitLab 升级前的保命符RPM 手动安装的人有个优势对版本和目录结构相对清楚备份恢复思路也更清晰。GitLab 备份分为两部分缺一不可。第一部分是应用数据和仓库数据通过内置命令备份sudo gitlab-backup create备份文件默认生成在/var/opt/gitlab/backups/文件名类似1700000000_2025_01_01_17.0.0_gitlab_backup.tar。第二部分是配置文件备份很多人会漏掉这个。/etc/gitlab/gitlab.rb和/etc/gitlab/gitlab-secrets.json这两个文件必须一起备份。尤其是gitlab-secrets.json里面保存了 GitLab 各种加密密钥丢了会导致数据库里的某些敏感信息无法解密。我的做法是手动 copy 一份到备份目录sudo cp -a /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/恢复的思路也很直接# 停止相关服务避免数据写入冲突 sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq # 恢复指定备份文件名里的时间戳部分 sudo gitlab-backup restore BACKUP1700000000_2025_01_01_17.0.0 # 恢复配置文件前先备份现有配置再覆盖回去 sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab.rb.bak sudo cp /path/to/backup/gitlab.rb /etc/gitlab/gitlab.rb sudo cp /path/to/backup/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json # 重新加载配置并启动所有服务 sudo gitlab-ctl reconfigure sudo gitlab-ctl restart恢复完以后建议第一时间登录页面确认项目、用户、CI/CD 变量是否都正常然后再让团队回归验证。这句一定要记住升级前不做备份就是在拿生产数据赌博。我见过太多人升级 GitLab 翻车最后只能靠备份回滚。6. 踩坑实录内网环境安装时的完整问题排查记录最后这部分我把它写成一份“如果不是亲身踩过很难写出来”的排查记录。全部来自我实际部署 GitLab 时遇到的真实问题时间线是跨了多个项目的。6.1 postfix 起不来邮件功能半残有次在线安装 GitLab做到 reconfigure 那一步日志一直卡在邮件发送相关的检查上。后来排查发现是 postfix 没起来再往下挖是sshd服务没起来导致 postfix 初始化脚本里依赖检查失败。对你没看错postfix 挂掉的根因是 sshd 没启动这种“连环坑”在没有经验的情况下真的很难第一时间定位。处理方式很简单先确保 sshd 起来再单独启动 postfix最后回到 GitLab 的 reconfiguresudo systemctl start sshd sudo systemctl enable sshd sudo systemctl start postfix sudo systemctl enable postfix sudo gitlab-ctl reconfigure后续我再装机第一件事永远先检查sshd和postfix两个服务的运行状态没有再启动不然后面一堆问题。6.2 磁盘被日志堆满git 仓库目录迁移到数据盘上个月刚帮一台跑了大半年的 GitLab 服务器做“减负”。那台机器当时/根分区只有 40GBGitLab 默认把仓库数据放在/var/opt/gitlab/git-data日志放在/var/log/gitlab主分区很快就满了。等用户开始抱怨git push报fatal: unable to write file的时候问题已经很严重。我当时的处理思路是把 GitLab 的仓库数据目录整体迁移到另外一块大容量数据盘。具体操作可以参考下面的流程但不要直接在业务高峰期执行建议先维护一段时间。检查当前磁盘使用确认数据盘路径假设新数据盘挂载在/datadf -h停止 GitLab 相关服务防止迁移过程中有新的数据写入sudo gitlab-ctl stop创建新目录并迁移仓库数据sudo mkdir -p /data/gitlab/git-data sudo mv /var/opt/gitlab/git-data /data/gitlab/git-data修改/etc/gitlab/gitlab.rb指定新的仓库存储路径git_data_dirs({ default { path /data/gitlab/git-data } })重新配置并启动然后检查仓库是否正常sudo gitlab-ctl reconfigure sudo gitlab-ctl start顺手把日志目录也做一下软链接迁移sudo mv /var/log/gitlab /data/gitlab/logs sudo ln -s /data/gitlab/logs /var/log/gitlab其实更省心的做法是刚开始装 GitLab 时就把数据目录定位到大分区。如果你是第一次装强烈建议先把git_data_dirs写在配置里避免后期迁移。6.3 升级大版本时按官方升级路径一步步走GitLab 的版本升级策略不是“你想跳几级跳几级”。从老版本直接跨大版本升级数据库迁移经常失败。官方会给出升级路径。比如要从 15.x 升到 17.x中间一般要经过 16.x 的某个特定小版本过渡不能直接跳。我踩过最痛的一次坑是在一台老机器上从 13.4 直接升级到 14.0结果数据库迁移中途报错导致服务一直没有起来。后来学乖了凡是跨大版本升级都会确认当前版本到目标版本之间需要经过哪些中间版本然后一个个 RPM 包按顺序升级每升一步做一次完整备份。以手动安装为例升级操作本身不复杂# 先备份 sudo gitlab-backup create sudo cp -a /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /var/opt/gitlab/backups/ # 下载并安装新版本 rpm sudo yum localinstall -y gitlab-ce-新版本.rpm # 重新配置并重启 sudo gitlab-ctl reconfigure sudo gitlab-ctl restart升级完成后用/opt/gitlab/version-manifest.txt或登录页面查看当前版本确认升级成功。顺便检查 GitLab 是否正常运行具体可以看gitlab-ctl status和 Web 页面是否能打开。这里我强烈建议所有用 RPM 方式维护 GitLab 的人建立一张版本清单当前版本、内置组件版本、上次升级时间、备份文件位置、备份文件时间。别嫌麻烦这套信息在出问题的时候就是救命稻草。最后说几句自己的体会这套 RPM 手动安装的流程我从最早 GitLab 8.x 时代一路用到现在的 17.x前前后后装机部署至少二十次以上。中间踩过各种坑比如刚才写的 postfix 连环问题、磁盘堆满、大版本升级翻车都遇到过。现在反而觉得正是这些“折腾”让我对 GitLab 的组件关系有了比直接用 Docker 安装更清晰的理解——一旦出了问题我知道该去看哪个日志、查哪个服务而不是对着一个黑盒干瞪眼。如果你是我前面说的那三类读者之一我建议按照这篇文章的顺序完整地走一遍 RPM 安装流程。第一次可能会慢一点但走通一次以后你在任何内网离线环境里都能泰然自若。最后再分享一个我自己的小习惯每装完一台 GitLab顺手把执行过的关键命令、修改过的配置项连同踩坑记录写到本地的运维笔记里。下一次再安装直接照着自己的笔记走效率比全网搜教程高一倍。