目前我将整个 gitlab EE 作为单个容器运行。我需要扩展服务，以便它可以同时支持更多用户和更多操作/拉/推/合并请求等。
我需要自己运行一个redis集群
我需要单独运行一个 PG 集群
我需要集成elasticsearch进行搜索
但是我怎样才能扩展剩余的核心 gitlab 服务。它们是否支持横向扩展架构。
【问题讨论】：
标签： gitlab scaleout-hserver gitlab-ee
它们是否支持横向扩展架构。
不完全是，考虑到 GitLab Omnibus image 是 一个 带有捆绑依赖项的包。
但我从来没有遇到过需要拆分和横向扩展的流量。
有一个拆分 Omnibus 图像的建议：gitlab-org/omnibus-gitlab issue 1800。
它指出gitlab-org/build/CNG 正是您正在寻找的：
每个目录都包含运行 GitLab 所需的基础架构的特定组件的 Dockerfile。
- rails - API 和 Web 所需的 Rails 代码。
- unicorn - 暴露 Rails 的 Unicorn 容器。
- sidekiq - 运行异步 Rails 作业的 Sidekiq 容器
- shell - 运行 GitLab Shell 和 OpenSSH 以提供 git over ssh 和来自数据库的授权密钥支持
- gitaly - 提供分布式 git 存储库的 Gitaly 容器
使用 Kubernetes 的另一个选项是 charts/gitlab：
gitlab 图表是在 Kubernetes 上操作 GitLab 的最佳方式。此图表包含入门所需的所有组件，并且可以扩展到大型部署。
此图表和相应容器的一些主要优点是：
- 改进的可扩展性和可靠性
- 不需要root权限
- 使用对象存储而不是 NFS 进行存储
默认部署包括：
- 核心 GitLab 组件：Unicorn、Shell、Workhorse、Registry、Sidekiq 和 Gitaly
- 可选依赖项：Postgres、Redis、Minio
- 使用 Kubernetes 执行程序的自动缩放、非特权 GitLab Runner
- 通过 Let's Encrypt 自动配置 SSL。
2020 年 9 月更新：
GitLab 13.4 提供了一项可以帮助在本地扩展 GitLab 的功能：
Gitaly Cluster 多数获胜参考交易（测试版）
Gitaly Cluster 允许在多个 Gitaly 暖节点上复制 Git 存储库。这通过消除单点故障提高了容错能力。
Reference transactions，在 GitLab 13.3 中引入，会导致将更改广播到集群中的所有 Gitaly 节点，但只有与主节点投票同意的 Gitaly 节点才会将更改保存到磁盘。
如果所有副本节点都反对，则只有一个更改副本将保存到磁盘，从而在异步复制完成之前产生单点故障。多数获胜投票通过在将更改持久化到磁盘之前要求大多数节点同意来提高容错能力。启用功能标志后，写入必须在多个节点上成功。通过从构成仲裁的节点进行异步复制，异议节点会自动同步。
参见Documentation 和Issue。
【讨论】：