GitLab从入门到实战：Docker部署、SSH连接与CI/CD流水线指南-平芜编程栈

1. 先搞明白一件事：GitLab到底是干嘛的，凭什么值得学

1.1 GitLab的本质：不只是个代码仓库

很多刚接触GitLab的同学，第一反应是"这不就是个放代码的地方吗"。这么理解没有错，但只对了一半。GitLab本质上是一套完整的DevOps生命周期管理平台，代码托管只是它最基础的功能。它把代码仓库、问题跟踪、代码评审（Merge Request）、CI/CD流水线、容器镜像仓库、安全扫描等等全部塞进了一个系统里。

打个比方：GitHub像是一个对外开放的"代码广场"，你把代码摆上去，大家都能看、能下载、能提Issues；而GitLab更像是一个"企业内部研发基地"，从代码存储到自动构建、自动测试、自动部署，整条链路都可以在一个平台上闭环完成。这也是为什么绝大多数公司在做内部研发平台选型时，首选就是GitLab——它可以跑在自己的服务器上，代码不出内网，数据安全可控。

1.2 和GitHub、Gitee相比，GitLab赢在哪

我自己三套系统都用过，GitHub放开源项目，Gitee放国内访问比较快的公开仓库，GitLab则是公司内部项目的核心阵地。三者对比下来，GitLab有几个特别突出的优势：

私有化部署：GitLab可以装在自己的服务器或内网环境里，GitHub虽然也有付费的私有仓库，但代码终究是放在别人的服务器上，对于很多有合规要求的公司来说这是不可接受的。
CI/CD一体化：GitLab自带的GitLab CI/CD可以直接在仓库里配置流水线，不需要像GitHub那样还要额外接Travis CI、GitHub Actions、Jenkins等第三方服务。虽然生态不如GitHub丰富，但对于绝大多数团队来说完全够用。
权限管理细粒度：从访客（Guest）到报告者（Reporter）再到开发者（Developer）、主维护者（Maintainer）、所有者（Owner），五级权限体系非常清楚，在多人协作的公司项目里管控起来很方便。
性能部署灵活：既能用Omnibus一键安装包跑在单台服务器上，也能用Docker容器化部署，甚至支持大规模分布式部署，从几十人的小团队到几千人的大厂都能找到合适的部署形态。

1.3 哪些场景下你躲不开GitLab

如果你正在经历下面这些场景中的任何一个，那这篇"骨灰级入门"就是为你准备的：

公司要求你往内部的GitLab上传代码，但你连SSH密钥是什么都没搞明白；
你刚接手一个项目，需要从GitLab上把代码拉下来，但总是提示登录失败或者权限报错；
项目发布流程要求走GitLab CI/CD，但你对Runner、Pipeline这些名词一头雾水；
你想在自己的服务器上搭一个私有GitLab，用Docker装了几次都没成功；
你已经能正常提交代码了，但还没弄懂怎么在同台电脑上同时使用GitHub和公司GitLab的账号。

这篇内容不整虚的，全是我在实际操作中验证过的步骤和踩过的坑，跟着一步步来就行。

2. 部署选型：从Docker快速安装到Linux离线包，几条路我都走了一遍

2.1 为什么新手指引里首推Docker方案

先回答一个我经常被问到的问题："我想在自己服务器上搭个GitLab，用哪种方式装比较好？"

GitLab官方提供了好几种安装方式，包括Omnibus安装包、Docker镜像、Helm Chart（Kubernetes部署）、云厂商镜像市场等。对于初学者，我强烈建议优先选择Docker方式。

原因有三：第一，Docker镜像把GitLab运行时所需的所有依赖都打包好了，你不需要单独去装Ruby、PostgreSQL、Redis这些组件，一条docker run命令就能拉起一个完整的GitLab服务；第二，升级和回滚非常方便，换一个镜像标签重启容器就行，不用像Omnibus包那样还要跑gitlab-ctl upgrade等一堆升级流程；第三，如果后面不想用了，删除容器就清理得干干净净，不会在系统里留下零散的配置文件和依赖包。

当然，Docker方案有一个前提：你的服务器上已经装好了Docker环境。如果连Docker都还没装，建议先去把Docker装好，Ubuntu用apt install docker.io，CentOS用yum install docker-ce，这个就不展开了。

2.2 Docker安装GitLab的完整步骤与资源预估

以我实际部署过的环境为例，服务器配置是4核8G内存、100G磁盘，系统是Ubuntu 20.04。这个配置跑一个小团队的GitLab（几十人规模）完全没问题，但如果团队超过百人，建议把内存加到16G。

直接贴我验证过可用的安装命令，这里以gitlab-ce中文社区版为例：

# 设置环境变量，注意替换为自己的域名或IP export GITLAB_HOME=/srv/gitlab sudo mkdir -p $GITLAB_HOME sudo docker run --detach \ --hostname gitlab.example.com \ --publish 443:443 --publish 80:80 --publish 2222:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ce:latest

这里有几个关键点要解释一下：

--hostname参数决定你后面用哪个域名或IP来访问GitLab，如果你没有域名，这里可以直接填服务器IP，比如--hostname 192.168.1.100。
我把主机的2222端口映射到了容器的22端口，这是为了防止宿主机本身的SSH服务和GitLab的SSH端口冲突。如果你宿主机上没有占用22端口，也可以直接--publish 22:22，但端口映射成2222更保险。实际用的时候注意：git clone ssh://git@域名:2222/组名/项目.git，SSH端口就是2222。
三个volume挂载目录分别是配置、日志、数据，一定要挂出来。否则容器一删，数据全没了，到时候哭都来不及。
--shm-size 256m是给共享内存设大小，GitLab的PostgreSQL比较吃这个，不设置的话在低配机器上容易出问题。

容器启动后，第一次初始化会比较慢，一般需要3到5分钟。你可以用docker logs -f gitlab持续观察日志，看到gitlab Reconfigured!之类的输出，就说明初始化完成了。

启动完成后，浏览器访问http://服务器IP，第一次访问会让你设置root用户的初始密码，设置完就可以用root账号登录了。

2.3 离线环境部署：Linux内网服务器的坑与对策

很多公司出于安全考虑，服务器是不能上外网的，这就涉及到GitLab的离线部署。我在一次内网项目中踩过不少坑，把经验总结一下。

离线部署的核心思路就一句话：在一台能上网的机器上把安装包和依赖全部下载好，再拷贝到内网机器上安装。

如果是Omnibus安装包方式，操作相对简单：

# 在有外网的机器上下载对应系统的安装包 wget https://packages.gitlab.com/gitlab/gitlab-ce/packages/ubuntu/focal/gitlab-ce_15.11.0-ce.0_amd64.deb # 拷贝到内网机器后执行 sudo dpkg -i gitlab-ce_15.11.0-ce.0_amd64.deb sudo gitlab-ctl reconfigure

如果是Docker方式离线部署，需要先在有外网的机器上把镜像保存成tar文件：

# 有外网的机器上执行 docker pull gitlab/gitlab-ce:15.11.0-ce.0 docker save -o gitlab-ce-15.11.0.tar gitlab/gitlab-ce:15.11.0-ce.0 # 把tar包拷贝到内网机器，然后执行 docker load -i gitlab-ce-15.11.0.tar

离线部署有几个特别容易踩的坑：一是版本选择要谨慎，提前确认好内网机器操作系统版本与GitLab安装包的兼容性，Ubuntu 18.04和20.04的安装包不能混用；二是依赖问题，Omnibus安装包虽然自带了大部分依赖，但个别系统可能需要先装openssl、postfix等基础组件，建议提前apt install一下；三是内网域名解析，如果没有DNS服务器，要给所有使用方配好/etc/hosts，把GitLab的域名指向服务器的内网IP。

2.4 初次登录：账号密码和管理员配置

GitLab装好之后，第一次用浏览器访问时，页面会要求你设置root用户的初始密码。这个密码建议设置得复杂一些，至少12位，包含大小写字母、数字和特殊字符——因为GitLab作为代码仓库，一旦root账号被攻破，整个公司的源码就全暴露了。

登录进去之后，我建议第一时间做两件事：

第一，到**Admin Area（管理员区域）**去关闭公开注册。默认情况下GitLab是允许任何人注册账号的，对内网系统来说这很危险。操作路径：左侧菜单Admin Area→Settings→General→Sign-up restrictions，把Sign-up enabled取消勾选。

第二，创建一个自己的普通账号，日常操作都用普通账号，不要一直用root跑业务。项目权限控制、账号管理用root就够了，经常用root操作仓库容易误操作改坏权限配置。

到这里，你的GitLab服务器就已经能用了。接下来要解决的问题是：怎么把代码拉下来、推上去。

3. 和仓库建立连接：SSH密钥配置、clone到本地、域名和ID那点事

3.1 生成SSH密钥：一次生成，一劳永逸

GitLab支持两种代码传输协议：HTTP(S)和SSH。我个人的建议是：日常命令行操作一律用SSH，因为SSH密钥认证比输入用户名密码更安全，而且不需要每次push都输密码。

生成SSH密钥的步骤如下：

# 在本地机器上执行，-C后面写你的邮箱，用来标识这个密钥 ssh-keygen -t rsa -b 4096 -C "your_email@example.com" # 一路回车，会生成默认路径下的密钥对 # 默认路径：~/.ssh/id_rsa（私钥）和 ~/.ssh/id_rsa.pub（公钥）

生成完之后，查看公钥内容：

cat ~/.ssh/id_rsa.pub

把输出的内容完整复制，登录GitLab网页端，右上角头像 →Preferences（偏好设置）→ 左侧SSH Keys，把公钥粘贴到Key输入框里，Title可以随意填，建议填"我的工作电脑"之类的备注，方便以后区分。点击Add key就完成了。

这里有个常见的坑：有些同学会把id_rsa（私钥）当成公钥贴上去，结果一直提示权限错误。记住，公钥是.pub后缀的那个，私钥永远不要给别人看。

3.2 HTTP克隆和SSH克隆的差异，以及"域名还是机器ID"那个坑

很多从Windows环境开始用Git的同学，习惯了直接用HTTP方式clone。这种方式的优势是简单，只需要账号密码，不用配置SSH密钥。但HTTP方式后面会碰到一个问题：每次push都要输账号密码，而且企业GitLab通常会从某一天开始要求必须用Personal Access Token代替密码，很多初学者就在这里卡住了。

更麻烦的是，如果当初安装GitLab时设的external_url是机器ID（比如容器ID或内网主机名），别人通过HTTP clone的时候就会出现连不上的情况。这是个非常经典的问题——GitLab会把external_url写进所有项目的clone地址里。

举个例子：你安装时--hostname填了gitlab.example.com，那么网页上显示的所有clone URL都是http://gitlab.example.com/xxx/yyy.git。但如果你安装时填的hostname是abc123这种机器ID，那么clone地址就会变成http://abc123/xxx/yyy.git，别人当然连不上。

解决办法也很简单：

第一种，改external_url配置：

# 进入GitLab容器（Docker方式部署时） docker exec -it gitlab bash # 编辑配置文件 vi /etc/gitlab/gitlab.rb # 修改或添加以下行 external_url 'http://gitlab.example.com' # 生效配置 gitlab-ctl reconfigure

第二种，更省事的办法是用域名解析。如果你没有自己的域名，也可以直接用服务器IP作为external_url，这样所有人通过http://服务器IP/xxx/yyy.git就能clone，简单省事。

这里要提醒一下：修改external_url之后，GitLab会重新生成项目的clone地址，但已经存在的远端URL不会自动变化，你需要把本地仓库的remote改一下：

git remote set-url origin http://服务器IP/xxx/yyy.git

3.3 同一台电脑上同时用GitHub和公司GitLab

这个需求几乎每个程序员都会遇到。我刚工作那会儿就被这个问题折腾了好久，本地Git客户端配置了公司GitLab的账号之后，发现GitHub的仓库push不上去了，push的时候老是要输密码或者直接报权限错误。

问题出在SSH密钥的配置上。正确做法是：为不同的Git平台生成不同的密钥对，然后在~/.ssh/config里做好映射。

# 生成GitHub专用的密钥 ssh-keygen -t rsa -b 4096 -C "github_email@example.com" -f ~/.ssh/id_rsa_github # 生成公司GitLab专用的密钥 ssh-keygen -t rsa -b 4096 -C "company_email@example.com" -f ~/.ssh/id_rsa_gitlab

然后编辑~/.ssh/config文件：

# GitHub配置 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_rsa_github # 公司GitLab配置 Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_rsa_gitlab

把两个公钥分别添加到GitHub和GitLab的SSH Keys设置里，然后用下面的命令测试连通性：

ssh -T git@github.com ssh -T git@gitlab.company.com

看到Welcome to GitHub或者Welcome to GitLab的输出就说明配置成功了。这样做的原理是：SSH客户端会根据你连接的Host自动选择对应的私钥进行认证，不同平台的密钥互不干扰。

4. 日常开发流转：从拉取代码到提交、上传、切换账号

4.1 拉取代码到本地：clone的两种姿势

连接配置好了之后，拉取代码就简单了。在GitLab项目主页上，点击Clone按钮，会看到两种URL：SSH和HTTP。在命令行里执行：

# SSH方式（推荐） git clone git@gitlab.example.com:group/project.git # HTTP方式 git clone http://gitlab.example.com/group/project.git

执行完会在当前目录生成一个以项目名命名的文件夹，代码就在里面了。有些同学clone大项目的时候容易遇到网络中断或者超时的情况，建议可以只clone单个分支减少数据量：

# 只clone指定分支，不带历史提交 git clone --branch main --depth 1 git@gitlab.example.com:group/project.git

--depth 1表示只拉取最新一次的提交记录，这样clone速度会快很多。但注意这种方式会丢失历史记录，如果需要查看旧版本代码，还是建议完整clone。

4.2 提交代码到仓库：add、commit、push的完整闭环

从拉取代码到本地之后，你肯定要改代码、提交代码。Git的基本操作流程是这样的：

# 1. 查看当前状态，看看改了哪些文件 git status # 2. 把修改的文件加入暂存区 git add . # 添加所有修改文件 # 或者只添加指定文件 git add src/main/java/UserService.java # 3. 提交到本地仓库，-m后面是提交说明 git commit -m "fix: 修复用户登录接口的空指针异常" # 4. 推送到远程仓库 git push origin main

这里提醒几个重要的习惯：

第一，提交信息要写清楚。不要写"update"、"fix bug"这种敷衍的提交信息，别人看你的提交记录根本不知道你干了什么。推荐用"类型: 描述"的格式，比如feat: 新增用户注册功能、fix: 修复订单超时问题、docs: 更新接口文档。

第二，push之前先pull。如果你和同事在同一个分支上协作，别人可能已经推了新代码上去。直接push的话可能会冲突或者被拒绝。所以push之前建议先执行git pull把远程最新代码拉下来合并。

第三，用了--depth 1clone的仓库不能push。因为本地缺少历史记录，推上去会和远程仓库产生不匹配。如果遇到这个问题，可以执行git fetch --unshallow把完整历史拉下来就行了。

4.3 网页端上传文件：临时小文件也能搞定

有些场景下，你只是想在GitLab上上传一个文件，比如配置文件、文档、模板等，不想为此走一遍完整的clone和push流程。这时候可以直接用GitLab网页端的"上传文件"功能。

在项目页面上，点击文件列表右上角的+按钮，选择Upload file，选择本地文件后它可以自动帮你在指定分支上创建一个新的commit。提交信息可以改，默认是你上传的文件名。

我个人的使用体验是：网页端上传适用于偶尔上传小型配置文件或者文档，对于大量的、频繁的代码文件操作，还是要用Git命令行工具。因为网页上传没有本地仓库的版本管理，后续继续修改要二次上传，效率太低。

4.4 IDEA里切换GitLab账号的实测步骤

如果你和我一样是Java开发，日常用的是IntelliJ IDEA，那IDEA里GitLab账号的配置和切换也算是个高频需求。

IDEA打开项目后，通过File→Settings→Version Control→GitLab进入配置页面。在这里可以添加多个GitLab服务器地址，每个地址对应一个Login账号。

切换账号的坑在于：IDEA默认会用当前配置的Token去连接GitLab，如果你的Token过期了或者密码改了，GitLab面板里就会出现红色的错误提示。

我推荐的做法是：在GitLab网页端生成一个Personal Access Token，不要直接用密码登录IDEA。操作路径：GitLab右上角头像 →Preferences→Access Tokens，勾选api、read_repository、write_repository这几个权限，生成一个Token字符串。然后在IDEA的GitLab设置页里选择Token认证方式，把Token粘进去。

这样做的好处是：Token可以设置过期时间，到期了重新生成一个就行，不用频繁改密码；而且Token可以针对不同项目或不同权限分别创建，安全性更好。如果以后要切换账号，把旧Token删掉换新Token就行。

5. CI/CD从0到1：Runner配置、Pipeline触发和Docker自动化部署

5.1 没有.gitlab-ci.yml就触发Runner？先搞清楚CI是怎么被唤起的

在讲配置Runner之前，我先回答一个网上经常搜到的问题："没有gitlab.yaml依然触发Runner，是否可行？"

答案是：不可行。GitLab CI/CD的运行机制非常明确——每次触发Pipeline（流水线）的先决条件就是仓库根目录下存在.gitlab-ci.yml文件。如果没有这个文件，GitLab会认为该项目没有配置CI/CD，推送代码时根本不会去调度Runner。

但为什么有些同学会观察到"没有.gitlab-ci.yml也触发了Runner"？这其实不是一个bug，而是Runner可能是被其他方式唤醒的。常见的原因有两个：

第一，项目配置了Pipeline Triggers。GitLab允许通过API调用触发Pipeline，即使仓库里没有.gitlab-ci.yml文件，只要有人/系统调用了触发接口，Runner依然会被调用。但这种情况下Pipeline会因为找不到配置文件而直接报错。

第二，Runner配置了run_untagged且开启了locked的共享Runner，同时项目里配置了其他自动任务（比如Scheduled Pipeline定时流水线）。定时任务到点触发时，如果没找到.gitlab-ci.yml，Pipeline同样会失败。

所以结论很清楚：想让Runner正常工作，就必须在仓库里加上.gitlab-ci.yml。这也是GitLab CI/CD的入口文件，相当于整个自动化流程的"剧本"。

5.2 Runner注册：让GitLab找到干活的人

Runner是真正执行你流水线任务的"工人"。GitLab本身只负责调度和管理，具体的构建、测试、部署操作全部由Runner来执行。Runner可以装在独立的机器上，也可以和GitLab装在同一台服务器上。

注册Runner的步骤如下：

第一步，在GitLab里获取注册令牌。路径：项目/组的Settings→CI/CD→Runners，里面有个Project registration token。如果想注册项目级别的Runner就复制项目令牌，如果想注册组级别或实例级别的Runner就复制对应的令牌。

第二步，在Runner所在的机器上安装并注册：

# Ubuntu上安装GitLab Runner curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash sudo apt-get install gitlab-runner # 注册Runner sudo gitlab-runner register

注册过程中会依次询问：

GitLab实例URL：填http://gitlab.example.com
注册令牌：粘贴刚才复制的令牌
Runner描述：填一个说明性的名称，比如"生产环境编译机"
标签：建议填docker或者build，这是后面在.gitlab-ci.yml里指定Runner用的关键词
执行器：强烈建议选docker，因为Docker执行器能让每次构建都在一个全新的容器里运行，环境干净、互不干扰

第三步，注册完成后，回到GitLab的Runners页面，就能看到这个Runner处于在线状态。

5.3 手写一份最简单的.gitlab-ci.yml

有了Runner之后，接下来要在仓库根目录下创建.gitlab-ci.yml文件。我先给一个最简单的示例，后面再逐步增加自动部署逻辑：

stages: - build build-job: stage: build image: maven:3.8-openjdk-11 script: - echo "开始编译项目..." - mvn clean package -DskipTests artifacts: paths: - target/*.jar

解释一下关键配置的含义：

stages：定义了流水线包含哪几个阶段，这里是只有一个build阶段。多个阶段的示例是build、test、deploy，按顺序执行，只有前一个阶段成功了才会进入下一个阶段。
build-job：这是Job的名称，可以自定义。
stage：指定这个Job属于哪个阶段。
image：指定执行这个Job时使用的Docker镜像。如果你的项目是Java的，就用Maven镜像；如果是Node.js项目，就用node:18的镜像。
script：这是Job真正要执行的命令序列。
artifacts：构建完成后保留的产物，通常是jar包或构建好的静态文件。

把这个文件推送到GitLab仓库之后，GitLab会立刻检测到并触发一次Pipeline。你可以在项目的CI/CD→Pipelines页面看到执行过程和结果。

一个小提醒：如果Runner没有打标签，.gitlab-ci.yml里的Job默认只能在tag列表为空的Runner上运行。如果你的Runner注册时打了docker标签，那Job里最好加上tags: - docker，否则会一直处于Pending状态。

5.4 Docker镜像构建与自动化部署的完整链路

CI/CD做到这一步，其实已经能自动编译了。但生产环境真正的价值在于"自动化部署"。下面我把一套完整的"构建Docker镜像+推送到私有仓库+自动部署到服务器"的流程贴出来。

假设你的项目是个Spring Boot服务，部署目标是另一台应用服务器，完整的.gitlab-ci.yml大概是这样的：

stages: - build - package - deploy variables: IMAGE_NAME: registry.example.com/myapp/server IMAGE_TAG: $CI_COMMIT_SHORT_SHA build-job: stage: build image: maven:3.8-openjdk-11 script: - mvn clean package -DskipTests artifacts: paths: - target/*.jar expire_in: 1 hour package-job: stage: package image: docker:20.10.17 services: - docker:20.10.17-dind script: - docker build -t $IMAGE_NAME:$IMAGE_TAG . - docker login -u $REGISTRY_USER -p $REGISTRY_PASSWORD registry.example.com - docker push $IMAGE_NAME:$IMAGE_TAG deploy-job: stage: deploy image: alpine:latest before_script: - apk add --no-cache openssh-client script: - ssh -o StrictHostKeyChecking=no root@192.168.1.101 "docker pull $IMAGE_NAME:$IMAGE_TAG && docker stop myapp || true && docker rm myapp || true && docker run -d --name myapp -p 8080:8080 $IMAGE_NAME:$IMAGE_TAG" only: - main

这里面有几点说明一下。

$CI_COMMIT_SHORT_SHA是GitLab CI/CD内置的预定义变量，代表当前提交的短哈希值，用来作为镜像tag可以保证每次构建的镜像都是唯一可追溯的。

package-job里用到了Docker的dind服务（Docker in Docker）。因为执行器本身就是Docker容器，容器里想再构建Docker镜像，就必须通过docker:20.10.17-dind这个服务去提供Docker守护进程。

deploy-job里通过SSH远程连接应用服务器，执行容器更新操作。注意生产环境不要这么裸奔，建议用docker-compose up -d配合版本管理，或者用Kubernetes滚动更新。

注册表账号密码这类敏感信息不要直接写死在.gitlab-ci.yml里，要去项目的Settings→CI/CD→Variables里配置受保护的变量，GitLab会自动用$变量名的语法去读取。

这套流程跑通之后，你推送代码到main分支的那一刻，编译、打包镜像、推送镜像、远程部署就全自动完成了，非常爽。

5.5 Jenkins连接GitLab：两个工具的分工与协作

很多公司的技术栈里既有GitLab又有Jenkins，两者的关系让很多新人困惑。简单理解：GitLab负责代码托管和MR评审，Jenkins负责持续构建和发布，两者通过Webhook和API配合。

在Jenkins里配置GitLab连接，需要做两件事：

第一，在Jenkins的系统管理→系统配置里，找到GitLab插件配置区，填入GitLab的URL和API Token。API Token还是在GitLab的Access Tokens里生成，需要勾选api权限。

第二，Pipline脚本或自由风格项目里，在"源码管理"中选择Git，填上仓库URL。如果你用的是HTTP地址，还要配置Credentials（GitLab账号密码或Token）。SSH地址的话，在Jenkins服务器上生成一对密钥，把公钥配到GitLab用户的SSH Keys里。

实际操作中，我推荐用**Jenkins的Pipeline脚本（Jenkinsfile）**来定义构建流程，这样整个流程就像代码一样有版本管理。同时配合GitLab的Webhook——在GitLab项目设置里配置Webhook指向Jenkins的接口地址，这样每次push代码，GitLab会自动通知Jenkins触发构建，实现半自动或全自动的CI。

不过说句实话，对于新项目，如果代码和流水线都愿意放在GitLab这边，就没必要再引入Jenkins了。GitLab CI/CD的能力已经覆盖了绝大多数场景，多一套Jenkins就多一套维护成本。只有当你有非常复杂的构建矩阵、多平台分发或者已经在Jenkins上沉淀了大量流水线资产的时候，才值得把两者连接起来。

6. 管理员和进阶玩家容易踩的坑：漏洞修复、权限管理、备份恢复

6.1 高危漏洞修复：版本升级与补丁操作

GitLab作为使用量极大的开源平台，历史上也曝出过一些高危漏洞。常见的包括：任意文件读取漏洞（CVE-2020-13347）、SSRF漏洞（CVE-2021-22214）、存储型XSS漏洞、反序列化漏洞等。

遇到高危漏洞，最有效的修复方案就两个字：升级。GitLab官方在每个漏洞披露时都会发布修复版本，你需要做的是：

# Docker方式部署时，换镜像标签即可 docker stop gitlab docker rm gitlab docker run ... gitlab/gitlab-ce:最新修复版本

这里有一个非常重要的提醒：升级GitLab之前，一定要先备份。GitLab的版本升级路径是有讲究的，跨大版本直接升级（比如14.x直接跳到16.x）很可能会失败，官方要求按照大版本逐级升级（14.x → 15.x → 16.x）。

如果暂时不方便升级，应急缓解措施包括：关闭某些有漏洞的功能模块、限制外网访问GitLab管理后台、加强防火墙规则。但这些都只是权宜之计，最终还是要靠升级修复。

另外，日常使用中要注意：external_url配置里的域名不要跟内网敏感服务有关联，避免被黑客利用SSRF漏洞去探测内网资源。同时建议开启GitLab的双重身份验证（2FA），特别是管理员账号，能有效降低账号被盗后的风险。

6.2 账号权限模型：从游客到Owner的五级权限

做GitLab管理员，权限模型是必须搞清楚的。很多权限问题排查半天，其实只是没理解这五级权限的含义。

角色	权限说明	典型场景
Guest（访客）	只能看Issue和评论，不能看代码	产品经理、外部客户
Reporter（报告者）	可以看代码、提Issue，不能push	测试人员
Developer（开发者）	可以push代码、创建分支、发起MR	日常开发的主力角色
Maintainer（主维护者）	可以合并MR、管理项目设置	技术负责人
Owner（所有者）	项目最高权限，可删除项目	项目负责人或管理员

实际使用中，我见过不少团队把所有人的权限都设成Maintainer甚至Owner，图省事。但这样做风险挺大的：万一有人误操作点了删除项目或者改掉了CI/CD配置，整个团队的代码就危险了。

建议采用最小权限原则：

新人进组先给Reporter或Developer起步，观察一段时间再给更高的权限；
主干分支（main/master）可以在项目设置里开启保护分支，只允许Maintainer及以上角色直接push，其他人只能通过Merge Request合入。这样能保证主干代码质量；
生产部署相关的CI/CD变量设为受保护变量，只有保护分支上的流水线才能读取。

6.3 数据备份与恢复的实用操作

最后聊一下GitLab的备份恢复，这个问题很多管理员容易忽略，等出了问题才后悔莫及。

先看Docker方式部署时怎么备份：

# 进入容器执行备份命令 docker exec -t gitlab gitlab-backup create # 备份文件默认放在数据目录的backups子目录下 # 也就是宿主机 $GITLAB_HOME/data/backups/

备份完成后，会在/data/backups/下生成一个类似1699999999_2023_11_15_16.11.0_gitlab_backup.tar的文件。这个tar文件只包含GitLab的数据库和Git仓库数据，不包含配置文件。所以备份时，还要把/srv/gitlab/config目录一并拷贝走。

恢复的时候：

# 停止相关服务 docker exec -t gitlab gitlab-ctl stop unicorn docker exec -t gitlab gitlab-ctl stop sidekiq # 恢复备份，注意文件名里的时间戳前缀 docker exec -t gitlab gitlab-backup restore BACKUP=1699999999 # 重启服务 docker exec -t gitlab gitlab-ctl start

我在实际操作中总结出的经验是：备份策略要自动化，不要等手动想起来才备份。可以在宿主机上写一个cron定时任务，每天凌晨执行一次备份，同时保留最近7天的备份文件，更早的自动清理。这样即便哪天真出了问题，也能在最多丢失一天数据的情况下恢复回来。

最后，说点题外话

我见过的初学者，在GitLab上栽跟头的点，绝大多数集中在SSH密钥配错、external_url配错、Runner注册不了、权限不足这几个问题上。这些坑说大不大，但排查起来非常耗时。希望这篇内容能帮你把路走顺一点。

如果你刚接触GitLab，我的建议很简单：先按着第2章的Docker部署走一遍，把环境搭起来；再按第3章的SSH配置把连接打通；然后按第4章完成第一次代码推送。这三步做完，你就已经跑通了GitLab最核心的使用闭环。CI/CD那一块，等日常使用熟练了再上手也不迟，但一旦跑通自动化部署，你的开发体验会立刻上升一个档次。

GitLab从入门到实战：Docker部署、SSH连接与CI/CD流水线指南