先说个我自己的场景给你们听。去年公司要搭一套内部代码仓库老板给的条件是数据不出内网、不想掏钱买商业版、还要能撑起几十个研发日常的 push/pull。前前后后对比了几套方案最后还是选了 GitLab 社区版。原因很简单GitLab 不止是个 Git 仓库它把 issue、MR、CI 全都揉在一起了团队规模不大的时候一台机器就能打通研发全流程。真正上手之后才发现GitLab 安装配置这事儿网上教程虽然多但要么跳步要么环境和你不一样跟着敲完 command 还是一堆 502、权限错误、clone 地址不对之类的幺蛾子。所以我这次把完整的实操过程重新整理了一遍从服务器准备、安装方式选型到 gitlab.rb 关键参数、备份恢复再到和 Jenkins、GitLab Runner 联动时踩过的坑全部按实际执行的顺序写出来。不管你是第一次接触 GitLab 的新手还是已经装过但被各种细节折磨过的运维这篇应该都能帮上忙。1. 环境准备与安装方案选型1.1 服务器配置与系统要求GitLab 是个典型的“麻雀虽小五脏俱全”的架构它自带 Nginx、PostgreSQL、Redis、Puma 这一整套组件所以对内存的胃口绝对不小。官方文档给出的最低配置是 4GB 内存我实际用下来感觉 4GB 是“能跑”但跑 CI 或者多人同时提交的时候会明显卡建议有条件直接上 8GB。2GB 的机器也不是不能装但装上之后你会亲眼看着内存占用飙到 90% 以上然后频繁触发 OOM页面时不时给你来一个 502。系统方面我这次用的是 CentOS 7.964 位内核 3.10 以上。Ubuntu 系、Debian、Rocky Linux 也都一样能装只是包管理命令不同核心逻辑完全一致。硬盘建议用 SSD尤其是存放 Git 仓库的分区机械盘在仓库多了以后git gc和页面响应都会非常难受。另外单独划一个数据盘存放 Git 仓库数据是种好习惯后面做备份和扩容都省事别把系统盘和数据盘混在一起。安装前我把防火墙和 SELinux 的处理也放在前面说。如果你在内网环境最简单的做法是直接关闭 firewalld因为 GitLab 的 Nginx 要监听 80/443 端口防火墙策略配置不当会白白折腾半天。如果公司安全要求不能关防火墙就只放行需要的端口systemctl stop firewalld systemctl disable firewalld # 或者只放行端口 firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --reloadSELinux 我建议先临时改成 permissive 模式等 GitLab 跑通了再按需恢复。虽然 GitLab 官方提供了 SELinux 策略包但生产环境里因为 SELinux 拦截导致 Nginx 反代失败的情况我见过太多次了新手阶段没必要跟它死磕。1.2 三种主流安装方式怎么选GitLab 官方主要提供三种安装方式Omnibus 包安装、Docker 容器部署、源码安装。源码安装我直接劝退组件多、依赖版本敏感、升级麻烦除非你有特殊定制需求否则完全是给自己找罪受。剩下两种是绝大多数团队实际在用的。安装方式适用场景优点缺点Omnibus RPM/DEB 包生产环境首选组件整合度高一条命令装完gitlab-ctl统一管理占用系统资源较高升级偶遇依赖冲突Docker 部署已有 K8s/Docker 环境环境隔离迁移方便一台宿主机可跑多套实例数据卷和端口映射需要仔细设计排障隔了一层离线 RPM 包内网隔离环境不依赖外网仓库可批量铺到多台机器依赖包需要手动收集版本锁定后升级麻烦我个人生产环境更偏向 Omnibus 包因为 GitLab 的依赖全部打成 RPM 包了yum 管理起来干净gitlab-ctl的命令也直接Docker 方案虽然部署快但数据卷权限、容器内日志排查都多一层对不熟悉 Docker 的运维来说反而更容易翻车。如果你是完全离线的内网环境那就在一台能上外网的机器上把 Omnibus 包和所有依赖下载好打包传进内网再rpm -ivh安装。依赖收集用yum install --downloadonly --downloaddir/path就能搞定GitLab 主包则直接从官方仓库下载对应系统版本的 rpm 文件。1.3 域名规划这件事千万别偷懒安装之前先想好 GitLab 将来用什么地址访问这个特别重要。很多人上来就装装完才发现 clone 地址显示的是http://192.168.1.100/root/project.git这种 IP 形式后患无穷。如果你有内部 DNS先给 GitLab 分配个域名比如gitlab.example.com没有 DNS 就在需要访问的机器上改 hosts 文件也行。域名提前规划好后面配置external_url时直接用域名clone 地址、CI/CD 里回调地址、Webhook 地址全部都会自动继承这个域名能省掉后面一堆别扭事。IP 也能当作external_url用但等哪天 IP 变了你得去改配置重新 reconfigure团队所有人还要重新改 remote 地址这酸爽我经历过一次就不想再来第二次了。2. GitLab 安装与最关键的首轮配置2.1 用 Omnibus 包一步步装下来我自己最常用的安装路径是直接添加 GitLab 官方 yum 源然后 yum 安装。先装依赖和邮件服务sudo yum install -y curl policycoreutils openssh-server perl sudo systemctl enable sshd sudo systemctl start sshd # 安装 postfix用于 GitLab 发通知邮件 sudo yum install -y postfix sudo systemctl enable postfix sudo systemctl start postfix然后添加 GitLab 官方源并执行安装这里以 ce 版为例curl -s https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash sudo EXTERNAL_URLhttp://gitlab.example.com yum install -y gitlab-ce你如果注意到我在安装的同时直接指定了EXTERNAL_URL环境变量。这是 GitLab 安装流程里第一个关键点它会被写进/etc/gitlab/gitlab.rb的external_url配置项。安装完成后如果不满意后面可以随时修改但要记住一点修改 external_url 后必须执行gitlab-ctl reconfigure让配置生效。安装速度取决于网络慢的时候十几分钟也正常因为 GitLab 的包体积将近 1GB里面把 PostgreSQL、Redis、Nginx 这些全带上了。装完之后先别急着访问我习惯先把基础配置改了再启动避免反复 reconfigure 浪费时间。2.2 gitlab.rb 里那几个决定命运的配置项/etc/gitlab/gitlab.rb是 GitLab 的总配置文件几百行全是注释看着吓人但其实真正要动的就那么几个。我用vim /etc/gitlab/gitlab.rb打开逐个调整核心项。# 访问地址改成你的域名http 或 https 都行 external_url http://gitlab.example.com # 时区默认 UTC 会导致页面时间差 8 小时 gitlab_rails[time_zone] Asia/Shanghai # 数据存储路径默认在 /var/opt/gitlab建议改到数据盘 # git_data_dirs({default {path /data/gitlab}}) # 邮件配置以 SMTP 为例这里先留空后面单独讲 # gitlab_rails[smtp_enable] true有几个参数我特别提醒一下。一是external_url它后面有没有端口号有讲究。如果你用默认的 80 端口直接写http://gitlab.example.com如果服务器 80 端口被占了想用别的端口比如 8081就要写成http://gitlab.example.com:8081GitLab 内置的 Nginx 会自动监听这个端口不需要再单独改 Nginx 配置。二是 Puma worker 数量。默认配置是puma[worker_processes] 2你要是给 GitLab 分配的内存不多这个数字别往大调4GB 内存的机器跑 2 个 worker 就够用了。反之内存充足的情况下可以调大一点并发能力有明显提升。三是git_data_dirs。Git 仓库默认存在/var/opt/gitlab/git-data如果根分区空间不大一定要在安装前就把这个路径改到独立数据盘。注意路径指的是/data/gitlabGitLab 会在它下面自动创建repositories子目录。改完之后执行sudo gitlab-ctl reconfigure这一步会初始化所有组件时间比较长日志在不断滚动耐心等它跑完。结束之后执行sudo gitlab-ctl status应该能看到run: nginx: (pid xx) running这样的输出并且puma、postgresql、redis都在运行状态。2.3 初始化管理员账号与密码找回第一次打开http://gitlab.example.com时页面会要求你设置 root 管理员的初始密码至少 8 位。这块有个常见情况如果你安装时没走这个引导页或者忘记密码了可以直接进数据库重置。GitLab 社区版的管理员账号默认就是 root。我推荐用 Rails 命令来重置简单稳定sudo gitlab-rails console进入交互式控制台后执行user User.where(username: root).first user.password 新密码 user.password_confirmation 新密码 user.save!然后退出用新密码登录。代码里如果返回true就说明保存成功如果返回false一般是密码太弱或者两次输入不一致重新赋值再保存。还有一点容易被忽略GitLab 默认允许任何人注册账号。对于公司内网使用我建议关掉或者只允许管理员创建用户不然内网所有人都能自己注册仓库权限管控就形同虚设了。位置在“Admin Area - Settings - General - Sign-up restrictions”取消勾选 Sign-up enabled 保存即可。2.4 离线部署的特殊处理上面提到离线环境这里补充下实际中几个容易出问题的点。离线安装 GitLab 时光有 gitlab-ce 的 rpm 包不够它依赖policycoreutils-python、openssh-server、postfix这些系统包。在一台能联网的同版本 CentOS 机器上用下面的命令把依赖全抓下来mkdir -p /tmp/gitlab-offline yum install -y --downloadonly --downloaddir/tmp/gitlab-offline \ gitlab-ce policycoreutils-python openssh-server postfix然后把/tmp/gitlab-offline整个目录拷到内网机器执行cd /tmp/gitlab-offline rpm -ivh *.rpm离线安装后同样要执行sudo gitlab-ctl reconfigure。如果你嫌在主仓库下载太大也可以找人从能上网的环境里导出 gitlab-ce 的 rpm 包但版本一定要和 CentOS 大版本匹配CentOS 7 的包跑到 CentOS 8/9 上是装不上的。3. 核心功能配置与日常运维要点3.1 SSH 免密、clone 与首次 pushGitLab 装好只是万里长征第一步接下来团队要能正常拉代码、推代码。HTTP 方式虽然也能用但每次都要输账号密码而且 GitLab 新版把 HTTP 方式的密码验证改成了需要 Personal Access Token很多人一头雾水。我建议直接把 SSH Key 配好一劳永逸。在客户端电脑上不是服务器生成密钥ssh-keygen -t ed25519 -C userexample.com一路回车默认生成在~/.ssh/id_ed25519.pub。然后查看公钥内容cat ~/.ssh/id_ed25519.pub复制完整内容登录 GitLab 后进入 Preferences - SSH Keys把公钥粘进去保存。接着测试连接ssh -T gitgitlab.example.com如果输出Welcome to GitLab, username!就说明通了。这里有个小坑如果 GitLab 的 SSH 端口不是默认的 22你需要先看下/etc/gitlab/gitlab.rb里的gitlab_rails[gitlab_shell_ssh_port]配置。当服务器 22 端口被别的服务占用时可以把 GitLab SSH 端口设成 2222gitlab_rails[gitlab_shell_ssh_port] 2222改完 reconfigure然后 clone 地址会显示为ssh://gitgitlab.example.com:2222/group/project.git客户端使用 SSH 时也要用-p 2222参数或者给~/.ssh/config指定端口不然默认还是连 22 端口直接失败。这个属于典型的“配置了但没生效”的坑排查时的第一反应应该是去看 clone 地址里的端口号。首次 push 命令其实没什么特别git init git add README.md git commit -m first commit git remote add origin gitgitlab.example.com:group/project.git git push -u origin main需要留意的是默认分支名GitLab 默认初始分支是 main有些人习惯 master可以在“Admin Area - Settings - Repository”里改全局默认分支名省得每次创建项目都手动去调。3.2 clone 地址显示机器ID而不是域名怎么处理这个可是高频搜索词而且特别多人中招。现象是在 GitLab 项目页面点“复制”按钮clone 地址显示的是http://gitlab-2c4g-xxxx/root/demo.git这种带机器IDhostname的地址而不是你想要的域名。原因很简单external_url没配对或者安装时系统 hostname 是默认的gitlab-2c4g-xxxx安装脚本自动把 hostname 写进了 external_url。解决办法就是改/etc/gitlab/gitlab.rb里的external_url改成你规划的域名然后执行sudo gitlab-ctl reconfigure改完再去项目页面刷新clone 地址就变成http://gitlab.example.com/root/demo.git了。这里我要强调一下安装之后再改 external_url虽然 reconfigure 会重新生成 Nginx 配置、更新 Git 仓库的 remote URL 相关配置但旧地址如果被写在某些项目的 webhook 或 CI 配置里需要手动去改。所以我在开头反复说域名要提前规划安装时就把 external_url 设置好能省掉这些后续麻烦。如果你是在反代后面用域名访问内网 GitLab 的 Nginx 监听端口不一定是 80那 external_url 里就必须带上外部访问的端口比如http://gitlab.example.com:8080这样才能保证页面链接、clone 地址都是对的。3.3 SMTP 邮件通知配置GitLab 的站内通知、密码找回、MR 提醒都依赖邮件服务。默认配置走的是本机 postfix很多内网服务器发不出去外网邮件这时就要配一个 SMTP 地址。我用的是公司邮箱服务配置如下gitlab_rails[smtp_enable] true gitlab_rails[smtp_address] smtp.example.com gitlab_rails[smtp_port] 465 gitlab_rails[smtp_user_name] gitlabexample.com gitlab_rails[smtp_password] your-password gitlab_rails[smtp_domain] example.com gitlab_rails[smtp_authentication] login gitlab_rails[smtp_enable_starttls_auto] true gitlab_rails[smtp_tls] true gitlab_rails[gitlab_email_from] gitlabexample.com如果你用的是 25 端口或 587 端口注意别开smtp_tls在smtp_enable_starttls_auto true的情况下它会自动升级到 TLS。改完执行sudo gitlab-ctl reconfigure然后可以用下面的方法测试邮件是否正常发出sudo gitlab-rails console Notifier.test_email(destexample.com, Test Subject, Test Body).deliver_now如果收不到邮件第一反应查日志sudo tail -f /var/log/gitlab/gitlab-rails/production.log日志里通常会给出 535 认证失败或超时这类准确原因比瞎猜强得多。3.4 备份与恢复备份这事我在真实环境里见过太多“出事了才想起来没备份”的案例了。GitLab 的备份命令很简单但有几个注意点必须说。首先确认备份目录空间默认在/var/opt/gitlab/backups配置文件里也可以改gitlab_rails[backup_path] /data/gitlab-backups然后执行备份sudo gitlab-backup create备份文件是一个 tar 包。这里有个关键点gitlab-backup create默认只备份 Git 仓库、数据库、上传文件不包含/etc/gitlab/gitlab.rb配置文件。所以完整的备份必须手动把/etc/gitlab/整个目录也拷走不然恢复后配置全丢等于半残。我的习惯是把备份写进 crontab0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON1 5 2 * * * tar czf /data/config-backup/gitlab-config-$(date %F).tar.gz /etc/gitlab恢复操作反而不常用但必须知道。先把备份文件放到 backups 目录然后sudo gitlab-ctl stop puma sudo gitlab-ctl stop sidekiq sudo gitlab-backup restore BACKUP时间戳文件名 sudo gitlab-ctl reconfigure sudo gitlab-ctl restart恢复时会提示task gitlab_backup is already running之类的情况其实是 puma 和 sidekiq 没停干净用gitlab-ctl status确认这两个服务状态是 down 再执行恢复。另外恢复前如果之前的数据还在建议先清掉再恢复避免冲突。3.5 版本升级与漏洞修复思路GitLab 的热搜词里有个“gitlab高危漏洞修复方案”其实核心就一句话保持版本更新。GitLab 官方对安全漏洞的反应算是快的高危漏洞通常会同步发布修复版本你只要及时升级就能堵住大部分问题。升级前切记先备份特别是跨大版本升级时比如 14.x 升 15.x需要一步步升级而不是直接跳。GitLab 官方提供 upgrade path 工具用来检查你的版本路径是否合法跳过太多版本直接升的话 reconfigure 时很容易出兼容性错误。升级操作一般是sudo yum update gitlab-ce sudo gitlab-ctl reconfigure sudo gitlab-ctl restart如果是在线 yum 源安装的一条 update 就能拉到最新版。升级过程中我会盯着两个指标一是磁盘空间before 和 after 都要确认GitLab 每次升级都会备份一部分数据空间不足会导致升级中断二是升级后检查gitlab-ctl status确认 postgresql、redis、puma、nginx 都正常拉起。GitLab 这个团队更新速度是真的快养成“发布后两周内升级”的习惯能躲开后知后觉的漏洞利用。4. 与 CI/CD 联动Jenkins、Runner 与镜像构建4.1 Jenkins 配置 GitLab Connection 时最常见的那个报错很多团队会保留 Jenkins 作为持续集成入口GitLab 只做仓库管理这时需要在 Jenkins 的“系统管理 - 系统配置”里配置 GitLab 连接。添加一个 GitLab connectionURL 填 GitLab 地址Credentials 选择 GitLab API Token。实际操作中大家最常遇到的就是标题里那条login failed. check api token or gitlab version. log in via git if the versi ...排查思路分成三步走。第一步确认你创建的 Token 类型对不对。GitLab 新版界面中创建 Personal Access Token 时注意两点有效期别选太短scope 至少勾选api和read_user。有些教程会误导你只用read_repository结果 Jenkins 拉取项目列表时照样失败。第二步看 GitLab API 是否可达。在浏览器里直接访问curl -I --header PRIVATE-TOKEN: 你的token http://gitlab.example.com/api/v4/user返回 200 并且有 JSON 数据说明 API 没问题如果 401 或 403就是 Token 权限不够返回 404 则要检查 URL 路径是否正确。第三步注意 Jenkins 的 GitLab 插件版本要和 GitLab 版本兼容。老版本 Jenkins 插件用的认证接口在 GitLab 新版本里被移除了就会出现“check api token or gitlab version”这种提示。解法是把 Jenkins 插件升到最新或者改用 GitLab 的 OAuth 方式认证。真正稳定跑起来之后Jenkins 里使用 Git 类型的凭据时也能选 GitLab API token 作为凭据来源还能自动帮你创建 SSH key 并类推到 GitLab 用户下这个功能对批量配置流水线的场景非常省事。4.2 GitLab Runner 注册与一个能跑的 .gitlab-ci.yml说 GitLab CI/CD 之前先装 Runner。Runner 是独立组件不要求装在同一台机器上。安装方式同样用官方仓库curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash sudo yum install -y gitlab-runner安装完注册注册的时候需要两个关键信息GitLab 实例地址和注册 token。token 在哪找“管理员 - 设置 - CI/CD - Runner”里能看到共享 Runner 的注册地址和 token或者某个项目下的“项目 - 设置 - CI/CD - Runner”也能拿到项目级 token。sudo gitlab-runner register执行后按提示填 URL 和 tokenexecutor 我推荐选docker这样每次 job 都在干净环境里跑不受宿主机污染。如果选shell那 Runner 所在机器上必须装好 Git、JDK、Node、Docker 这些依赖每次构建都依赖宿主机环境出问题不好排查。注册完成后在 GitLab 后台对应 Runner 状态会变成绿色。CI 配置方面最简化但能说明问题的流水线长这样stages: - build - deploy build-job: stage: build image: node:18-alpine script: - npm ci - npm run build artifacts: paths: - dist/ deploy-job: stage: deploy before_script: - command -v docker || (echo Docker not found exit 1) script: - docker build -t registry.example.com/myapp:$CI_COMMIT_SHORT_SHA . - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD registry.example.com - docker push registry.example.com/myapp:$CI_COMMIT_SHORT_SHA only: - main这段配置的工作流程是代码推到 main 分支后先在 Node 镜像里构建前端产物然后利用 Runner 机器上的 Docker 构建镜像并推送到镜像仓库。如果你用 GitLab 自带的 Container Registry把registry.example.com换成你 GitLab 的域名和项目路径就行。和 Jenkins 相比GitLab CI 的好处是全流程都留在同一个平台里.gitlab-ci.yml跟着代码走改动通过 MR 审阅团队不用在多个系统间来回切换。但 Jenkins 在插件生态和复杂流水线的自由度上仍然有优势到底用哪个取决于团队现状没有绝对的谁更优。4.3 Docker 镜像构建与自动化部署的完整闭环现在团队里最常见的交付物就是一个 Docker 镜像CI/CD 流水线的终点就是把镜像推到仓库然后触发部署。我在上面那段 .gitlab-ci.yml 里已经写到了镜像构建和推送这里再补充一个细节让部署更自动化可以在 push 成功后调用目标服务器的部署接口或者用 SSH 远程执行新的发布脚本。一个比较稳妥的做法是在 Runner 上配置 SSH 免密登录到目标服务器然后推送完镜像之后执行远端命令ssh deploydeploy-server docker pull registry.example.com/myapp:$CI_COMMIT_SHORT_SHA docker stop myapp || true docker run -d --rm -p 8080:80 registry.example.com/myapp:$CI_COMMIT_SHORT_SHA这个过程可以用一个 shell 脚本包起来也可以在 .gitlab-ci.yml 里写成一个 deploy job。需要注意两点SSH 私钥要妥善保存在 GitLab 项目的 CI/CD Variables 里别写进仓库目标服务器的 Docker 环境要和 Runner 环境分开避免 Runner 自己 docker 嵌套 docker 产生的权限和网络问题。自动化部署真正跑通的那一刻会很有成就感但生产环境使用前要加审批环节。GitLab 有 protected environment 功能可以限制只有 Maintainer 角色才能触发生产环境部署这个建议打开。5. 高频问题排查速查表与避坑心得5.1 直接照着排查的故障表GitLab 装多了之后你会发现出现问题翻来覆去就那么几类。我整理了一个排查表按“现象 - 可能原因 - 解决方向”来排直接照着查就行。现象可能原因解决方向页面 502 或一直转圈Puma/PostgreSQL 起不来或内存不足gitlab-ctl status查看组件状态gitlab-ctl tail puma看日志确认内存是否溢出clone 地址显示机器ID而不是域名external_url 配置不对改/etc/gitlab/gitlab.rb的 external_url 后 reconfigureSSH 方式 clone 报 Permission denied公钥没配好或端口不是 22检查 SSH Key 内容、端口设置ssh -T git域名测试HTTP clone 总是要求输密码新版 GitLab 要求用 Personal Access Token 代替密码创建 Personal Access Token 后用它作为密码Jenkins 报 login failed. check api token or gitlab versionToken 权限不足或插件版本不兼容更新 Jenkins GitLab 插件确认 Token 有 api scopegitlab-ctl reconfigure卡住超时磁盘空间不足或数据库迁移慢查看/var/log/gitlab下的日志释放磁盘空间后重试收到大量邮件轰炸Webhook 配置错误或 CI 死循环检查项目 Webhook 设置、CI 触发规则上传大文件一直失败Nginx 上传大小限制修改nginx[client_max_body_size]5.2 从搜索热词里看大家被困惑的点写这篇文章的时候我专门去看了下相关的搜索结果发现用户最高频的困惑集中在几个点上一是“gitlab使用教程”说明上手后的功能探索需求很多二是“docker安装gitlab”说明容器化部署是很多人的第一选择三是“linux离线部署gitlab”说明内网环境占比不小还有一类是围绕 Jenkins、GitLab Runner 和 CI/CD 的联动问题。这块我上面几节都覆盖到了。这里再补一个容易被搜到但不一定理解透的点Docker 部署 GitLab 时端口映射。很多人照着docker run命令跑起来却忘了 GitLab 容器里 Nginx 默认监听 80 端口所以宿主机映射时要写成-p 8080:80而不是-p 8080:8080。同时external_url必须写成http://gitlab.example.com:8080端口号要和宿主机映射的外部端口一致否则容器内生成的链接还是 80 端口。这个错位问题我在好几个同事的电脑上见到过。5.3 几条踩过坑才记得住的实战心得第一千万别在业务高峰时段执行 reconfigure 或升级。GitLab 的 reconfigure 会触发组件重启看起来只是重启实际体验上短则几十秒长则几分钟的不可用。我前几年有一次午休时间改了配置顺手 reconfigure正好赶上团队发版本页面直接白屏那种被开发同事连环问“服务器怎么了”的场景给我留下了深刻的心理阴影。第二备份脚本一定要定期验证不只是执行成功就完事。执行gitlab-backup create成功不代表备份文件可恢复。我的做法是每个月挑一台测试机做一次完整恢复演练把备份恢复到临时目录里启动一个临时 GitLab 实例验证数据完整性。这个习惯帮我在真正的“删库跑路”风险面前保住过项目数据值得养成。第三PostgreSQL 升级要多留一个心眼。GitLab 大版本升级时经常伴随内置 PostgreSQL 的主版本升级比如从 12 升到 13这个过程会有数据迁移耗时很长。如果你的仓库特别多迁移期间 CPU、磁盘 IO 都会很高建议提前通知团队暂停 push。升级前把gitlab-ctl status的组件版本截图保存升级失败时方便回滚对比。第四系统盘的 inode 也可能爆。GitLab 的仓库数量多、小文件多经常是磁盘空间还有剩余但 inode 已经占满表现为No space left on device。所以规划数据盘时不要只看容量还要关注文件系统类型ext4或xfs在 inode 方面都比较好如果日志文件或临时文件堆积导致 inode 耗尽优先清理/var/log/gitlab下的旧日志。结尾这套 GitLab 环境目前在我这边已经稳定运行了挺长时间从一开始只想搭个代码仓库到后来顺手把 issue、CI/CD、自动部署都拉通了团队协作效率提升是很明显的。回头看整个安装配置过程脚本化和可复现是最大的体会任何一步不要靠“人肉记忆”都写进运维文档或者自动化脚本里换机器、加环境的时候能省下成倍的时间。如果你还在纠结装 GitLab 还是用其他代码托管平台我的建议是在内网环境下GitLab 社区版依然是综合体验最完整、社区资料最丰富的那一个。最后分享一个实用小技巧——无论你是装在物理机还是容器里都记得给 GitLab 配置独立的备份目录和定时任务数据安全这件事永远不要建立在“应该没问题”的假设上。