1. 为什么我还在 CentOS 7 上搭 GitLab方案选型与真实取舍先说结论如果你手头正好有一台 CentOS 7 服务器又不想把代码托管到公共平台想自己搭一套 GitLab 做内部代码仓库和 CI/CD那这篇东西就是给你写的。我会把从零初始化系统、安装 GitLab 社区版、配 SSH、跑通仓库推送拉取再到接 Jenkins、配置 GitLab Runner 做自动化构建部署的完整路径都过一遍。新手能照着做老手也能看我在哪些坑里摔过。我在实际项目里见过太多人一上来就问“GitLab 怎么装”结果装完连 web 界面都打不开或者打开以后 push 代码一直要密码又或者 CI 跑不起来。这些问题绝大多数不是 GitLab 本身难用而是没搞清楚它依赖什么、配置了什么、端口和权限哪里不对。所以这篇文章不会只给命令我会把每个关键步骤后面的为什么也说清楚。先说 CentOS 7 这个选择。曾经 CentOS 7 是服务器领域绝对的主力虽然它的生命周期已经结束但大量企业内部服务器至今还跑着它很多云厂商的镜像市场里 CentOS 7 依然挂着。如果你所在团队已经有存量 CentOS 7或者你只是想在虚拟机里先练手那用它装 GitLab 完全没问题。比 CentOS 7 更老旧的系统装 GitLab 会很痛苦因为 GitLab 依赖的 glibc、Ruby、PostgreSQL 版本都偏新而 CentOS 8 或 Stream 也不是不好只是在很多公司里 7 的存量惯性太大运维脚本、防火墙策略、内核参数全是按 7 调的。所以我的建议是新环境优先选更新的系统但如果你就是要在 CentOS 7 上做也没必要慌按下面这套流程走完效果一样稳。我还会穿插讲一下 Docker 安装 GitLab 的方式。热词里有很多人搜“docker安装gitlab”说明容器化部署已经成了主流习惯。确实用 Docker 跑 GitLab 能绕开一堆依赖冲突问题备份和迁移也简单。但 Docker 跑 GitLab 同样有坑特别是数据目录、端口映射、容器重启策略这三块配置错了照样崩。我会把两种方式都写出来你根据自己环境选。2. 安装前的准备硬件评估、系统初始化与依赖检查2.1 资源预算与内存交换分区配置GitLab 是个资源大户这是很多人第一次装它时没概念的地方。官方文档给过一个参考值4GB 内存大概能支撑 500 个用户的小团队1GB 内存也能跑起来但非常勉强UNICORN 进程动不动就 OOM。我实测下来的感受是如果只是个人用或者三五人小团队2GB 内存 2GB swap 是最低可用的底线4GB 内存跑起来就比较舒服了。CPU 至少 2 核否则 Web 界面响应会明显卡顿。CentOS 7 默认可能没有 swap 或者 swap 很小。安装 GitLab 之前我强烈建议先把 swap 准备好尤其内存不足 4GB 的机器。创建 swap 的方式很简单# 创建一个 4GB 的 swapfile dd if/dev/zero of/swapfile bs1M count4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 写入 fstab 使开机自动挂载 echo /swapfile swap swap defaults 0 0 /etc/fstab # 调整 swappiness 提升缓存效率 sysctl vm.swappiness10 echo vm.swappiness10 /etc/sysctl.conf这个步骤很多人会跳过但等 GitLab 跑到一半进程被杀再回来补就太被动了。我在一台 1GB 内存的测试机上试过不配 swap 的时候跑 gitlab-ctl reconfigure 都能直接把进程卡死配了 swap 至少能顺利完成安装和基础操作。2.2 系统基础设置主机名、时钟、防火墙与 SELinux准备好资源以后先把系统基础环境理清。这里每一步都有目的不是为了走流程。主机名和 hostsGitLab 的 external_url 会用到主机名如果你不想每次访问都敲 IP最好提前设置一个规范的主机名hostnamectl set-hostname gitlab.example.local echo 192.168.1.100 gitlab.example.local /etc/hosts注意这个主机名千万别随便用带下划线的GitLab 的 NGINX 配置对这类主机名处理起来很别扭访问时容易出证书域名不匹配的怪问题。时间同步GitLab 的日志、SSH key 有效期、CI 任务记录全部依赖系统时间。CentOS 7 默认用的是 chrony检查一下有没有在运行systemctl status chronyd # 如果没装就 yum install -y chrony systemctl start chronyd时间不准的机器上配 GitLab最典型的表现是 push 代码时提示证书校验失败排查半天结果发现是系统时间差了好几分钟。防火墙CentOS 7 自带 firewalld很多人装完 GitLab 后网页打不开八成都卡在这里。GitLab 主要会用到这几个端口服务默认端口HTTP80HTTPS443SSH22GitLab Pages80/443邮件发送25出方向如果不想折腾直接在防火墙里放行firewall-cmd --permanent --add-servicehttp firewall-cmd --permanent --add-servicehttps firewall-cmd --permanent --add-servicessh firewall-cmd --reload如果你把 SSH 端口改了记得放行对应端口不然 Git clone 会天天提示 connection refused。SELinux这是 CentOS 7 跟 Ubuntu 系最大的区别。SELinux 默认 enforcing 状态GitLab 官方 rpm 包已经带了 SELinux 策略理论上可以不开但实际部署中我见过太多因为策略冲突导致的权限诡异问题。我的建议是生产环境尽量开启 SELinux但如果你不熟悉它先把 GitLab 跑通再慢慢调策略。个人练手直接临时关闭最省心setenforce 0 sed -i s/^SELINUXenforcing/SELINUXpermissive/ /etc/selinux/config注意setenforce 0只是临时生效改 config 文件才能保证重启后不回到 enforcing。我用 permissive 而不是 disabled是因为 Per是指有日志但不拦截至少你能看到哪里冲突了。2.3 安装源与基础依赖CentOS 7 自带的 yum 源已经停止维护了很多基础包可能下载失败。这里要先把 yum 源替换成阿里云镜像否则后续装 GitLab 依赖时会非常痛苦# 备份原 repo cp -r /etc/yum.repos.d /etc/yum.repos.d.bak # 使用阿里云 CentOS 源 curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo # 清理缓存并重建 yum clean all yum makecache然后升级一下基础包yum update -y yum install -y curl policycoreutils openssh-server openssh-clients postfix perl这里特别说一下 postfix。GitLab 发送邮件通知需要 Mail 服务虽然不用 postfix 也能跑但在 web 界面里配置 SMTP 邮件服务之前系统本身最好有一个可用的 MTA。如果公司有现成的 SMTP 服务你也可以不装 postfix直接在 gitlab.rb 里配置gitlab_rails[smtp_enable] true然后指向你们自己的邮件服务器就行。3. GitLab 社区版安装与基础配置实战3.1 在线安装通过官方 RPM 仓库快速部署GitLab 分社区版 CE 和企业版 EE对大多数人来说 CE 完全够用CI/CD、代码仓库、Issue 跟踪这些核心功能一个不少。官方给了一个一键安装脚本但我不太建议直接用 curl 管道执行因为脚本行为不够透明。更稳妥的做法是手动添加仓库再装curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash如果你对这种方式有顾虑也可以直接配置仓库文件cat /etc/yum.repos.d/gitlab_gitlab-ce.repo EOF [gitlab_gitlab-ce] namegitlab_gitlab-ce baseurlhttps://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7 repo_gpgcheck0 gpgcheck0 enabled1 EOF yum makecache清华镜像源在国内访问速度明显比官方源快。装的时候指定 external_url这一步会同时完成安装和初始配置yum install -y gitlab-ce安装完成后第一次配置gitlab-ctl reconfigure这一步会跑很久因为它要初始化 PostgreSQL、Redis、NGINX、Sidekiq、Prometheus 等一系列组件。如果 strace 看它的执行过程你会发现它本质上就是把配置文件里的变量渲染到各个服务的配置里再逐个启动服务。我见过新手等不及直接 CtrlC结果留下一堆半初始化状态最后只能重装。所以 reconfigure 的时候耐心点一般 3 到 10 分钟都正常。3.2 离线安装内网环境的最省心方案很多企业服务器是不允许访问外网的这时候离线安装就是唯一的路。离线安装的核心是提前准备好 rpm 包和依赖。你可以找一台能联网的同架构 CentOS 7 机器先把 gitlab-ce 的 rpm 包下载下来# 用 yumdownloader 或直接到镜像站下载 yum install -y yum-utils yumdownloader gitlab-ce --resolve或者直接浏览器访问清华镜像目录挑一个具体版本比如gitlab-ce-16.10.8-ce.0.el7.x86_64.rpm。然后把 rpm 包传到内网机器上用 localinstall 安装yum localinstall -y gitlab-ce-*.rpm如果安装过程中提示缺依赖你就把依赖包也一并下载带进去。离线方式最麻烦的点在于 GitLab 版本升级因为你得手动下载新版 rpm 再执行升级没法像在线环境那样直接 yum update。但好处是版本可控不会出现某天早晨起来发现 GitLab 自动升级了导致不兼容的情况。3.3 基础配置external_url、时区与备份目录安装完成后最核心的配置文件是/etc/gitlab/gitlab.rb。这里面有几百项配置但刚起步只需要改几个关键项。external_url这是第一优先级的配置它决定了 GitLab 对外暴露的地址。如果是局域网内使用直接写成 IPexternal_url http://192.168.1.100如果你手头有域名并且想走 HTTPS可以写成external_url https://gitlab.example.com注意改成 https 之后GitLab 会用自带的自签名证书浏览器访问时会提示不安全。如果你想解决这个问题要么用官方或者第三方 CA 签发的证书要么在内部环境里把自签名证书导入到各台机器的信任库。时区与时间显示gitlab_rails[time_zone] Asia/Shanghai这个配置解决的是 Web 界面和 CI 日志里显示的时间跟本地时间差 8 小时的问题。很多人没设置然后发现提交记录时间不对还以为是代码问题。实际上是系统时区默认 UTCGitLab 显示出来的时间当然跟中国本地时间不一致。备份目录GitLab 默认备份目录是/var/opt/gitlab/backups如果你的系统盘空间不大建议改成独立磁盘或者 NFS 挂载点gitlab_rails[backup_path] /data/gitlab-backups改完任何配置都要重新执行gitlab-ctl reconfigure这是 GitLab 的规矩别只改不看效果。有些配置还需要重启对应服务比如改了 external_url 要重启 NGINXgitlab-ctl restart nginx。3.4 Docker 方式安装 GitLab另一种选择Docker 装 GitLab 确实能省掉很多依赖上的麻烦但注意网络和存储配置。我见过最多的问题是把容器内部的 22 端口映射到宿主机然后宿主机自己的 sshd 也在监听 22结果端口冲突容器起不来。推荐的映射方式是宿主机的 2222 映射到容器的 22docker run --detach \ --hostname 192.168.1.100 \ --publish 443:443 --publish 80:80 --publish 2222:22 \ --name gitlab \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest这里有几个关键点。第一--hostname不能随便填它会被写进容器的 GitLab 配置里作为 clone 地址的一部分。第二三个 volume 一定要挂出来否则容器一删数据就全没了。第三--restart always保证宿主机重启后容器能自动恢复。用 Docker 之后SSH 的 clone 地址会变成ssh://git192.168.1.100:2222/group/project.git因为宿主机 22 被占用了。你可以在 GitLab 的 web 界面里修改Projects-Settings-General-Visibility下面的端口设置也可以直接在 gitlab.rb 里改gitlab_rails[gitlab_shell_ssh_port] 2222来让界面显示正确的地址。Docker 方式跟 rpm 方式还有一个重要区别升级。rpm 方式升级是yum update gitlab-ce容器方式是拉新镜像再重建容器。后者虽然干净但要额外注意数据卷权限问题容器内的 git 用户 uid 是 998如果宿主机目录权限不对容器起来后 web 界面能打开但 Git 操作会报权限错误。4. 核心使用配置把仓库、SSH 与自动化流程跑通4.1 SSH 密钥配置与代码拉取推送GitLab 装好之后下一步就是让成员能正常 clone 和 push 代码。这里有个新手最容易困惑的点GitLab 账号的密码跟 Git 操作时用的认证是什么关系。GitLab Web 登录用账号密码但 Git 操作首选的是 SSH 密钥认证。你需要在本地机器上生成一对密钥然后把公钥粘贴到 GitLab 的 SSH Keys 设置里。# 本地生成密钥建议用 ed25519 ssh-keygen -t ed25519 -C your-emailexample.com # 查看公钥并复制 cat ~/.ssh/id_ed25519.pub然后登录 GitLab打开Preferences - SSH Keys把公钥粘贴进去保存。之后 clone 代码git clone git192.168.1.100:group/project.git如果你把容器方式的 SSH 端口映射成 2222那 clone 地址要带端口号git clone ssh://git192.168.1.100:2222/group/project.git第一次 clone 的时候会提示确认 host key输入 yes 即可。这之后就不会再问密码了。如果仍然让你输密码常见的排查思路是本地 ssh-agent 里没有加载密钥执行ssh-add ~/.ssh/id_ed25519。GitLab 账号对应的 SSH 公钥没配置对。SELinux 或防火墙拦截了 SSH 端口。用ssh -T git192.168.1.100测试连接看到Welcome to GitLab, username!这样的提示就说明通了。4.2 Group、权限与分支保护设计正常使用 GitLab一定不能一个人建一堆零散项目就完事了。GitLab 的逻辑是 Group 管理 ProjectMember 管理用户权限。Group 可以理解为一个团队或者部门一个 Group 下可以包含多个 Project。建议按照项目线划分 Group比如frontend、backend、devops。然后在 Group 设置里添加成员权限等级从低到高是 Guest、Reporter、Developer、Maintainer、Owner。日常开发给 Developer 就够了Maintainer 主要负责合并分支和修改项目设置Owner 一般是组长或者负责人。分支保护是很多人忽略但又特别重要的设置。GitLab 默认保护默认分支通常是 main 或 master意思是只有 Maintainer 以上权限能直接 push 到受保护分支Developer 需要走 Merge Request。这个机制能让团队养成提 MR 的习惯避免所有人都往主干上硬推。在Settings - Repository - Protected branches里可以调整谁有权限 push 和 merge。实际使用中我建议至少做以下几点默认分支统一为main新项目创建时直接设置。开一个develop分支做集成测试feature/*分支做功能开发。所有合并到main的操作都要求 MR 审核。开启 MR 的 pipeline 检查CI 不通过不允许合并。这些规则能在源头上把代码质量卡住而不是出了问题再靠人肉 review。4.3 Jenkins 连接 GitLab解决常见的 login failed 报错很多人会在热词里搜“jenkins配置gitlab connection”然后被login failed. check api token or gitlab version. log in via git if the version...这个报错折磨。这个错误在 Jenkins 配置 GitLab API token 时非常典型核心原因有三类。第一类是 token 权限不足。在 GitLab 创建 Personal Access Token 时需要勾选api权限。如果只勾了read_user或者read_repositoryJenkins 用它调 API 就会失败。重新生成一个 token勾上 api。第二类是 GitLab 版本跟 Jenkins GitLab Plugin 不兼容。老版本 GitLab 的 API v3 早被废弃了插件默认请求 v4如果 GitLab 太老确实会报 login failed。这个只能通过升级 GitLab 解决。第三类是 Jenkins 系统配置里的 URL 填错了。很多人填的是http://192.168.1.100但 GitLab 实际 external_url 是http://gitlab.example.com或者带了子路径导致 API 请求 404。需要检查 System Configuration 里的 GitLab host URL 是否跟 external_url 完全一致。在 Jenkins 这边正确的配置顺序是打开Manage Jenkins - Configure System。找到 GitLab 部分填入 Connection name、GitLab host URL。Credentials 类型选择GitLab API token把 token 粘进去。点 Test Connection看到 Success 就说明连上了。连上之后在 Job 里可以用 GitLab 提供的触发器比如 Merge Request 触发或 Push 触发。Jenkinsfile 里也通过 API token 去拉取 GitLab 仓库不再需要单独为 clone 配 SSH 密钥了。5. CI/CD 自动化部署GitLab Runner 与 Docker 镜像构建5.1 注册 GitLab RunnerGitLab 自带的 CI/CD 功能依赖 Runner。Runner 可以理解为执行 CI 任务的工人GitLab 服务器负责调度和记录日志Runner 负责真正跑任务。Runner 类型分三种Shared、Group、Project。小团队直接用 Project Runner 最省事在Settings - CI/CD - Runners里可以看到注册 token。安装 Runner 的官方方式是在独立机器或 Docker 容器里跑gitlab-runner。CentOS 7 上直接用 rpm 安装curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh | sudo bash yum install -y gitlab-runner然后注册gitlab-runner register注册过程中会问你 GitLab URL 和 registration token这两个都能在项目或 Group 的 Runners 页面找到。Executor 我建议选docker因为 CI 任务在容器里跑环境隔离好依赖冲突少。选 docker 之后还要设置默认镜像比如docker:24.0.7或者alpine:latest。注册完成后在 GitLab 的 Runners 页面能看到这个 Runner 变成绿色 online 状态。如果一直 offline检查 Runner 机器跟 GitLab 之间的网络尤其防火墙有没有放行 GitLab 的 443 或 80 端口。5.2 编写 .gitlab-ci.yml 构建 Docker 镜像并部署配好 Runner 后CI 的真正逻辑全写在项目根目录的.gitlab-ci.yml里。我下面给一个非常典型的例子代码推到 main 分支后自动构建 Docker 镜像推到私有镜像仓库然后 SSH 到部署服务器拉镜像并重启容器。stages: - build - deploy variables: IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHORT_SHA build: stage: build image: docker:24.0.7 services: - docker:24.0.7-dind script: - docker build -t $IMAGE_TAG . - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - docker push $IMAGE_TAG only: - main deploy: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - eval $(ssh-agent -s) - echo $DEPLOY_SSH_PRIVATE_KEY | ssh-add - - ssh -o StrictHostKeyCheckingno rootdeploy-server docker pull $IMAGE_TAG docker stop my-app || true docker rm my-app || true docker run -d --name my-app -p 8080:80 $IMAGE_TAG only: - main environment: name: production这段配置里有几个细节很关键。第一docker:dindservice 是必须的它提供 Docker daemon。如果没有它docker build会报Cannot connect to the Docker daemon。这也意味着 Runner 机器上要能跑特权容器Runner 注册的 config.toml 里最好加上privileged true。第二$CI_REGISTRY是 GitLab Container Registry 的地址前提是你启用了 GitLab 自带的镜像仓库功能。如果你用的是 Harbor 或者阿里云镜像仓库就替换成对应的变量和登录地址。第三部署服务器上的 Docker 操作需要 SSH 密钥这个密钥不要直接写在 yml 里而是通过 GitLab 项目的 CI/CD Variables 配置类型选 File 或 Variable 都可以。记住敏感信息永远不要硬编码进仓库。这套流程跑通之后开发只要 push 代码剩下的构建部署全自动完成。而且因为镜像 tag 里带了 commit SHA部署的是哪个版本一目了然回滚的时候只要重新部署旧的 tag 就行。5.3 CI 常见失败排查权限、缓存与镜像拉取CI 看着简单实际跑起来问题也不少。我把高频的几类失败列一下。Docker 权限错误Runner 如果用 docker executor容器里的用户没有权限访问 docker.sock解决办法是在 config.toml 里把 Runner 的执行用户设为 root或者在 yml 的 before_script 里加sudo chmod 666 /var/run/docker.sock。但更推荐的做法是给 docker executor 挂上 dind service彻底避免挂在 docker.sock 上。Runner 不执行 pipeline检查 Runner 是否 online然后看项目里 Runners 的 tag 设置。如果你的 Runner 注册时定义了 tag那 yml 里的 job 也要写上对应的tags否则 GitLab 不知道派哪个 Runner 去执行。这个问题很多人搜不到答案因为报错信息比较模糊就一句话This job is stuck because the project doesnt have any runners online。缓存不生效导致构建慢yarn 或 npm 依赖每次重新下构建时间高得吓人。解决办法是配置 CI 缓存cache: key: files: - package-lock.json paths: - node_modules/这样只要 package-lock.json 没变Runner 就会复用缓存目录。注意缓存是按 Runner 所在机器本地存储的如果你用了多个 Runner缓存并不会共享除非配置了 S3 之类的分布式缓存。6. 运维维护高危漏洞修复、备份恢复与升级6.1 GitLab 高危漏洞的应对思路热词里有人搜“gitlab高危漏洞修复方案”说实话GitLab 这种体量的系统隔三差五出安全公告太正常了。关键不是一出漏洞就慌而是建立一套可持续的升级和修复流程。第一优先级是关注官方安全公告。GitLab 会定期发布安全版本例如某个版本修复了存储 XSS、CSRF 或者权限绕过问题。你不需要把每个公告都读完但至少要关注.0后缀的版本这种通常汇集了一批安全修复。修复方式大部分情况就是升级到对应补丁版本yum update gitlab-ce gitlab-ctl reconfigure gitlab-ctl restart如果是内网机器没法直接升级可以先通过配置层面做缓解比如强制启用 HTTPS、限制外部访问、关闭不需要的匿名访问。还有一条容易被忽略的检查注册开关。如果你把 GitLab 部署在公网又开着开放注册那任何人都能注册账号进来看你的项目列表这是很常见的入口。设置路径在Admin Area - Settings - General - Sign-up restrictions内网环境直接取消勾选 Sign-up enabled。6.2 备份、恢复与定时任务数据安全这块没有备份策略的 GitLab 就是定时炸弹。GitLab 官方提供了备份命令可以备份仓库、数据库、上传附件和配置。手动备份很简单gitlab-backup create默认备份文件会在/var/opt/gitlab/backups下生成一个一串数字_gitlab_backup.tar。注意备份命令只备份业务数据不备份配置文件/etc/gitlab/gitlab.rb。备份配置要另外操作cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /data/gitlab-backups/gitlab-secrets.json尤其重要里面有很多加密密钥丢了它即使你有备份 tar 文件也恢复不了。恢复的话先停掉相关服务防止数据写入gitlab-ctl stop unicorn gitlab-ctl stop sidekiq gitlab-ctl stop puma # 看版本新版是 puma gitlab-backup restore BACKUP1234567890_2024_01_01_16.0.0 gitlab-ctl reconfigure gitlab-ctl restart日常建议用 crontab 做定时备份比如每天凌晨两点0 2 * * * /usr/bin/gitlab-backup create CRON1 /var/log/gitlab-backup.log 21备份文件记得定期 rsync 到其他机器或者对象存储否则硬盘坏了备份也没了。6.3 常见问题与排查速查表最后把我在使用 GitLab 过程中遇到的高频问题整理成了表格方便你在卡住的时候快速定位。现象可能原因处理方式网页打不开firewalld 未放行 80/443 端口放行端口或关闭 firewalld再检查 external_url 是否配对Git push 总让输密码未配置 SSH 密钥生成 ed25519 密钥并添加到 GitLab SSH Keysclone 地址带内网 IP 但访问不了external_url 配置与集群内访问方式不一致修改 gitlab.rb 里的 external_url 后 reconfigureCI job 卡住不跑Runner offline 或 tag 不匹配检查 Runner 状态在 yml job 中补齐 tagsdocker build 连不上 daemon缺少 dind service添加docker:dind作为 service磁盘空间被备份占满备份文件太多写清理策略如 find /data/backups -mtime 7 -delete内存不足导致服务频繁重启swap 没配或内存过小增加 swap 或升级内存GitLab 最低建议 4GHTTPS 证书报错自签名证书不被信任内网使用可关闭 HTTPS 或导入证书到客户端排查原则其实就一句话先看日志。GitLab 的日志大多集中在/var/log/gitlab/gitlab-rails/production.log、/var/log/gitlab/gitlab-rails/api_json.log、/var/log/gitlab/nginx/gitlab_access.log这几个文件里。出问题先 tail 日志比乱试配置高效得多。结尾的小建议如果让我总结这几年在 GitLab 上跌跌撞撞的经验最重要的一条是别急着加功能先把备份和升级路径跑通。很多人搭好 GitLab 后第一件事就是配 CI/CD却连备份目录都没确认过。结果一旦服务器出问题代码仓库、MR 记录、Runner 配置全没了那个损失不是重装一遍能补回来的。另外升级 GitLab 之前一定先备份并且在测试环境验证一次。GitLab 的版本策略比较激进跨大版本升级有时需要先升到中间版本再继续直接跳版本经常会出现数据库迁移失败。你可以在官方升级路径文档里查一下当前版本到目标版本的升级路线再决定怎么操作。这篇文章覆盖了从 CentOS 7 系统初始化、GitLab 安装配置、SSH 认证、Jenkins 集成到 CI/CD Docker 部署和运维备份的完整链路。你可以把它当成一张操作地图按顺序走一遍就能有一套能用的内部代码平台。如果后面有遇到具体的报错建议先按这个排查表过一遍。