gitlab各组件功能list

概述

查看各组件状态

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
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