00. GitLab 不只是代码托管：一套 DevOps 平台的 6 大核心能力

发表于 2026-11-11 分类于 GitLab

很多人以为 GitLab 只是个 Git 仓库，其实它是覆盖代码、CI/CD、安全、运维的研发一体化平台。本文建立对 GitLab 的宏观认知。

「GitLab」系列已发布： 00. GitLab 不只是代码托管：一套 DevOps 平台的 6 大核心能力（本文） ｜ 01. GitLab 怎么装最省心？Omnibus/Docker/K8s 三种姿势

很多人以为 GitLab 只是个 Git 仓库，其实它是覆盖代码、CI/CD、安全、运维的研发一体化平台。本文建立对 GitLab 的宏观认知。

前置条件

不需要装任何东西。这篇是 GitLab 系列的第一篇，帮你建立对整个平台的宏观认知。

一、GitLab 是什么

GitLab 是一个完整的 DevOps 平台。以 Git 仓库管理为核心，覆盖从 idea 到上线的整个软件开发生命周期——项目管理、源码管理、CI/CD、监控、安全合规，全在一个应用里。

和 GitHub、Bitbucket 比，GitLab 从一开始就把"企业自托管"和"DevOps 全链路"当成核心理念。GitHub 虽然后来也补了 Actions、Projects 等能力，但它的基因是开源社区协作。

能力维度	GitLab	GitHub	Bitbucket
代码托管	支持	支持	支持
CI/CD	内置	GitHub Actions	Bitbucket Pipelines
容器镜像仓库	内置 Container Registry	GitHub Packages	需外部集成
项目管理	Issue / Epic / Roadmap	Issues / Projects	Issues
安全扫描	内置 SAST/DAST/依赖扫描	Dependabot + CodeQL	需第三方
自托管部署	核心优势	GitHub Enterprise Server	Bitbucket Data Center
开源许可	MIT（社区版）	非开源	非开源

1.1 发展脉络

GitLab 是乌克兰开发者 Dmytro Zaporozhets 和荷兰人 Sid Sijbrandij 在 2011 年搞出来的。当时 Dmytro 想要一个自托管的代码管理平台，市面上的方案体验太差，于是自己用 Ruby on Rails 撸了第一版。

关键节点：

2011：首个版本发布，开源，托管在 GitHub 上。
2013：拆分社区版（CE）和企业版（EE）。
2015：拿到 Y Combinator 投资，搬去旧金山。同年推出 GitLab CI，把持续集成直接内建进平台。
2016：GitLab Pages、Container Registry、Issue Board 陆续上线。
2018：Auto DevOps —— 自动给项目配 CI/CD 流水线。
2020：收购 Peach Tech 和 Fuzzit，扩展安全测试。
2021：纳斯达克上市（GTLB），发布 GitLab 14.0。
2023：推出 GitLab Duo（AI 辅助套件），发布 16.0。
2024 至今：17.x 系列，持续整合 AI 能力。

1.2 版本体系

GitLab 有三种形态：

1.2.1 社区版（CE）

MIT 许可证，完全开源。有 Git 仓库管理、Issue 跟踪、Merge Request 代码审查、CI/CD 等核心功能。个人开发者和小团队自托管够用。

1.2.2 企业版（EE）

CE 基础上加了 LDAP/AD 集成、多集群管理、合规流水线、高级安全扫描、Epic、Roadmap 等。源码公开但许可证是专有的（EE License），生产环境使用需要付费订阅。

1.2.3 GitLab.com（SaaS）

官方托管，跑的是 EE 代码。免费用户享受大部分 CE + 部分 EE 功能，付费用户解锁全部 EE。不想自己维护服务器的团队直接用它。

怎么选？

flowchart TD
    Q1{"需要完全控制数据
和基础设施？"}
    Q1 -->|是| Self["自托管"]
    Q1 -->|否| SaaS["GitLab.com SaaS"]
    Self --> Q2{"需要高级安全/
合规/管理？"}
    Q2 -->|是| EE["EE（付费）"]
    Q2 -->|否| CE["CE 免费自托管"]
    SaaS --> Q3{"个人或小团队？"}
    Q3 -->|是| Free["Free 计划"]
    Q3 -->|否| Paid["付费计划"]

1.3 架构概览

自托管部署用的是单体应用 + 组件拆分的架构。核心是一个 Ruby on Rails 应用（Puma 做应用服务器），配合一组后台服务。

graph TB
    subgraph "用户层"
        Browser[浏览器/IDE]
        GitClient[Git 客户端]
    end
    subgraph "接入层"
        Nginx[Nginx 反向代理]
    end
    subgraph "应用层"
        Puma[Puma 应用服务器]
        Sidekiq[Sidekiq 后台任务]
        ActionCable[ActionCable WebSocket]
    end
    subgraph "数据层"
        PostgreSQL[(PostgreSQL)]
        Redis[(Redis)]
        Gitaly[Gitaly Git 存储]
    end
    subgraph "CI/CD 层"
        Runner[GitLab Runner]
        Registry[Container Registry]
    end
    
    Browser --> Nginx
    GitClient --> Nginx
    Nginx --> Puma
    Puma --> PostgreSQL
    Puma --> Redis
    Puma --> Gitaly
    Sidekiq --> PostgreSQL
    Sidekiq --> Redis
    Runner --> Nginx
    Registry --> Nginx

1.3.1 组件职责

组件	职责	部署要点
Nginx	反向代理、静态资源、HTTPS 终端	GitLab 自带编译版本，自动配置
Puma	Rails 应用服务器，处理 Web 请求	多进程 worker，可横向扩展
Sidekiq	异步任务（发邮件、创建 MR、同步仓库）	基于 Redis 队列，独立进程
PostgreSQL	存用户、项目、Issue 等元数据	最低 12.x，推荐 15.x+
Redis	缓存、Sidekiq 队列、会话、Action Cable	建议开持久化
Gitaly	Git 数据存储与操作	与应用层解耦，gRPC 通信
GitLab Shell	处理 SSH 协议的 Git 操作	轻量级 Go
GitLab Workhorse	智能反向代理，处理大文件上传/下载	在 Nginx 和 Puma 之间
GitLab Runner	执行 CI/CD Job	独立部署，任意机器
Container Registry	内置 Docker 镜像仓库	可选，基于 Docker Distribution

1.3.2 数据怎么走

一次 git push 的数据流：


# 一次 git push 的数据流：


# push (SSH/HTTPS)


# → GitLab Shell (SSH) 或 Workhorse (HTTPS)


# → Gitaly (gRPC)


# → 磁盘上的 Git 裸仓库


# → Redis（更新缓存）

浏览器访问 Merge Request 页面：

flowchart LR
    Browser[浏览器] --> Nginx[Nginx
静态直接回 / 动态转发]
    Nginx --> Workhorse[Workhorse
检查有没有大文件要处理]
    Workhorse --> Puma[Puma
处理业务逻辑、查库]
    Puma --> Gitaly[Gitaly
读 Git 数据、生成 diff]

1.4 Omnibus vs 云原生

1.4.1 Omnibus

官方推荐方式，所有组件打包在一个安装包里，一个配置文件 /etc/gitlab/gitlab.rb 统一管理。


# Debian/Ubuntu
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ee

好处：一条命令装完，维护成本低，升级用 apt upgrade，官方保证组件版本兼容。

坏处：组件耦合紧，难单独扩展，所有东西跑一台机器上，不符合云原生理念。

1.5 云原生（Helm Chart）

Kubernetes 环境用官方 Helm Chart，各组件独立 Pod 部署：

helm repo add gitlab https://charts.gitlab.io/
helm repo update
helm install gitlab gitlab/gitlab \
  --set global.hosts.domain=example.com \
  --set certmanager-issuer.email=admin@example.com

好处：组件独立扩缩容，天然适配 K8s 生态。

坏处：部署复杂度远高于 Omnibus，需要团队会运维 K8s，资源消耗大（最小部署也得约 10 个 Pod）。

1.5.1 选哪个

场景	推荐
个人 / <100 用户	Omnibus 单节点
100-500 用户	Omnibus + 外部 PostgreSQL/Redis
>500 用户 / 高可用	Helm Chart (K8s)
不想运维	GitLab.com SaaS

1.6 系列路线图

安装与环境部署（第 01 篇）
初始配置与管理员操作（第 02 篇）
用户、群组与权限管理（第 03 篇）
项目创建、导入与设置（第 04 篇）
Merge Request 代码审查流程（第 05 篇）
CI/CD 概念与架构（第 06 篇）
Runner 安装与注册（第 07 篇）
.gitlab-ci.yml编写基础（第 08 篇）
Pipeline 构建实战（第 09 篇）
缓存与工件管理（第 10 篇）
环境与部署策略（第 11 篇）
安全扫描与合规（第 12 篇）
Container Registry（第 13 篇）
Package Registry（第 14 篇）
高可用与备份恢复（第 15 篇）
Webhooks 与 API 集成（第 16 篇）
Pages（第 17 篇）
监控与运维（第 18 篇）
企业级管理实践（第 19 篇）

二、文章引用

📌 本文首发于微信公众号 【运维知识点滴】——专注运维实战干货，微信搜索“运维知识点滴”或扫下方二维码关注，更新不迷路。
📎 微信原文：00. GitLab 不只是代码托管：一套 DevOps 平台的 6 大核心能力

微信公众号【运维知识点滴】	微信小程序【A5单据合并&大试卷拆分转A4打印】

运维实战干货 · 关注追更	Word 转 PDF · 试卷/发票打印神器 · 免费

💡 小程序【A5单据合并&大试卷拆分转A4打印】是干嘛的？ 一个 Word 转 PDF 的打印神器，专治“文档版式和打印机对不上”：

A3 试卷打不出来？ 学校发的电子版试卷多是 A3，家用打印机只吃 A4——上传 Word 一键转换：可缩到一页 A4（页数不变），也可对半拆成两张 A4（1:1 原大、字更清晰），两种模式自选；

版式不乱：真实渲染引擎原样转换、绝不重排内容，转出的 PDF 和原 Word 排版一致，公式/表格/图片不跑版；

两张 A5 单据拼一张 A4：出租车票、火车票等报销凭证拼版后，一次打印、整齐粘贴；

隐私省心：无需注册，转换结果留存 5 天、最多下载 5 次即自动删除，不留任何历史记录；

微信扫码即用，免费、免安装，支持 doc / docx（≤50MB）。

下一篇：01. GitLab 怎么装最省心？Omnibus/Docker/K8s 三种姿势