3、GitLab平台搭建：GitLab安装与配置、项目与组管理、权限模型、Webhook与API集成

聊到企业级DevOps流水线，GitLab几乎是绕不开的核心平台。我个人习惯把它当作整个CI/CD体系的「心脏」——代码托管、CI/CD执行、制品管理，全都能在一个平台上搞定。这一章咱们就手把手把GitLab搭起来，顺便把日常用得最多的几个功能讲透。

3.1 GitLab安装与配置

安装GitLab其实不复杂，但有几个坑我得先给你提个醒。我曾经在一台2核4G的机器上硬跑GitLab，结果内存直接飙到90%，页面卡得跟幻灯片似的。所以第一件事：机器配置别省。

环境 最低配置 推荐配置
CPU 2核 4核+
内存 4GB 8GB+
磁盘 20GB 50GB+（SSD）
操作系统 Ubuntu 20.04 / CentOS 7 Ubuntu 22.04 / Rocky Linux 9

安装方式我推荐用Omnibus包，省心。Ubuntu上跑起来就几步：

# 安装依赖
sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates

# 添加GitLab仓库
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

# 安装并配置域名
sudo EXTERNAL_URL="https://gitlab.yourcompany.com" apt-get install gitlab-ce

嗯，这里要注意：EXTERNAL_URL一定要填对。我见过有人填了http://localhost，结果后面配置CI Runner的时候各种跨域问题，折腾了大半天。你想想看，一个错误的URL能引出多少连锁反应？

避坑指南： 我曾经在生产环境直接装最新版，结果跟已有的LDAP认证插件不兼容。建议先看Release Notes，确认兼容性再动手。另外，gitlab-ctl reconfigure这个命令会重置很多配置，跑之前一定备份/etc/gitlab/gitlab.rb。

安装完成后，访问https://gitlab.yourcompany.com，第一次会让你设置root密码。这个密码记牢了，后面管理员操作全靠它。

3.2 项目与组管理

GitLab里最核心的管理单元就是组（Group）和项目（Project）。我习惯把组当作「部门」或「产品线」，项目就是具体的「应用」或「服务」。

举个例子：

  • 组： backend-team（后端团队）
  • 子组： backend-team/user-service（用户服务子组）
  • 项目： backend-team/user-service/api（API项目）

这种层级结构的好处是权限可以继承。你给backend-team组设置好权限，下面所有子组和项目自动生效。省事。

创建组和项目很简单，但有几个细节我建议你注意：

  • 组名用全小写+连字符：比如data-platform，别用驼峰或下划线，后面CI/CD变量引用时省心。
  • 项目可见性：内部项目选Internal，敏感项目选Private。别图省事全设成Public，我见过有人把数据库密码直接提交到公开项目里……
  • 项目描述写清楚：至少写一句「这个项目是干啥的」。不然半年后你自己都忘了。
小技巧： 创建项目时勾选「Initialize repository with a README」，这样项目一建好就有默认分支和README文件，省去手动初始化的步骤。

3.3 权限模型

GitLab的权限模型其实很清晰，说白了就是五个级别：

角色 权限范围 典型场景
Guest 只能看Issue、评论 外部合作方、只读用户
Reporter 可以看代码、下载制品 测试人员、产品经理
Developer 可以推送代码、创建分支、触发CI 开发工程师
Maintainer 可以合并代码、管理项目设置 技术负责人、架构师
Owner 完全控制权，包括删除项目 项目管理员

我建议你遵循最小权限原则。比如开发人员给Developer就够了，别动不动就给Maintainer。我曾经有个项目，开发同学不小心把main分支给删了，还好有备份，不然那周就得通宵恢复了。

组级别的权限设置路径：Group → Settings → Members。这里可以批量添加用户，还能设置过期时间。临时工或者实习生，设个30天过期，到期自动失效，省得手动清理。

重点： 权限是继承的，但也可以覆盖。比如组级别是Developer，某个项目里可以单独把某人提升到Maintainer。但反过来，组级别是Maintainer，项目里不能降级到Guest——这是GitLab的设计逻辑，记住就好。

3.4 Webhook与API集成

Webhook和API是GitLab的灵魂。没有它们，GitLab就是个高级网盘。有了它们，才能跟Jenkins、Slack、Jira这些工具联动起来。

3.4.1 Webhook配置

Webhook说白了就是「当GitLab里发生某件事时，主动通知另一个系统」。比如代码推送后自动触发Jenkins构建。

配置路径：Project → Settings → Webhooks

常用的触发事件：

  • Push events：代码推送时触发。最常用，配合CI/CD流水线。
  • Merge request events：合并请求创建或更新时触发。适合做代码审查通知。
  • Tag push events：打标签时触发。适合触发发布流程。
  • Pipeline events：CI流水线状态变化时触发。适合通知构建结果。

举个例子，配置一个推送到Jenkins的Webhook：

URL: https://jenkins.yourcompany.com/gitlab-webhook/post
Secret Token: your-secret-token
Trigger: Push events, Merge request events
SSL verification: Enable
注意： Secret Token一定要设。我见过有人裸奔Webhook，结果被恶意触发了几百次构建，CI Runner直接被打挂了。Token相当于你的API密钥，保管好。

3.4.2 API集成

GitLab的API非常强大，几乎你能在界面上做的操作，API都能做。我个人习惯用API来做自动化运维，比如批量创建项目、管理用户、触发流水线。

先获取Personal Access Token：User Settings → Access Tokens。记得勾选你需要的权限范围，比如api、read_repository、write_repository。

几个常用的API示例：

# 获取项目列表
curl --header "PRIVATE-TOKEN: your-token" "https://gitlab.yourcompany.com/api/v4/projects"

# 创建新项目
curl --request POST --header "PRIVATE-TOKEN: your-token" \
  --data "name=my-new-project&visibility=private" \
  "https://gitlab.yourcompany.com/api/v4/projects"

# 触发CI流水线
curl --request POST --header "PRIVATE-TOKEN: your-token" \
  "https://gitlab.yourcompany.com/api/v4/projects/123/pipeline?ref=main"

为什么会推荐用API而不是界面操作？你想想看，当你需要一次性创建50个项目、给100个用户分配权限时，点鼠标能把你点疯掉。写个脚本，几分钟搞定。

经验之谈： 我建议把API Token的权限设得尽量小。比如只读操作就用read_api，别给api全权限。另外，Token别硬编码在脚本里，用环境变量或者Vault来管理。

3.5 小结

这一章我们走通了GitLab的安装、组与项目管理、权限模型，还有Webhook和API的集成。说实话，GitLab的功能远不止这些，但上面这些已经能覆盖日常80%的需求了。

下一章我们会聊GitLab CI/CD的核心——.gitlab-ci.yml怎么写，怎么把流水线跑起来。到时候你会看到，前面搭的这些基础设施，全都会派上用场。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →