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 ChartKubernetes部署、云厂商镜像市场等。对于初学者我强烈建议优先选择Docker方式。原因有三第一Docker镜像把GitLab运行时所需的所有依赖都打包好了你不需要单独去装Ruby、PostgreSQL、Redis这些组件一条docker run命令就能拉起一个完整的GitLab服务第二升级和回滚非常方便换一个镜像标签重启容器就行不用像Omnibus包那样还要跑gitlab-ctl upgrade等一堆升级流程第三如果后面不想用了删除容器就清理得干干净净不会在系统里留下零散的配置文件和依赖包。当然Docker方案有一个前提你的服务器上已经装好了Docker环境。如果连Docker都还没装建议先去把Docker装好Ubuntu用apt install docker.ioCentOS用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/组名/项目.gitSSH端口就是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_emailexample.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.git3.3 同一台电脑上同时用GitHub和公司GitLab这个需求几乎每个程序员都会遇到。我刚工作那会儿就被这个问题折腾了好久本地Git客户端配置了公司GitLab的账号之后发现GitHub的仓库push不上去了push的时候老是要输密码或者直接报权限错误。问题出在SSH密钥的配置上。正确做法是为不同的Git平台生成不同的密钥对然后在~/.ssh/config里做好映射。# 生成GitHub专用的密钥 ssh-keygen -t rsa -b 4096 -C github_emailexample.com -f ~/.ssh/id_rsa_github # 生成公司GitLab专用的密钥 ssh-keygen -t rsa -b 4096 -C company_emailexample.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 gitgithub.com ssh -T gitgitlab.company.com看到Welcome to GitHub或者Welcome to GitLab的输出就说明配置成功了。这样做的原理是SSH客户端会根据你连接的Host自动选择对应的私钥进行认证不同平台的密钥互不干扰。4. 日常开发流转从拉取代码到提交、上传、切换账号4.1 拉取代码到本地clone的两种姿势连接配置好了之后拉取代码就简单了。在GitLab项目主页上点击Clone按钮会看到两种URLSSH和HTTP。在命令行里执行# SSH方式推荐 git clone gitgitlab.example.com:group/project.git # HTTP方式 git clone http://gitlab.example.com/group/project.git执行完会在当前目录生成一个以项目名命名的文件夹代码就在里面了。有些同学clone大项目的时候容易遇到网络中断或者超时的情况建议可以只clone单个分支减少数据量# 只clone指定分支不带历史提交 git clone --branch main --depth 1 gitgitlab.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到1Runner配置、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.ymlPipeline同样会失败。所以结论很清楚想让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 StrictHostKeyCheckingno root192.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地址还要配置CredentialsGitLab账号密码或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 BACKUP1699999999 # 重启服务 docker exec -t gitlab gitlab-ctl start我在实际操作中总结出的经验是备份策略要自动化不要等手动想起来才备份。可以在宿主机上写一个cron定时任务每天凌晨执行一次备份同时保留最近7天的备份文件更早的自动清理。这样即便哪天真出了问题也能在最多丢失一天数据的情况下恢复回来。最后说点题外话我见过的初学者在GitLab上栽跟头的点绝大多数集中在SSH密钥配错、external_url配错、Runner注册不了、权限不足这几个问题上。这些坑说大不大但排查起来非常耗时。希望这篇内容能帮你把路走顺一点。如果你刚接触GitLab我的建议很简单先按着第2章的Docker部署走一遍把环境搭起来再按第3章的SSH配置把连接打通然后按第4章完成第一次代码推送。这三步做完你就已经跑通了GitLab最核心的使用闭环。CI/CD那一块等日常使用熟练了再上手也不迟但一旦跑通自动化部署你的开发体验会立刻上升一个档次。