GitLab 基础与架构介绍
GitLab 是开源 DevOps 平台，把 Git 仓库、CI/CD、Issue、Merge Request、Container Registry 和权限管理放在同一套系统里。运维视角下，它既是代码托管服务，也是 CI 调度中枢和制品入口。
完成本章后，你应该能够：
- 说明 GitLab 与 GitHub 在部署模型和功能边界上的差异；
- 区分 CE/EE 及版本号含义，规划升级路径；
- 画出 GitLab 核心组件及其职责；
- 根据团队规模选择合适的部署方式。
GitLab 将代码仓库、评审、CI、测试、镜像、部署、监控和运维串联在同一平台中。
1. GitLab简介
GitLab 最初是 Git 仓库管理工具，现已扩展为完整 DevOps 生命周期平台。开发者通过 Web UI 或 Git 协议提交代码；运维通过 Omnibus 包、Docker 或 Helm 部署实例；CI/CD 通过 .gitlab-ci.yml 和 Runner 执行构建与发布。
典型使用场景：
| 场景 | GitLab 提供的能力 |
|---|---|
| 代码托管 | Git 仓库、分支保护、Merge Request |
| 持续集成 | Pipeline、Job、Artifact、Cache |
| 制品管理 | Container Registry、Package Registry |
| 协作与审计 | Issue、Wiki、Audit Event（EE） |
中小团队常把 GitLab 作为「唯一入口」：代码、流水线、镜像仓库都在同一域名下，减少跨系统凭证和权限同步成本。
2. GitLab核心能力
源代码管理：支持 Git over HTTP/SSH，Merge Request 带 Code Review、讨论和 CI 状态检查。
CI/CD：.gitlab-ci.yml 声明 Stage/Job；Runner 拉取 Job 并在 Docker/K8s/Shell 等 Executor 中执行；支持 Cache、Artifact、Environment 和 Deploy Token。
项目管理：Group/Project 层级、Issue Board、Milestone、Label，适合按产品线组织。
安全与合规（部分为 EE）：Dependency Scanning、Container Scanning、Audit Events、Compliance Framework 等；CE 仍具备基础权限模型和 Protected Branch。
Container Registry：与 Project 绑定，Pipeline 可直接 docker push 到 registry.example.com/group/project。
3. GitLab与GitHub区别
| 维度 | GitLab | GitHub |
|---|---|---|
| 部署 | 可自托管（Omnibus/Docker/K8s） | 仅 SaaS（GitHub Enterprise Server 需单独授权） |
| CI/CD | 内置 GitLab CI，Runner 自管 | GitHub Actions，Runner 可选 GitHub 托管或自托管 |
| 权限模型 | Group → Project，内置 Guest～Owner | Organization → Repository，角色体系不同 |
| Registry | 内置 Container Registry | GitHub Container Registry (ghcr.io) |
| 适用场景 | 内网、合规、一体化 DevOps | 开源社区、SaaS 协作 |
自托管 GitLab 意味着你要负责备份、升级、证书、Runner 和 PostgreSQL/Redis 运维；SaaS GitHub 把这些交给厂商，但数据出境和定制能力受限。
4. GitLab版本介绍
4.1 CE 与 EE
- Community Edition (CE)：开源，含核心 Git、CI/CD、Registry，满足多数团队需求。
- Enterprise Edition (EE)：在 CE 基础上增加高级安全扫描、Geo 复制、合规、更细审计等；生产若需这些能力需购买订阅。
镜像/包名示例：gitlab/gitlab-ce、gitlab/gitlab-ee；Omnibus 包同理。
4.2 版本号规则
GitLab 采用 Major.Minor.Patch（如 17.5.2）：
- Major：大版本，可能含破坏性变更，升级前必读 Release Notes；
- Minor：功能版本，通常每约 4 周发布；
- Patch：安全与 Bug 修复，应优先跟进。
查看当前版本：
# Omnibus 安装
sudo gitlab-rake gitlab:env:info | head -20
# Docker
docker exec gitlab gitlab-rake gitlab:env:info 2>/dev/null | grep "GitLab information"
4.3 升级路径概念
GitLab 不支持跨多个 Major 一次跳升。正确路径是逐级 Minor/Major 升级，例如 16.11 → 17.0 → 17.5，每步执行：
# 1. 备份
sudo gitlab-backup create
# 2. 升级包/镜像
# 3. 重新配置
sudo gitlab-ctl reconfigure
sudo gitlab-rake gitlab:check SANITIZE=true
升级前检查：官方升级路径文档 与 PostgreSQL、Gitaly 版本兼容性。
5. GitLab整体架构
单机 Omnibus 部署时，各组件由 gitlab-ctl 统一管理，对外通常只暴露 443/80（HTTP/HTTPS） 和 22（SSH，可改端口）。
架构配图用于快速理解请求入口、应用层、数据层、后台任务、镜像仓库和外部 Runner 的分层关系；各组件的准确职责见下方组件表。
Rails 处理 Web/API；Gitaly 负责 Git 对象读写；Sidekiq 消费 Redis 队列执行异步任务（邮件、Pipeline 调度等）。
6. GitLab核心组件介绍
各组件职责与后续章节对应关系：
| 组件 | 职责 | 详见 |
|---|---|---|
| GitLab Rails | Web UI、REST/GraphQL API、权限与业务逻辑 | 组件详解 |
| Gitaly | Git 仓库 RPC 服务，实际存储 Git 对象 | 组件详解 |
| PostgreSQL | 元数据、用户、MR、Pipeline 记录 | 组件详解 |
| Redis | 缓存、队列、会话、Rate Limit | 组件详解 |
| Sidekiq | 后台 Job 消费者 | 组件详解 |
| Workhorse | 大文件上传、Git HTTP 智能代理 | 组件详解 |
| Nginx | 反向代理、TLS 终结、静态资源 | 组件详解 |
| Container Registry | OCI 镜像存储与鉴权 | 组件详解 |
排障时先确定请求类型：页面/API 走 Rails；git clone/push 走 Workhorse→Gitaly；Pipeline 卡住常查 Sidekiq 和 Runner，而不是 Nginx。
7. GitLab部署方式选择
Omnibus（Linux 包）
- 优点：官方一键安装，
gitlab-ctl统一管理所有组件；文档和备份脚本最完整。 - 缺点：与系统其他服务同机时资源争抢；升级需按发行版包流程。
- 适用：单节点或小型团队、首次自建、需要最快落地。
Docker / Docker Compose
- 优点：环境隔离、版本 pin 清晰、易于在测试机复现生产配置。
- 缺点：数据卷与升级策略需自行设计；大实例 I/O 与内存调优比 Omnibus 多一步。
- 适用：已有容器化运维体系、多环境快速拉起。
Kubernetes（Helm Chart）
- 优点：高可用、水平扩展 Gitaly/Sidekiq、与云原生栈一致。
- 缺点：架构复杂（需外置 PostgreSQL、Redis、对象存储）；运维门槛最高。
- 适用：数百人以上、多地域、已有 K8s 平台与 DBA 团队。
| 方式 | 运维复杂度 | 高可用 | 典型规模 |
|---|---|---|---|
| Omnibus 单机 | 低 | 需手动主从/备份 | < 100 用户 |
| Omnibus 多节点 | 中 | 组件可拆分 | 100～500 用户 |
| Docker Compose | 中 | 依赖外部 DB/存储 | 开发/中小生产 |
| Helm on K8s | 高 | Chart 支持分组件 HA | 500+ 或企业标准 |
下一章从 安装部署 开始，按 Omnibus 与 Docker 给出可执行步骤。