2. GitLab平台架构与部署选型

在动手安装 GitLab 之前，必须先回答一个比“装哪个版本”更根本的问题：这套平台以什么形态运行、由谁维护、故障时如何恢复。GitLab 官方提供三种主流部署形态——Omnibus 包、Helm Chart 与 GitLab Operator，它们并非简单的“新旧替代”关系，而是对应不同的运维能力、集群条件与生命周期管理诉求。选错形态，后期扩容、升级和排障的成本会成倍增加。

三种部署形态的本质差异

Omnibus 是“单机一体化”思路。它把 PostgreSQL、Redis、Gitaly、Sidekiq、Nginx、Puma 等所有组件打包进一个安装包，通过 /etc/gitlab/gitlab.rb 统一配置，再由 gitlab-ctl reconfigure 生成各组件配置并重启服务。它的优势是组件版本经过官方验证、依赖自洽、排障路径清晰；代价是单机资源上限明显，横向扩展需要手工拆分组件。

Helm Chart 是“Kubernetes 原生”思路。它把 GitLab 拆成多个 Deployment/StatefulSet，通过 values.yaml 声明式配置，依赖集群的 Service、Ingress、PVC、Secret 完成编排。它天然支持滚动升级与副本伸缩，但要求团队具备 K8s 运维能力，且对象存储、数据库、Redis 通常需要外部托管服务配合。

GitLab Operator 是“Chart 之上的自动化控制器”。它基于 Kubernetes Operator 模式，用 CRD（如 GitLab 自定义资源）描述期望状态，由控制器持续调谐实际状态。相比直接使用 Helm，Operator 能自动处理升级顺序、备份、证书轮换等有状态操作，适合希望把 GitLab 生命周期纳入 GitOps 流程的团队。

自建与云托管的取舍

形态确定后，第二个决策是“谁来运维”。自建（Self-Managed）意味着你拥有 GitLab 的全部控制权：数据落在自己的机房或私有云，可深度定制 Runner、镜像仓库、审计策略，也能满足等保与数据不出境要求。但代价是你要承担升级窗口、备份验证、容量规划、CVE 响应等全部责任。以 Omnibus 为例，一次跨大版本升级通常需要先备份、再停写、再升级、再验证，窗口期往往在 1～2 小时。

云托管（GitLab.com SaaS 或云厂商托管版）把底层运维交给服务方，团队只需管理命名空间、成员与 CI 配额。它适合快速起步、团队规模小、无强合规约束的场景。但要注意：SaaS 版的 Runner 共享资源存在排队，敏感代码上传到第三方需要评估；云厂商托管版虽然数据在境内，但版本节奏受服务方控制，某些高级功能可能滞后。

一个常见的折中方案是“自建核心 + 云上 Runner”：GitLab 主实例自建以保证代码与制品可控，CI Runner 部署在云上按需伸缩，兼顾安全与弹性。这种混合模式在中小团队中落地效果较好。

高可用架构设计要点

当团队规模超过 200 人、或 CI 并发持续走高时，单机 Omnibus 会成为瓶颈。此时需要按“无状态横向扩展、有状态主从复制”的原则拆分：

• 入口层：两台以上 Nginx 或云负载均衡，健康检查指向 /-/health，会话保持非必需（GitLab 使用 JWT）。
• 应用层：Puma/Workhorse 无状态，可部署多副本，共享同一数据库与 Redis。
• 数据层：PostgreSQL 采用主从 + Patroni 自动切换；Redis 使用 Sentinel 或 Cluster；Gitaly 按仓库分片，配合 Praefect 做路由与副本一致性。
• 存储层：制品、LFS、上传文件统一走对象存储（如 MinIO 或云 OSS），避免本地磁盘成为单点。
• 备份：数据库每日全量 + WAL 归档，Gitaly 仓库快照，备份文件异地存放并定期做恢复演练。

选型决策参考

最后强调一个容易被忽略的点：无论选哪种形态，都要在部署前确定外部访问地址（external_url）、对象存储桶和备份目标这三项。它们一旦上线后再变更，往往涉及证书、回调地址、Runner 注册和已有数据的迁移，成本远高于前期规划。把这三项写进部署检查清单，再开始安装，是本章最实用的落地建议。