gitlab各组件功能list

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

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

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

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

80、443、8060

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

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

Redis guidelines | GitLab

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

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

127.0.0.1:9093

9094