企业官网建设流程全解析

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 bs=1M count=4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 写入 fstab 使开机自动挂载 echo '/swapfile swap swap defaults 0 0' >> /etc/fstab # 调整 swappiness 提升缓存效率 sysctl vm.swappiness=10 echo 'vm.swappiness=10' >> /etc/sysctl.conf

这个步骤很多人会跳过，但等 GitLab 跑到一半进程被杀，再回来补就太被动了。我在一台 1GB 内存的测试机上试过，不配 swap 的时候跑 gitlab-ctl reconfigure 都能直接把进程卡死，配了 swap 至少能顺利完成安装和基础操作。

2.2 系统基础设置：主机名、时钟、防火墙与 SELinux

准备好资源以后，先把系统基础环境理清。这里每一步都有目的，不是为了走流程。

主机名和 hosts

GitLab 的 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 主要会用到这几个端口：

如果不想折腾，直接在防火墙里放行：

firewall-cmd --permanent --add-service=http firewall-cmd --permanent --add-service=https firewall-cmd --permanent --add-service=ssh firewall-cmd --reload

如果你把 SSH 端口改了，记得放行对应端口，不然 Git clone 会天天提示 connection refused。

SELinux

这是 CentOS 7 跟 Ubuntu 系最大的区别。SELinux 默认 enforcing 状态，GitLab 官方 rpm 包已经带了 SELinux 策略，理论上可以不开，但实际部署中我见过太多因为策略冲突导致的权限诡异问题。我的建议是：生产环境尽量开启 SELinux，但如果你不熟悉它，先把 GitLab 跑通，再慢慢调策略。个人练手直接临时关闭最省心：

setenforce 0 sed -i 's/^SELINUX=enforcing/SELINUX=permissive/' /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] name=gitlab_gitlab-ce baseurl=https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7 repo_gpgcheck=0 gpgcheck=0 enabled=1 EOF yum makecache

清华镜像源在国内访问速度明显比官方源快。装的时候指定 external_url，这一步会同时完成安装和初始配置：

yum install -y gitlab-ce

安装完成后，第一次配置：

gitlab-ctl reconfigure

这一步会跑很久，因为它要初始化 PostgreSQL、Redis、NGINX、Sidekiq、Prometheus 等一系列组件。如果 strace 看它的执行过程，你会发现它本质上就是把配置文件里的变量渲染到各个服务的配置里，再逐个启动服务。我见过新手等不及直接 Ctrl+C，结果留下一堆半初始化状态，最后只能重装。所以 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 对外暴露的地址。如果是局域网内使用，直接写成 IP：

external_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 小时的问题。很多人没设置，然后发现提交记录时间不对，还以为是代码问题。实际上是系统时区默认 UTC，GitLab 显示出来的时间当然跟中国本地时间不一致。

备份目录

GitLab 默认备份目录是/var/opt/gitlab/backups，如果你的系统盘空间不大，建议改成独立磁盘或者 NFS 挂载点：

gitlab_rails['backup_path'] = '/data/gitlab-backups'

改完任何配置都要重新执行gitlab-ctl reconfigure，这是 GitLab 的规矩，别只改不看效果。有些配置还需要重启对应服务，比如改了 external_url 要重启 NGINX：gitlab-ctl restart nginx。

3.4 Docker 方式安装 GitLab：另一种选择

Docker 装 GitLab 确实能省掉很多依赖上的麻烦，但注意网络和存储配置。我见过最多的问题是把容器内部的 22 端口映射到宿主机，然后宿主机自己的 sshd 也在监听 22，结果端口冲突，容器起不来。推荐的映射方式是宿主机的 2222 映射到容器的 22：

docker 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://git@192.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-email@example.com" # 查看公钥并复制 cat ~/.ssh/id_ed25519.pub

然后登录 GitLab，打开Preferences -> SSH Keys，把公钥粘贴进去，保存。之后 clone 代码：

git clone git@192.168.1.100:group/project.git

如果你把容器方式的 SSH 端口映射成 2222，那 clone 地址要带端口号：

git clone ssh://git@192.168.1.100:2222/group/project.git

第一次 clone 的时候会提示确认 host key，输入 yes 即可。这之后就不会再问密码了。如果仍然让你输密码，常见的排查思路是：

1. 本地 ssh-agent 里没有加载密钥，执行ssh-add ~/.ssh/id_ed25519。
2. GitLab 账号对应的 SSH 公钥没配置对。
3. SELinux 或防火墙拦截了 SSH 端口。

用ssh -T git@192.168.1.100测试连接，看到Welcome to GitLab, @username!这样的提示就说明通了。

4.2 Group、权限与分支保护设计

正常使用 GitLab，一定不能一个人建一堆零散项目就完事了。GitLab 的逻辑是 Group 管理 Project，Member 管理用户权限。

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_repository，Jenkins 用它调 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 这边，正确的配置顺序是：

1. 打开Manage Jenkins -> Configure System。
2. 找到 GitLab 部分，填入 Connection name、GitLab host URL。
3. Credentials 类型选择GitLab API token，把 token 粘进去。
4. 点 Test Connection，看到 Success 就说明连上了。

连上之后，在 Job 里可以用 GitLab 提供的触发器，比如 Merge Request 触发或 Push 触发。Jenkinsfile 里也通过 API token 去拉取 GitLab 仓库，不再需要单独为 clone 配 SSH 密钥了。

5. CI/CD 自动化部署：GitLab Runner 与 Docker 镜像构建

5.1 注册 GitLab Runner

GitLab 自带的 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 StrictHostKeyChecking=no root@deploy-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 doesn't 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 BACKUP=1234567890_2024_01_01_16.0.0 gitlab-ctl reconfigure gitlab-ctl restart

日常建议用 crontab 做定时备份，比如每天凌晨两点：

0 2 * * * /usr/bin/gitlab-backup create CRON=1 >> /var/log/gitlab-backup.log 2>&1

备份文件记得定期 rsync 到其他机器或者对象存储，否则硬盘坏了备份也没了。

6.3 常见问题与排查速查表

最后把我在使用 GitLab 过程中遇到的高频问题整理成了表格，方便你在卡住的时候快速定位。

排查原则其实就一句话：先看日志。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 部署和运维备份的完整链路。你可以把它当成一张操作地图，按顺序走一遍就能有一套能用的内部代码平台。如果后面有遇到具体的报错，建议先按这个排查表过一遍。