概述
查看各组件状态
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 |