概述

查看各组件状态

gitlab-ctl status

gitlab组件架构文档（有详细架构图）：GitLab architecture overview | GitLab

精简版-gitlab各组件list

  • gitaly - 提供对Git Repository的高级RPC访问。只负责Repository数据，其他数据不通过gitlay。
  • gitlab-workhorse - 作为http请求代理，所有http请求都会过gitlab-workhorse。再由gitlab-workhorse通过Ruby程序HTTP服务器（Unicorn）转发给后端Ruby应用程序（puma、sidekiq）。
  • gitlab rails application - gitlab的后端Ruby应用程序的总称，实际的Ruby应用程序为puma、sidekiq。
  • puma - Ruby应用程序。puma在Gitlab中提供面向用户的功能。 
  • sidekiq - Ruby应用程序。sidekiq是一个后台作业处理器，从Redis队列中提取作业并进行处理。
  • nginx - 作为http请求入口，将http请求路由到合适的gitlab子系统。
  • postgresql - 为应用程序元数据和用户信息提供存储。
  • redis - 主要用于以下目的：缓存、Sidekiq的作业处理队列、管理共享应用程序状态、存储 CI 跟踪块、作为 ActionCable 的 Pub/Sub 队列后端、速率限制状态存储、Session。
  • logrotate - 用于日志切割。
  • 监控组件 - prometheus、alertmanager、grafana、指标采集器（node-exporter、postgres-exporter、redis-exporter）
  • gitlab-kas - kubernetes agent server，用于管理kubernetes中的gitlab agent。用于gitlab到k8s的持续集成、持续部署。

详细版-gitlab各组件list

相关组件

端口

备注

gitaly

127.0.0.1:9236

gitaly提供对Git repositories的高级RPC访问。Gitlab通过gitaly读取和写入数据，协调repositories的存储和检索。gitaly只负责repositories存储，其他的数据不通过gitaly。

gitaly可以有单实例(单机)和集群两种模式。单机时repositories存储在单个节点上；cluster模式下repositories可以被存储在多个节点上，以实现容错。

gitaly是C/S架构。服务端是：gitaly本身；客户端是向gitaly发出请求的进程：GitLab Rails application（puma、sidekiq）、GitLab Shell、GitLab Workhorse、GitLab Elasticsearch Indexer

gitlab-workhorse

127.0.0.1:9229

GitLab Workhorse是 GitLab 设计的一个程序，旨在帮助减轻来自 Puma 的压力。您可以阅读更多关于发展的历史原因。它旨在充当智能反向代理，以帮助整个 GitLab 加速。

GitLab Workhorse作为http请求的代理，使用GO语言编写。从nginx过来的http请求先到GitLab Workhorse，再到Unicorn。Unicorn是为Ruby应用程序提供的HTTP服务器，在nginx中一般通过一个Unix Socket将请求转发至Unicorn worker池。GitLab Workhorse最初为了解决一些大型项目 git clone 时通过 ssh 的超时问题，因为Unicorn依赖相对较短的请求超时。后来为了简化nginx配置，将http的请求先经过GitLab Workhorse再转发到Unicorn，逐渐越来越多的http请求转移到了GitLab Workhorse上。

关于GitLab Workhorse的发展历史：A Brief History of GitLab Workhorse|GitLab..

puma（GitLab Rails application）

127.0.0.1:8080

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

sidekiq（GitLab Rails application）

Sidekiq 是一个 Ruby 后台作业处理器，它从 Redis 队列中提取作业并进行处理。后台作业允许 GitLab 通过将工作移至后台来提供更快的请求/响应周期。

Sidekiq 需要连接到 Redis、PostgreSQL 和 Gitaly 实例。

gitlab-kas

127.0.0.1:8150

127.0.0.1:8151

127.0.0.1:8153

127.0.0.1:8154

127.0.0.1:8155

KAS（Kubernetes agent server）是gitlab agent server，用于管理Kubernetes中的Gitlab agent（agentk）。

KAS ↔ gitlab agent，解决k8s和gitlab的链接。可以将部署从gitlab同步到k8s集群。

1.可以将k8s清单存储在gitlab中。更新清单文件，代理就会更新k8s中的部署

2.可以通过gitlab CI/CD查询和更新k8s集群

kubernetes结合gitlab实现cicd：

Connecting a Kubernetes cluster with GitLab | GitLab

kas架构：

doc/architecture.md · master · GitLab.org / cluster-integration / GitLab Agent for Kubernetes · GitLab

gitlab 统计代码数量 gitlab代码统计插件_ide

nginx

80、443、8060

作为http请求的入口，将http的请求路由到合适的gitlab子系统。

8060端口暴露nginx-status、nginx metrics、gitlab rails metrics。默认情况下只允许从127.0.0.1访问。

postgresql

为应用程序元数据和用户信息提供存储。

redis

Redis guidelines | GitLab

Redis用于以下目的：缓存（主要是通过Rails.cache）、作为Sidekiq的作业处理队列、管理共享应用程序状态、存储 CI 跟踪块、作为 ActionCable 的 Pub/Sub 队列后端、速率限制状态存储、Session。

如果启用Geo，每个 Geo 节点都会获得自己的独立 Redis 数据库。

logrotate

日志切割。

prometheus

9090

监控。

alertmanager

127.0.0.1:9093

9094

负责发送告警和抑制告警。

grafana

127.0.0.1:3000

监控面板。

node-exporter

127.0.0.1:9100

将node的指标提供给prometheus

postgres-exporter

127.0.0.1:9187

将postgresql的指标提供给prometheus

redis-exporter

127.0.0.1:9121

将redis的指标提供给prometheus