Help us learn about your current experience with the documentation. Take the survey.

GitLab 架构概述

软件交付

GitLab 有两个软件版本：

开源版 Community Edition（CE）。
开放核心版 Enterprise Edition（EE）。

EE 仓库已被归档。GitLab 现在运行于单一代码库下。

GitLab 提供多种订阅选项。

新版本的 GitLab 从稳定分支发布，而 main 分支用于前沿开发。

有关更多信息，请参见 GitLab 发布流程。

这两个版本都需要额外的组件。这些组件在组件详情部分中描述，并且每个组件都有自己的仓库。

每个依赖组件的新版本通常是标签形式，但保持在 GitLab 代码库的 main 分支上会获得这些组件的最新稳定版本。新版本通常与 GitLab 发布时间同步推出，除非是需要非正式安全更新的情况。

组件

典型的 GitLab 安装是在 GNU/Linux 上，但越来越多的部署也使用 Kubernetes 平台。已知最大的 GitLab 实例位于 GitLab.com，它使用我们的官方 GitLab Helm 图表和官方 Linux 包进行部署。

典型安装使用 NGINX 或 Apache 作为 Web 服务器，通过 GitLab Workhorse 代理到 Puma 应用程序服务器。GitLab 使用 Puma 应用程序服务器提供网页和 GitLab API。它使用 Sidekiq 作为作业队列，而 Sidekiq 又使用 Redis 作为非持久数据库后端来存储作业信息、元数据和传入作业。

默认情况下，Puma 和 Workhorse 之间的通信是通过 Unix 域套接字进行的，但也支持通过 TCP 转发请求。Workhorse 访问 gitlab/public 目录，绕过 Puma 应用程序服务器来提供静态页面、上传文件（例如头像图像或附件）和预编译资源。

GitLab 应用程序使用 PostgreSQL 来存储持久化数据库信息（例如用户、权限、问题或其他元数据）。GitLab 将裸 Git 仓库存储在配置文件的 repositories: 部分中定义的位置。它还将默认分支和钩子信息与裸仓库一起保存。

当通过 HTTP/HTTPS 提供仓库时，GitLab 使用 GitLab API 来解析授权和访问权限，并提供 Git 对象。

附加组件 GitLab Shell 通过 SSH 提供仓库服务。它在配置文件的 GitLab Shell 部分中定义的位置管理 SSH 密钥。该位置的文件不应手动编辑。GitLab Shell 通过 Gitaly 访问裸仓库以提供 Git 对象，并与 Redis 通信以向 Sidekiq 提交作业供 GitLab 处理。GitLab Shell 查询 GitLab API 以确定授权和访问权限。

Gitaly 执行来自 GitLab Shell 和 GitLab Web 应用的 Git 操作，并为 GitLab Web 应用提供 API 来获取 Git 属性（例如标题、分支、标签或其他元数据），以及获取 blob（例如差异、提交或文件）。

您可能还对 GitLab.com 的生产架构感兴趣。

适应现有组件并引入新组件

应用程序安装在传统 Linux 机器上与安装在容器化平台（如 Kubernetes）上的行为存在根本差异。

与我们官方安装方法相比，一些显著差异包括：

官方 Linux 包可以访问同一文件系统中的不同服务的文件。共享文件对于在 Kubernetes 平台上运行的应用程序来说不是一种选择。
官方 Linux 包默认具有可以访问共享配置和网络的服务。而对于在 Kubernetes 中运行的服务则不然，这些服务可能完全隔离运行，或者只能通过特定端口访问。

换句话说，在设计新功能并添加新组件时，服务之间的共享状态需要仔细考量。需要访问相同文件的服务，必须能够通过适当的API交换信息。只要有可能，不应通过文件来实现这一点。

由于采用API优先理念编写的组件兼容这两种方法，所有新功能和服务的编写都必须优先考虑Kubernetes兼容性。

确保这一点的最简单方式，是为你的功能或服务添加对官方GitLab Helm Chart的支持，或者联系Distribution团队。

有关更多详情，请参阅添加新服务组件的流程。

简化组件概述

这是一个简化的架构图，可用于理解GitLab架构。

完整的架构图可在下方的组件图中查看。

%%{init: {"flowchart": { "useMaxWidth": false } }}%%
graph TB
  %% Component declarations and formatting
  HTTP((HTTP/HTTPS))
  SSH((SSH))
  GitLabPages(GitLab Pages)
  GitLabWorkhorse(GitLab Workhorse)
  GitLabShell(GitLab Shell)
  Gitaly(Gitaly)
  Puma("Puma (GitLab Rails)")
  Sidekiq("Sidekiq (GitLab Rails)")
  PostgreSQL(PostgreSQL)
  Redis(Redis)

HTTP -- TCP 80,443 --> NGINX
  SSH -- TCP 22 --> GitLabShell

NGINX -- TCP 8090 --> GitLabPages
  NGINX --> GitLabWorkhorse

GitLabShell --> Gitaly
  GitLabShell --> GitLabWorkhorse

GitLabWorkhorse --> Gitaly
  GitLabWorkhorse --> Puma
  GitLabWorkhorse --> Redis

Sidekiq --> PostgreSQL
  Sidekiq --> Redis

Puma --> PostgreSQL
  Puma --> Redis
  Puma --> Gitaly

Gitaly --> GitLabWorkhorse

所有连接均使用Unix套接字，除非另有说明。

组件图

%%{init: {"flowchart": { "useMaxWidth": false } }}%%
graph LR
  %% Anchor items in the appropriate subgraph.
  %% Link them where the destination* is.

subgraph Clients
    Browser((Browser))
    Git((Git))
  end

%% External Components / Applications
  Geo{{GitLab Geo}} -- TCP 80, 443 --> HTTP
  Geo -- TCP 22 --> SSH
  Geo -- TCP 5432 --> PostgreSQL
  Runner{{GitLab Runner}} -- TCP 443 --> HTTP
  K8sAgent{{GitLab agent}} -- TCP 443 --> HTTP

%% GitLab Application Suite
  subgraph GitLab
    subgraph Ingress
        HTTP[[HTTP/HTTPS]]
        SSH[[SSH]]
        NGINX[NGINX]
        GitLabShell[GitLab Shell]

%% inbound/internal
        Browser -- TCP 80,443 --> HTTP
        Git -- TCP 80,443 --> HTTP
        Git -- TCP 22 --> SSH
        HTTP -- TCP 80, 443 --> NGINX
        SSH -- TCP 22 --> GitLabShell
    end

subgraph GitLab Services
        %% inbound from NGINX
        NGINX --> GitLabWorkhorse
        NGINX -- TCP 8090 --> GitLabPages
        NGINX -- TCP 8150 --> GitLabKas
        NGINX --> Registry
        %% inbound from GitLabShell
        GitLabShell --> GitLabWorkhorse

%% services
        Puma["Puma (GitLab Rails)"]
        Puma <--> Registry
        GitLabWorkhorse[GitLab Workhorse] <--> Puma
        GitLabKas[GitLab agent server] --> GitLabWorkhorse
        GitLabPages[GitLab Pages] --> GitLabWorkhorse
        Mailroom
        Sidekiq
    end

subgraph Integrated Services
        %% Mattermost
        Mattermost
        Mattermost ---> GitLabWorkhorse
        NGINX --> Mattermost

%% Grafana
        Grafana
        NGINX --> Grafana
    end

subgraph Metadata
        %% PostgreSQL
        PostgreSQL
        PostgreSQL --> Consul

%% Consul and inbound
        Consul
        Puma ---> Consul
        Sidekiq ---> Consul
        Migrations --> PostgreSQL

%% PgBouncer and inbound
        PgBouncer
        PgBouncer --> Consul
        PgBouncer --> PostgreSQL
        Sidekiq --> PgBouncer
        Puma --> PgBouncer
    end

subgraph State
        %% Redis and inbound
        Redis
        Puma --> Redis
        Sidekiq --> Redis
        GitLabWorkhorse --> Redis
        Mailroom --> Redis
        GitLabKas --> Redis

%% Sentinel and inbound
        Sentinel <--> Redis
        Puma --> Sentinel
        Sidekiq --> Sentinel
        GitLabWorkhorse --> Sentinel
        Mailroom --> Sentinel
        GitLabKas --> Sentinel
    end

subgraph Git Repositories
        %% Gitaly / Praefect
        Praefect --> Gitaly
        GitLabKas --> Praefect
        GitLabShell --> Praefect
        GitLabWorkhorse --> Praefect
        Puma --> Praefect
        Sidekiq --> Praefect
        Praefect <--> PraefectPGSQL[PostgreSQL]
        %% Gitaly makes API calls
        %% Ordered here to ensure placement.
        Gitaly --> GitLabWorkhorse
    end

subgraph 存储 %% 对象存储及入站流量 ObjectStorage[“对象存储”] Puma – TCP 443 –> ObjectStorage Sidekiq – TCP 443 –> ObjectStorage GitLabWorkhorse – TCP 443 –> ObjectStorage Registry – TCP 443 –> ObjectStorage GitLabPages – TCP 443 –> ObjectStorage %% Gitaly 可将仓库备份到对象存储。 Gitaly –> ObjectStorage end

subgraph 监控 %% Prometheus Grafana – TCP 9090 –> Prometheus[Prometheus] Prometheus – TCP 80, 443 –> Puma RedisExporter[Redis 导出器] –> Redis Prometheus – TCP 9121 –> RedisExporter PostgreSQLExporter[PostgreSQL 导出器] –> PostgreSQL PgBouncerExporter[PgBouncer 导出器] –> PgBouncer Prometheus – TCP 9187 –> PostgreSQLExporter Prometheus – TCP 9100 –> NodeExporter[Node 导出器] Prometheus – TCP 9168 –> GitLabExporter[GitLab 导出器] Prometheus – TCP 9127 –> PgBouncerExporter Prometheus –> Alertmanager GitLabExporter –> PostgreSQL GitLabExporter –> GitLabShell GitLabExporter –> Sidekiq %% Alertmanager Alertmanager – TCP 25 –> SMTP end %% end subgraph GitLab end

subgraph 外部服务 subgraph 外部服务 SMTP[SMTP 网关] LDAP

    %% 出站 SMTP
    Sidekiq -- TCP 25 --> SMTP
    Puma -- TCP 25 --> SMTP
    Mailroom -- TCP 25 --> SMTP

    %% 出站 LDAP
    Puma -- TCP 369 --> LDAP
    Sidekiq -- TCP 369 --> LDAP

    %% Elasticsearch
    Elasticsearch
    Puma -- TCP 9200 --> Elasticsearch
    Sidekiq -- TCP 9200 --> Elasticsearch
    Elasticsearch --> Praefect

    %% Zoekt
    Zoekt --> Praefect
end
subgraph 外部监控
    %% Sentry
    Sidekiq -- TCP 80, 443 --> Sentry
    Puma -- TCP 80, 443 --> Sentry

    %% Jaeger
    Jaeger
    Sidekiq -- UDP 6831 --> Jaeger
    Puma -- UDP 6831 --> Jaeger
    Gitaly -- UDP 6831 --> Jaeger
    GitLabShell -- UDP 6831 --> Jaeger
    GitLabWorkhorse -- UDP 6831 --> Jaeger
end

%% end subgraph 外部服务 end

click Alertmanager “#alertmanager” click Praefect “#praefect” click Geo “#gitlab-geo” click NGINX “#nginx” click Runner “#gitlab-runner” click Registry “#registry” click ObjectStorage “#minio” click Mattermost “#mattermost” click Gitaly “#gitaly” click Jaeger “#jaeger” click GitLabWorkhorse “#gitlab-workhorse” click LDAP “#ldap-authentication” click Puma “#puma” click GitLabShell “#gitlab-shell” click SSH “#ssh-request-22” click Sidekiq “#sidekiq” click Sentry “#sentry” click GitLabExporter “#gitlab-exporter” click Elasticsearch “#elasticsearch” click Migrations “#database-migrations” click PostgreSQL “#postgresql” click Consul “#consul” click PgBouncer “#pgbouncer” click PgBouncerExporter “#pgbouncer-exporter” click RedisExporter “#redis-exporter” click Redis “#redis” click Prometheus “#prometheus” click Grafana “#grafana” click GitLabPages “#gitlab-pages” click PostgreSQLExporter “#postgresql-exporter” click SMTP “#outbound-email” click NodeExporter “#node-exporter”

组件状态说明

✅ - 已默认安装
⚙ - 需额外配置
⤓ - 需手动安装
❌ - 不支持或无说明
N/A - 不适用

组件状态与各组件配置文档关联。

组件列表

|——————————————————-|—————————————————————-|:————–:|:————–:|:————:|:—————-:|:———-:|:——:|:—:|:——-:|

| 证书管理 | TLS 设置，Let’s Encrypt | ✅ | ✅ | ✅ | ⚙ | ✅ | ⚙ | ⚙ | CE & EE |

| Consul | 数据库节点发现，故障转移 | ⚙ | ✅ | ❌ | ❌ | ✅ | ❌ | ❌ | EE Only |

| Database Migrations | 数据库迁移 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE |

| Elasticsearch | 改进GitLab内的搜索 | ⤓ | ⚙ | ⤓ | ⤓ | ✅ | ⤓ | ⚙ | EE Only |

| Gitaly | 处理GitLab所有Git调用的Git RPC服务 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE |

| GitLab Exporter | 生成各种GitLab指标 | ✅ | ✅ | ✅ | ✅ | ✅ | ❌ | ❌ | CE & EE |

| GitLab Geo | 地理分布的GitLab站点 | ⚙ | ⚙ | ❌ | ❌ | ✅ | ❌ | ⚙ | EE Only |

| GitLab Pages | 托管静态网站 | ⚙ | ⚙ | ⚙ | ❌ | ✅ | ⚙ | ⚙ | CE & EE |

| GitLab agent for Kubernetes | 以云原生方式集成Kubernetes集群 | ⚙ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | EE Only |

| GitLab self-monitoring: Alertmanager | 去重、分组并路由来自Prometheus的警报 | ⚙ | ⚙ | ✅ | ⚙ | ✅ | ❌ | ❌ | CE & EE |

| GitLab self-monitoring: Grafana | 指标仪表板 | ✅ | ✅ | ⚙ | ⤓ | ✅ | ❌ | ⚙ | CE & EE |

| GitLab self-monitoring: Jaeger | 查看由GitLab实例生成的跟踪信息 | ❌ | ⚙ | ⚙ | ❌ | ❌ | ⤓ | ⚙ | CE & EE |

| GitLab self-monitoring: Prometheus | 时序数据库、指标收集和查询服务 | ✅ | ✅ | ✅ | ⚙ | ✅ | ❌ | ⚙ | CE & EE |

| GitLab self-monitoring: Sentry | 跟踪由GitLab实例产生的错误 | ⤓ | ⤓ | ⤓ | ❌ | ✅ | ⤓ | ⤓ | CE & EE |

| GitLab Shell | 处理SSH会话中的git | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE |

| GitLab Workhorse | 智能反向代理，处理大型HTTP请求 | ✅ | ✅ | ✅ | ✅ | ✅ | ⚙ | ✅ | CE & EE |

| Inbound email (SMTP) | 接收消息以更新问题 | ⤓ | ⤓ | ⚙ | ⤓ | ✅ | ⤓ | ⤓ | CE & EE |

| Jaeger integration | 已部署应用的分布式追踪 | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⤓ | ⚙ | EE Only |

| LDAP Authentication | 针对集中式LDAP目录验证用户 | ⤓ | ⤓ | ⤓ | ⤓ | ❌ | ⤓ | ⚙ | CE & EE |

| Mattermost | 开源Slack替代方案 | ⚙ | ⚙ | ⤓ | ⤓ | ⤓ | ❌ | ⚙ | CE & EE |

| MinIO | 对象存储服务 | ⤓ | ⤓ | ✅ | ✅ | ✅ | ❌ | ⚙ | CE & EE |

| NGINX | 将请求路由到适当组件，终止SSL | ✅ | ✅ | ✅ | ⚙ | ✅ | ⤓ | ⚙ | CE & EE |

| Node Exporter | 带有系统指标的Prometheus端点 | ✅ | ✅ | N/A | N/A | ✅ | ❌ | ❌ | CE & EE |

出站邮件（SMTP）	向用户发送电子邮件	⤓	⤓	⚙	⤓	✅	⤓	⤓	CE & EE
Patroni	管理 PostgreSQL 高可用集群的领导者选举和复制	⚙	✅	❌	❌	✅	❌	❌	EE Only
PgBouncer Exporter	包含 PgBouncer 指标的 Prometheus 端点	⚙	✅	❌	❌	✅	❌	❌	CE & EE
PgBouncer	数据库连接池，故障转移	⚙	✅	❌	❌	✅	❌	❌	EE Only
PostgreSQL Exporter	包含 PostgreSQL 指标的 Prometheus 端点	✅	✅	✅	✅	✅	❌	❌	CE & EE
PostgreSQL	数据库	✅	✅	✅	✅	✅	⤓	✅	CE & EE
Praefect	任何 Git 客户端与 Gitaly 存储节点之间的透明代理。	✅	✅	⚙	❌	❌	⚙	✅	CE & EE
Puma (GitLab Rails)	处理 Web 界面和 API 的请求	✅	✅	✅	✅	✅	⚙	✅	CE & EE
Redis Exporter	包含 Redis 指标的 Prometheus 端点	✅	✅	✅	✅	✅	❌	❌	CE & EE
Redis	缓存服务	✅	✅	✅	✅	✅	⤓	✅	CE & EE
Registry	容器注册表，允许推送和拉取镜像	⚙	⚙	✅	✅	✅	⤓	⚙	CE & EE
Runner	执行 GitLab CI/CD 作业	⤓	⤓	✅	⚙	✅	⚙	⚙	CE & EE
Sentry 集成	已部署应用的错误跟踪	⤓	⤓	⤓	⤓	⤓	⤓	⤓	CE & EE
Sidekiq	后台任务处理器	✅	✅	✅	✅	✅	✅	✅	CE & EE
令牌吊销 API	接收并吊销泄露的秘密	❌	❌	❌	❌	✅	❌	❌	EE Only

组件详情

本文档旨在供希望了解 GitLab 内部原理及其协同工作方式的系统管理员和 GitLab 支持工程师使用。

当部署时，应将 GitLab 视为以下流程的组合。在故障排除或调试时，请尽可能明确您所引用的组件。这应该能提高清晰度并减少混淆。

层级

从进程角度来看，GitLab 可以被认为有两个层级：

监控层：此层的任何内容都不是交付 GitLab 应用所必需的，但它能让管理员更深入了解其基础设施以及整个服务的运行情况。
核心层：对作为平台的 GitLab 交付至关重要的任何进程。如果这些进程中任何一个停止，就会导致 GitLab 停机。对于核心层，您可以进一步划分为：
- 处理器进程：这些进程负责实际执行操作并提供服务。
- 数据服务：这些服务存储/暴露 GitLab 服务所需的结构化数据。

Alertmanager

项目页面
配置：
- Omnibus
- Charts
层级：监控层

- 进程：`alertmanager`

- GitLab.com: [GitLab.com 监控](https://handbook.gitlab.com/handbook/engineering/monitoring/)

[Alert manager](https://prometheus.io/docs/alerting/latest/alertmanager/) 是 Prometheus 提供的工具，_“处理由客户端应用程序（如 Prometheus 服务器）发送的警报。它负责去重、分组并将它们路由到正确的接收器集成，例如电子邮件、PagerDuty 或 Opsgenie。它还负责警报的静默和抑制。”_ 你可以在 [issue #45740](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/45740) 中阅读更多我们警报的内容。

#### 证书管理

- 项目页面：
- [Omnibus](https://github.com/certbot/certbot/blob/master/README.rst)
- [Charts](https://github.com/cert-manager/cert-manager/blob/master/README.md)

- 配置：
- [Omnibus](https://docs.gitlab.com/omnibus/settings/ssl/)
- [Charts](https://docs.gitlab.com/charts/installation/tls.html)
- [Source](../install/self_compiled/_index.md#using-https)
- [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/howto/nginx.md)

- 层：核心服务（处理器）

- GitLab.com: [密钥管理](https://handbook.gitlab.com/handbook/engineering/infrastructure/production/architecture/#secrets-management)

#### Consul

- [项目页面](https://github.com/hashicorp/consul/blob/main/README.md)

- 配置：
- [Omnibus](../administration/consul.md)
- [Charts](https://docs.gitlab.com/charts/installation/deployment.html#postgresql)

- 层：核心服务（数据）

- GitLab.com: [Consul](../user/gitlab_com/_index.md#consul)

Consul 是一种用于服务发现和配置的工具。Consul 是分布式的、高可用的且极具可扩展性的。

#### 数据库迁移

- 配置：
- [Omnibus](https://docs.gitlab.com/omnibus/settings/database.html#disabling-automatic-database-migration)
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/migrations/)
- [Source](../update/upgrading_from_source.md#install-libraries-and-run-migrations)

- 层：核心服务（数据）

#### Elasticsearch

- [项目页面](https://github.com/elastic/elasticsearch/)

- 配置：
- [Omnibus](../integration/advanced_search/elasticsearch.md)
- [Charts](../integration/advanced_search/elasticsearch.md)
- [Source](../integration/advanced_search/elasticsearch.md)
- [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/elasticsearch.md)

- 层：核心服务（数据）

- GitLab.com: [在 GitLab.com 上启用高级搜索（已关闭）](https://gitlab.com/groups/gitlab-org/-/epics/153) epic。

Elasticsearch 是一款专为云端构建的分布式 RESTful 搜索引擎。

#### Gitaly

- [项目页面](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md)

- 配置：
- [Omnibus](../administration/gitaly/_index.md)
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/gitaly/)
- [Source](../install/self_compiled/_index.md#install-gitaly)

- 层：核心服务（数据）

- 进程：`gitaly`

Gitaly 是 GitLab 设计的服务，旨在消除分布式部署中对 NFS 的需求（想想 GitLab.com 或高可用部署）。从 11.3.0 版本起，此服务处理 GitLab 中的所有 Git 级别访问。你可以在项目的 README 中了解更多信息 [in the project's README](https://gitlab.com/gitlab-org/gitaly)。

#### Praefect

- [项目页面](https://gitlab.com/gitlab-org/gitaly/blob/master/README.md)

- 配置：
- [Omnibus](../administration/gitaly/_index.md)
- [Source](../install/self_compiled/_index.md#install-gitaly)

- 层：核心服务（数据）

- 进程：`praefect`

Praefect 是一个透明代理，位于每个 Git 客户端与 Gitaly 之间，负责协调将仓库更新复制到次要节点。

#### GitLab Geo

- 配置：
- [Omnibus](../administration/geo/setup/_index.md)
- [Charts](https://docs.gitlab.com/charts/advanced/geo/)
- [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/geo.md)

- 层：核心服务（处理器）

Geo 是一项高级功能，旨在通过提供一个或多个主 GitLab 实例的只读镜像来帮助加快分布式团队的研发速度。这个镜像（即 Geo 次级站点）减少了克隆或获取大型仓库和项目的时间，也可作为灾难恢复解决方案的一部分。

#### GitLab Exporter

- [项目页面](https://gitlab.com/gitlab-org/ruby/gems/gitlab-exporter)

- 配置：
- [Omnibus](../administration/monitoring/prometheus/gitlab_exporter.md)
- [Charts](https://docs.gitlab.com/charts/charts/gitlab/gitlab-exporter/)

- 层：监控

- 进程：`gitlab-exporter`

- GitLab.com: [GitLab.com 监控](https://handbook.gitlab.com/handbook/engineering/monitoring/)

GitLab Exporter 是一个内部设计的过程，允许我们将关于 GitLab 应用程序内部指标的度量数据导出到 Prometheus。你可以在项目的 README 中了解更多信息 in the project’s README。

GitLab agent for Kubernetes

GitLab agent for Kubernetes 是一个活跃的集群内组件，用于以安全且云原生的方式解决 GitLab 和 Kubernetes 的集成任务。

你可以使用它将部署同步到你的 Kubernetes 集群中。

GitLab Pages

配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
GitLab.com：GitLab Pages

GitLab Pages 是一项功能，允许你直接从 GitLab 仓库发布静态网站。

你可以将其用于个人或商业网站，例如作品集、文档、宣言和商业演示文稿。你也可以为你的内容附加任何许可证。

GitLab Runner

项目页面
配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
GitLab.com：Runner

GitLab Runner 运行作业并将结果发送给 GitLab。

GitLab CI/CD 是包含在 GitLab 中的开源持续集成服务，负责协调测试工作。此项目的旧名称是 GitLab CI Multi Runner，但从现在起你应该使用 GitLab Runner（不含 CI）。

GitLab Shell

项目页面
文档
配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）

GitLab Shell 是 GitLab 设计的一个程序，用于处理基于 SSH 的 git 会话，并修改授权密钥列表。GitLab Shell 不是 Unix shell，也不是 Bash 或 Zsh 的替代品。

GitLab Workhorse

项目页面
配置：
Omnibus
Charts
源码
层级：核心服务（处理器）
进程：gitlab-workhorse

GitLab Workhorse 是 GitLab 设计的一个程序，旨在帮助缓解 Puma 的压力。你可以阅读更多关于其开发的历史原因。它被设计为一个智能反向代理，有助于整体加速 GitLab。

Grafana

项目页面
配置：
Omnibus
Charts
层级：监控
GitLab.com：GitLab 问题排查 Grafana 仪表板

Grafana 是一个开源的、功能丰富的指标仪表盘和图形编辑器，支持 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB。

Jaeger

项目页面
配置：
Omnibus
Charts
源码
GDK
层级：监控
GitLab.com：为 GitLab 实例启用追踪功能的配置问题。

Jaeger 受 Dapper 和 OpenZipkin 启发，是一个分布式追踪系统。它可以用于监控基于微服务的分布式系统。

Logrotate

项目页面
配置：
Omnibus
层级：核心服务
进程：logrotate

GitLab 由大量服务组成，这些服务都会记录日志。我们打包了自己的 Logrotate 以确保负责任地记录日志。这只是常见开源版本的打包版。

Mattermost

项目页面
配置：
Omnibus
Charts
层级：核心服务（处理器）
GitLab.com：Mattermost

Mattermost 是一个开源的私有云 Slack 替代方案，来自 https://mattermost.com。

MinIO

项目页面
配置：
Omnibus
Charts
GDK
层级：核心服务（数据）
GitLab.com：存储架构

MinIO 是一个基于 GNU AGPL v3.0 许可发布的对象存储服务器。它与亚马逊 S3 云存储服务兼容。它最适合存储非结构化数据，如照片、视频、日志文件、备份以及容器/虚拟机镜像。对象大小可以从几 KB 到最大 5 TB 不等。

NGINX

项目页面：
Omnibus
Charts
配置：
Omnibus
Charts
源码
层级：核心服务（处理器）
进程：nginx

NGINX 有一个用于所有 HTTP 请求的入口端口，并将它们路由到 GitLab 内部的适当子系统。我们打包了流行的开源 Web 服务器的未修改版本。

Node Exporter

项目页面
配置：
Omnibus
Charts
层级：监控
进程：node-exporter
GitLab.com：GitLab.com 监控

Node Exporter 是 Prometheus 的一个工具，为我们提供底层机器的指标（例如 CPU/磁盘/负载）。这只是 Prometheus 项目提供的常见开源版本的打包版。

Patroni

项目页面
配置：
Omnibus
层级：核心服务（数据）
进程：patroni
GitLab.com：数据库架构

PgBouncer

项目页面
配置：
Omnibus
Charts
层级：核心服务（数据）
GitLab.com：数据库架构

轻量级 PostgreSQL 连接池器。

PgBouncer Exporter

项目页面
配置：
Omnibus
Charts
层级：监控
GitLab.com：GitLab.com 监控

PgBouncer 的 Prometheus 导出器。在 9127/metrics 端点导出指标。

PostgreSQL

项目页面
配置：
Omnibus
Charts
源码
层级：核心服务（数据）
进程：postgresql
GitLab.com：PostgreSQL

GitLab 打包了这个流行的数据库，以提供应用程序元数据和用户信息的存储。

#### PostgreSQL Exporter

- [项目页面](https://github.com/prometheus-community/postgres_exporter/blob/master/README.md)

- 配置：

- [Omnibus](../administration/monitoring/prometheus/postgres_exporter.md)

- [Chart 图表](https://docs.gitlab.com/charts/installation/deployment.html#postgresql)

- 层级：监控 (Monitoring)

- 进程：`postgres-exporter`

- GitLab.com：[GitLab.com 监控](https://handbook.gitlab.com/handbook/engineering/monitoring/)

[`postgres_exporter`](https://github.com/prometheus-community/postgres_exporter) 是社区提供的 Prometheus 导出器，它向 Prometheus 提供关于 PostgreSQL 的数据，用于在 Grafana 仪表板中使用。

#### Prometheus

- [项目页面](https://github.com/prometheus/prometheus/blob/main/README.md)

- 配置：

- [Omnibus](../administration/monitoring/prometheus/_index.md)

- [Chart 图表](https://docs.gitlab.com/charts/installation/deployment.html#prometheus)

- 层级：监控 (Monitoring)

- 进程：`prometheus`

- GitLab.com：[Prometheus](../user/gitlab_com/_index.md#prometheus)

Prometheus 是一个时间序列工具，帮助 GitLab 管理员暴露有关提供 GitLab 服务的各个进程的指标。

#### Redis

- [项目页面](https://github.com/redis/redis/blob/unstable/README.md)

- 配置：

- [Omnibus](https://docs.gitlab.com/omnibus/settings/redis.html)

- [Chart 图表](https://docs.gitlab.com/charts/installation/deployment.html#redis)

- [源码](../install/self_compiled/_index.md#8-redis)

- 层级：核心服务 (数据) (Core Service (Data))

- 进程：`redis`

Redis 被打包以提供一个存储位置：

- 会话数据

- 临时缓存信息

- 后台作业队列

有关 GitLab 如何使用 Redis 的更多信息，请参阅我们的 [Redis 指南](redis.md)。

#### Redis Exporter

- [项目页面](https://github.com/oliver006/redis_exporter/blob/master/README.md)

- 配置：

- [Omnibus](../administration/monitoring/prometheus/redis_exporter.md)

- [Chart 图表](https://docs.gitlab.com/charts/installation/deployment.html#redis)

- 层级：监控 (Monitoring)

- 进程：`redis-exporter`

- GitLab.com：[GitLab.com 监控](https://handbook.gitlab.com/handbook/engineering/monitoring/)

[Redis Exporter](https://github.com/oliver006/redis_exporter) 旨在向 Prometheus 提供 Redis 进程的具体指标，以便我们可以在 Grafana 中绘制这些指标的图表。

#### Registry

- [项目页面](https://gitlab.com/gitlab-org/container-registry)

- 配置：

- [Omnibus](../administration/packages/container_registry.md)

- [Chart 图表](https://docs.gitlab.com/charts/charts/registry/)

- [源码](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md?ref_type=heads)

- [GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/registry.md)

- 层级：核心服务 (处理器) (Core Service (Processor))

- GitLab.com：[GitLab 容器注册表](../user/packages/container_registry/build_and_push_images.md#use-gitlab-cicd)

注册表是用户用来存储自己 Docker 镜像的地方。捆绑的注册表使用 NGINX 作为负载均衡器，GitLab 作为身份验证管理器。每当客户端请求从注册表中拉取或推送镜像时，它会返回一个 `401` 响应，并附带一个标头，详细说明如何获取身份验证令牌（在本例中是 GitLab 实例）。然后客户端会向 GitLab 请求拉取或推送的身份验证令牌，并重试对注册表的原始请求。有关更多信息，请参阅 [令牌认证](https://distribution.github.io/distribution/spec/auth/token/)。

也可以配置外部注册表使用 GitLab 作为身份验证端点。

#### Sentry

- [项目页面](https://github.com/getsentry/sentry/)

- 配置：

- [Omnibus](https://docs.gitlab.com/omnibus/settings/configuration.html#error-reporting-and-logging-with-sentry)

- [Chart 图表](https://docs.gitlab.com/charts/charts/globals#sentry-settings)

- [源码](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)

- [GDK](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)

- 层级：监控 (Monitoring)

- GitLab.com：[搜索 Sentry](https://handbook.gitlab.com/handbook/support/workflows/500_errors/#searching-sentry)

从根本上说，Sentry 是一个帮助您实时监控和修复崩溃的服务。服务器是用 Python 编写的，但它包含了一个完整的 API，可以从任何语言的任何应用程序发送事件。

要监控已部署的应用程序，请参阅 [Sentry 集成文档](../operations/error_tracking.md)

#### Sidekiq

- [项目页面](https://github.com/sidekiq/sidekiq/blob/main/README.md)

- 配置：

- [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template)

- [Chart 图表](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/)

- [minikube 最小化安装](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/)

- [源码](https://gitlab.com/gitlab-org/gitlab/-/blob/master/config/gitlab.yml.example)

GDK
层级：核心服务（处理器）
进程：sidekiq
GitLab.com：Sidekiq

Sidekiq 是一个 Ruby 后台任务处理器，从 Redis 队列中提取任务并处理它们。后台任务使 GitLab 能够通过将工作移到后台来提供更快的请求/响应周期。

Puma

从 GitLab 13.0 开始，Puma 成为默认的 Web 服务器。

项目页面
配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
进程：puma
GitLab.com：Puma

Puma 是一个用于运行提供 GitLab 用户界面功能的 Rails 应用程序的核心 Ruby 应用服务器。在进程输出中通常显示为 bundle 或 config.ru，具体取决于 GitLab 版本。

LDAP 认证

配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
GitLab.com：产品层级

外发邮件

配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
GitLab.com：邮件配置

内收邮件

配置：
Omnibus
Charts
源码
GDK
层级：核心服务（处理器）
GitLab.com：邮件配置

按请求类型划分的 GitLab

GitLab 为终端用户提供两种访问服务的"接口"：

Web HTTP 请求（查看 UI/API）
Git HTTP/SSH 请求（推送/拉取 Git 数据）

理解这种区别很重要，因为有些进程同时用于这两种情况，而其他进程则仅限于特定类型的请求。

GitLab Web HTTP 请求周期

当向 HTTP 端点发出请求时（例如 /users/sign_in），请求会经过以下路径通过 GitLab 服务：

NGINX - 作为我们的第一层反向代理。
GitLab Workhorse - 这决定了是否需要转到 Rails 应用程序或其他地方以减少 Puma 的负载。
Puma - 由于这是 Web 请求且需要访问应用程序，因此它路由到 Puma。
PostgreSQL/Gitaly/Redis - 根据请求类型的不同，可能会命中这些服务来存储或检索数据。

GitLab Git 请求周期

下面我们描述 HTTP 与 SSH Git 请求所采用的不同路径。这与 Web 请求周期有一些重叠，但也有一些差异。

Web 请求（80/443）

通过 HTTP 进行的 Git 操作使用无状态的"智能"协议，如 Git 文档中所述，但这些操作的处理责任分布在多个 GitLab 组件之间。

以下是 git fetch 的序列图。所有请求都通过 NGINX 和其他任何 HTTP 负载均衡器，但不会被它们以任何方式转换。所有路径均相对于 /namespace/project.git URL 呈现。

sequenceDiagram
    participant Git on client
    participant NGINX
    participant Workhorse
    participant Rails
    participant Gitaly
    participant Git on server

Note left of Git on client: git fetch<br/>info-refs
    Git on client->>+Workhorse: GET /info/refs?service=git-upload-pack
    Workhorse->>+Rails: GET /info/refs?service=git-upload-pack
    Note right of Rails: 身份验证检查
    Rails-->>-Workhorse: Gitlab::Workhorse.git_http_ok
    Workhorse->>+Gitaly: SmartHTTPService.InfoRefsUploadPack 请求
    Gitaly->>+Git on server: git upload-pack --stateless-rpc --advertise-refs
    Git on server-->>-Gitaly: git upload-pack 响应
    Gitaly-->>-Workhorse: SmartHTTPService.InfoRefsUploadPack 响应
    Workhorse-->>-Git on client: 200 OK

Note left of Git on client: git fetch
fetch-pack Git on client-»+Workhorse: POST /git-upload-pack Workhorse-»+Rails: POST /git-upload-pack Note right of Rails: 身份验证检查 Rails–»-Workhorse: Gitlab::Workhorse.git_http_ok Workhorse-»+Gitaly: SmartHTTPService.PostUploadPack 请求 Gitaly-»+Git on server: git upload-pack –stateless-rpc Git on server–»-Gitaly: git upload-pack 响应 Gitaly–»-Workhorse: SmartHTTPService.PostUploadPack 响应 Workhorse–»-Git on client: 200 OK


该序列对 `git push` 类似，只是使用 `git-receive-pack` 代替 `git-upload-pack`。

### SSH 请求（22 端口）

通过 SSH 进行的 Git 操作可以使用 [Git 文档](https://git-scm.com/docs/pack-protocol#_ssh_transport) 中描述的有状态协议，但这些操作的处理责任分布在多个 GitLab 组件中。

没有任何 GitLab 组件直接处理 SSH —— 所有 SSH 连接都在客户端机器上的 Git 和终止连接的 SSH 服务器之间建立。对于 SSH 服务器来说，所有连接都以 `git` 用户身份进行身份验证；GitLab 用户通过客户端提供的 SSH 密钥来区分。

以下是 `git fetch` 的序列图（假设启用了 [快速 SSH 密钥查找](../administration/operations/fast_ssh_key_lookup.md)）：`AuthorizedKeysCommand` 是由 [GitLab Shell](#gitlab-shell) 提供的可执行文件：

```mermaid
sequenceDiagram
    participant Git on client
    participant SSH server
    participant AuthorizedKeysCommand
    participant GitLab Shell
    participant Rails
    participant Gitaly
    participant Git on server

Note left of Git on client: git fetch
    Git on client->>+SSH server: ssh git fetch-pack 请求
    SSH server->>+AuthorizedKeysCommand: gitlab-shell-authorized-keys-check git AAAA...
    AuthorizedKeysCommand->>+Rails: GET /internal/api/authorized_keys?key=AAAA...
    Note right of Rails: 查找密钥 ID
    Rails-->>-AuthorizedKeysCommand: 200 OK, command="gitlab-shell upload-pack key_id=1"
    AuthorizedKeysCommand-->>-SSH server: command="gitlab-shell upload-pack key_id=1"
    SSH server->>+GitLab Shell: gitlab-shell upload-pack key_id=1
    GitLab Shell->>+Rails: GET /internal/api/allowed?action=upload_pack&key_id=1
    Note right of Rails: 身份验证检查
    Rails-->>-GitLab Shell: 200 OK, { gitaly: ... }
    GitLab Shell->>+Gitaly: SSHService.SSHUploadPack 请求
    Gitaly->>+Git on server: git upload-pack 请求
    Note over Git on client,Git on server: Git 客户端与服务器之间的双向通信
    Git on server-->>-Gitaly: git upload-pack 响应
    Gitaly -->>-GitLab Shell: SSHService.SSHUploadPack 响应
    GitLab Shell-->>-SSH server: gitlab-shell upload-pack 响应
    SSH server-->>-Git on client: ssh git fetch-pack 响应

git push 操作非常相似，只是使用 git receive-pack 代替 git upload-pack。

如果未启用快速 SSH 密钥查找，SSH 服务器会从 ~git/.ssh/authorized_keys 文件中读取信息，以确定给定 SSH 会话要运行的命令。这个文件由 Rails 中的 AuthorizedKeysWorker 保持最新，该工作器会在用户修改 SSH 密钥时运行。

SSH 证书可以替代密钥使用。在这种情况下，AuthorizedKeysCommand 被替换为 AuthorizedPrincipalsCommand。这会从证书中提取用户名，而不使用 Rails 内部 API，后续在 /api/internal/allowed 调用中使用用户名代替 key_id。

GitLab Shell 还有一些不涉及 Gitaly 的操作，例如重置双因素认证码。这些操作的处理方式相同，只是没有往返到 Gitaly —— Rails 在内部 API 调用中执行操作，而 GitLab Shell 直接将响应流式传输回用户。

系统布局

当图片中提及 ~git 时，指的是 Git 用户的家目录，通常是 /home/git。

GitLab 主要安装在 /home/git 用户家目录下，以 git 用户身份运行。家目录内包含 GitLab 服务器软件和仓库（尽管仓库位置是可配置的）。

裸仓库位于 /home/git/repositories。GitLab 是一个 Ruby on Rails 应用程序，因此可以通过研究 Ruby on Rails 应用程序的运作细节来了解其内部工作机制。

为了通过 SSH 提供仓库服务，有一个附加应用程序称为 GitLab Shell，安装在 /home/git/gitlab-shell。

安装文件夹摘要

总结如下：git 用户家目录的结构。

进程

ps aux | grep '^git'

GitLab 有多个组件来运行。它需要一个持久化数据库（PostgreSQL）和 Redis 数据库，并使用 Apache httpd 或 NGINX 来 proxy-pass Puma。所有这些组件都应作为不同的系统用户运行（例如，postgres、redis 和 www-data，而不是 git）。

以 git 用户身份启动 Sidekiq 和 Puma（一个简单的 Ruby HTTP 服务器，默认运行在端口 8080 上）。在 GitLab 用户下通常有 4 个进程：puma master（1 个进程）、puma cluster worker（2 个进程）、sidekiq（1 个进程）。

仓库访问

仓库通过 HTTP 或 SSH 访问。HTTP 克隆/推送/拉取使用 GitLab API，而 SSH 克隆由 GitLab Shell 处理（之前已解释过）。

故障排查

请参阅 README 获取更多信息。

服务初始化脚本

GitLab 的 init 脚本启动和停止 Puma 与 Sidekiq：

/etc/init.d/gitlab
Usage: service gitlab {start|stop|restart|reload|status}

Redis（键值存储/非持久化数据库）：

/etc/init.d/redis
Usage: /etc/init.d/redis {start|stop|status|restart|condrestart|try-restart}

SSH 守护进程：

/etc/init.d/sshd
Usage: /etc/init.d/sshd {start|stop|restart|reload|force-reload|condrestart|try-restart|status}

Web 服务器（以下之一）：

/etc/init.d/httpd
Usage: httpd {start|stop|restart|condrestart|try-restart|force-reload|reload|status|fullstatus|graceful|help|configtest}

$ /etc/init.d/nginx
Usage: nginx {start|stop|restart|reload|force-reload|status|configtest}

持久化数据库：

$ /etc/init.d/postgresql
Usage: /etc/init.d/postgresql {start|stop|restart|reload|force-reload|status} [version ..]

服务日志位置

GitLab（包含 Puma 和 Sidekiq 日志）：

/home/git/gitlab/log/ 通常包含 application.log、production.log、sidekiq.log、puma.stdout.log、git_json.log 和 puma.stderr.log。

GitLab Shell：

/home/git/gitlab-shell/gitlab-shell.log

SSH：

/var/log/auth.log 身份验证日志（在 Ubuntu 上）。
/var/log/secure 身份验证日志（在 RHEL 上）。

NGINX：

/var/log/nginx/ 包含错误和访问日志。

Apache httpd：

Apache 日志说明。
/var/log/apache2/ 包含错误和输出日志（在 Ubuntu 上）。
/var/log/httpd/ 包含错误和输出日志（在 RHEL 上）。

Redis：

/var/log/redis/redis.log 还有日志轮转后的日志。

PostgreSQL：

/var/log/postgresql/*

GitLab 特定配置文件

GitLab 有配置文件位于 /home/git/gitlab/config/*。常用的配置文件包括：

gitlab.yml: GitLab Rails 配置
puma.rb: Puma Web 服务器设置
database.yml: 数据库连接设置

GitLab Shell 有一个配置文件在 /home/git/gitlab-shell/config.yml。

在 GitLab Rails 中添加新设置

属于 gitlab.yml 的设置包括那些与以下相关的：

应用程序如何跨多个服务组合在一起。例如，Gitaly 地址、Redis 地址、Postgres 地址和 Consul 地址。
分布式跟踪配置和一些可观测性配置。例如，直方图桶边界。
任何需要在 Rails 初始化期间配置的内容，可能在 Postgres 连接建立之前。

许多其他设置更适合放在应用本身中，即在 ApplicationSetting 中。相比管理配置文件，在 UI 中管理设置通常是更好的用户体验。从开发成本考虑，修改 gitlab.yml 往往看起来迭代更快，但当考虑到下面的所有部署方法时，这可能是一个糟糕的权衡。

当向 gitlab.yml 添加设置时：

确保也添加到 Omnibus。
如果需要，确保也添加到 Charts。
确保也添加到 GDK。

维护任务

GitLab 提供了 Rake 任务，你可以查看版本信息并对配置进行快速检查，以确保它在应用内正确配置。请参阅维护 Rake 任务。简而言之，执行以下操作：

sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
bundle exec rake gitlab:check RAILS_ENV=production

建议使用 sudo -i -u git 或 sudo su - git 登录 git 用户。虽然 GitLab 提供的 sudo 命令在 Ubuntu 下有效，但它们并不总是适用于 RHEL。

GitLab.com

GitLab.com 架构已详细说明供您参考，但此架构仅在拥有数百万用户时才有用。

AI 架构

提供了一个 SaaS 模型网关来启用原生 AI 功能。