概述

查看各组件状态

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代码统计插件_gitlab 统计代码数量

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