GitLab实战三——Gitlab架构组件详解

1.Gitlab架构

GitLab有两个软件发行版:开源社区版(CE)和企业版(EE)。新版本的GitLab在稳定的分支机构中发布,主分支用于前沿开发。新版本通常与GitLab CE版本大致同时发布,除非有重要的安全更新。Gitlab生态现在主要由以下三大模块组成:

GitLab实战三——Gitlab架构组件详解


官方架构图:

GitLab实战三——Gitlab架构组件详解GitLab实战三——Gitlab架构组件详解

Gitlab通常安装在GNU/Linux上。使用NignxApache 作为Web前端将请求代理到Unicorn Web 服务器,默认情况下,Unicorn和前端通过Unix套接字来通信,也支持使用TCP来转发请求。Web前端访问  /home/git/gitlab/public 绕过Unicorn服务器以提供静态页面,上传(例如头像图片或附件)和预编译资源。 GitLab使用Unicorn Web服务器提供网页和 GitLab API。使用Sidekiq作为作业队列,而后者又使用redis作为作业信息,元数据和传入作业的非持久数据库后端。

Gitlab 应用程序使用 MySQLPostgreSQL 作为持久数据库,用来保存用户,权限,issue,其他元数据等 git repository 默认存储在 /home/git/repositories 中,保留默认分支和 hooks 信息。

当通过 HTTP/HTTPS 提供 repository 时,GitLab 使用 GitLab API 来解析授权和访问以及提供 git 对象。

gitlab-shell 通过 SSH 提供 repository。它管理 /home/git/.ssh/authorized_keys 内的 SSH 密钥,不应手动编辑。gitlab-shell 通过 Gitaly 访问 bare repository 以提供 git 对象并与 redis 进行通信以向 Sidekiq 提交作业以供 GitLab 处理。gitlab-shell 查询 GitLab API 以确定授权和访问。

Gitaly 从 gitlab-shell 和 GitLab web 应用中获取操作命令,执行 git 操作,并为 GitLab web 应用程序提供 API 以从 git 获取属性(例如 title,branches,tags,其他元数据)和 blob(例如 diffs,commits ,files)。

Gitlab的生产架构可以参考这里


Gitlab组件:

  • repository:代码库,可以是硬盘或 分布式文件系统

  • Nginx:Web 入口

  • gitlab-workhorse:轻量级反向代理服务器,可以处理一些大的HTTP请求(磁盘上的 CSS、JS 文件、文件上传下载等),处理 Git Push/Pull 请求,处理到Rails 的连接会反向代理给后端的unicorn(修改由 Rails 发送的响应或发送给 Rails 的请求,管理 Rails 的长期 WebSocket 连接等)。

  • gitlab-shell:用于 SSH 交互,而不是 HTTP。gitlab-shell 通过 Redis 与 Sidekiq 进行通信,并直接或通过 TCP 间接访问 Unicorn。用于处理Git命令和修改authorized keys列表

  • Unicorn:Gitlab 自身的 Web 服务器(Ruby Web Server),包含了 Gitlab 主进程,负责处理快速/一般任务,与 Redis 一起工作,配置参考:CPU核心数 + 1 = unicorn workers数量。工作内容包括:

    • 通过检查存储在 Redis 中的用户会话来检查权限

    • 为 Sidekiq 制作任务

    • 从仓库(warehouse)取东西或在那里移动东西

  • Redis:缓存每个客户端的sessions和后台队列,负责分发任务。Redis需求的存储空间很小,大约每个用户25KB

  • Gitaly:后台服务,专门负责访问磁盘以高效处理 gitlab-shell 和 gitlab-workhorse 的git 操作,并缓存耗时操作。所有的 git 操作都通过 Gitaly 处理,并向 GitLab web 应用程序提供一个 API,以从 git(例如 title, branches, tags, other meta data)获取属性,并获取 blob(例如 diffs,commits,files)

  • Sidekiq后台核心服务,可以从redis队列中提取作业并对其进行处理。后台作业允许GitLab通过将工作移至后台来提供更快的请求/响应周期。Sidekiq任务需要来自Redis

  • 数据库(PostgreSQL/MySQL):包含以下信息:

    • repository 中的数据(元数据,issue,合并请求 merge request 等)

    • 可以登录 Web 的用户(权限)

  • mail_room:处理邮件请求。回复 GitLab 发出的邮件时,GitLab 会调用此服务处理Sidekiq、Unicorn 和 GitLab-shell 的任务

  • logrotate:日志文件管理,切割


Gitlab-shell组件:

GitLab Shell 的作用:处理 Git 命令修改 authorized keys 列表。GitLab Shell 不是 Unix shell,也不是 Bash 或 Zsh 的替代品。早期的 gitlab-shell 的实现方式为 gitolite。

当通过 SSH 访问 GitLab Server 时,GitLab Shell 会:

  • 限制执行预定义好的Git命令(git push, git pull)

  • 调用 GitLab Rails API,检查用户权限

  • 执行 pre-receive 钩子(在 GitLab 企业版中叫做 Git 钩子)

  • 执行你请求的动作

  • 处理 GitLab 的 post-receive 动作

  • 处理自定义的 post-receive 动作

git pull over ssh  - > gitlab-shell  - > API调用gitlab-rails(授权) - >接受或拒绝 - >建立Gitaly会话

git push over ssh  - > gitlab-shell(git命令尚未执行) - >建立Gitaly会话 - >(在Gitaly中)gitlab-shell pre-receive hook  - > API调用gitlab-rails(授权) - >接受或拒绝push


当通过 http(s) 访问 GitLab Server 时,工作流程取决于你是从 Git 仓库拉取(pull)代码,还是向 git 仓库推送(push)代码。

  • 如果你是从 Git 仓库 pull 代码,GitLab Rails 应用会全权负责处理用户鉴权和执行 Git 命令的工作

  • 如果你是向 Git 仓库 push 代码,GitLab Rails 应用既不会进行用户鉴权也不会执行 Git 命令,它会把以下工作交由 GitLab Shell 进行处理:

  • 调用GitLab Rails API 检查权限

  • 执行pre-receive 钩子

  • 执行你请求的动作

  • 处理 GitLab 的 post-receive 动作

  • 处理自定义的 post-receive 动作

也许你会奇怪在通过 http(s) push 代码的情况下,GitLab Rails应用为什么不在 GitLab Shell之前进行鉴权。这是因为 GitLab Rails 应用没有解析 git push 命令的逻辑。好的方法是将这些解析代码放在一个地方,这个地方就是 GitLab Shell,这样我们就可以在通过 SSH 进行访问时重用这段代码。实际上,GitLab Shell 在执行 git push 命令时根本不会进行权限检查,它是依赖于 pre-receive 钩子进行权限检查的。而当你执行 git pull 命令时,权限检查是在命令执行之前的。对 git pull 命令的权限检查要简单得多,因为你只需要检查一个用户是否可以访问这个仓库就可以了(不需要检查分支权限)。


Gitlab-workhorse组件:

  • Workhorse 可以处理一些请求,而不涉及 Rails:例如,Javascript 文件和 CSS 文件直接从磁盘载入

  • Workhorse 可以修改 Rails 发送的响应:例如,如果你在 Rails 中使用 send_file,那么 gitlab-workhorse 将打开磁盘上的文件,并将其内容作为响应体发送给客户端

  • Workhorse 可以在从 Rails 请求权限后接管请求。 例如:处理 git clone 动作

  • Workhorse 可以在将请求传递给 Rails 之前对其进行修改。 例如:处理 Git LFS 上传 Workhorse 首先向 Rails 请求权限,然后将请求主体存储在临时文件中,然后它将包含临时文件路径的修改后的请求发送到 Rails

  • Workhorse 可以管理 Rails 的长期 WebSocket 连接。 例如:处理环境的终端 websocket

  • Workhorse 不连接 Redis 或 Postgresql,只连接到 Rails

  • 我们假设所有到达 Workhorse 的请求首先通过一个上游代理,如 NGINX 或 Apache

  • Workhorse 不接受 HTTPS 连接

  • Workhorse 不清除空闲客户端连接

  • 我们假设所有对 Rails 的请求都通过 Workhorse


Gitaly组件:

Gitaly是一个Git RPC服务,使用gRPC协议与客户端通信,用于处理GitLab发出的所有git调用。详细介绍

GitLab实战三——Gitlab架构组件详解GitLab实战三——Gitlab架构组件详解

Gitlab老版架构图(< 9.0):

GitLab实战三——Gitlab架构组件详解GitLab实战三——Gitlab架构组件详解


2.Gitlab结构及配置

~/git 表示 git 用户的主目录,通常是 /home/git

GitLab 在安装时,会创建 git 用户,并安装在 /home/git 目录中。在主目录中是 gitlabhq 服务器软件以及 repository 所在的位置,repository 的位置可以单独配置。

repository 位于 /home/git/repositories 中。GitLab 是一款 Ruby on Rails 应用程序,因此可以通过研究 Ruby on Rails 应用程序的工作方式来了解内部工作的细节。

要通过 SSH 提供 repository,可以使用 gitlab-shell 这个附加应用程序,该应用程序安装在 /home/git/gitlab-shell 中。


Gitlab目录结构:

GitLab实战三——Gitlab架构组件详解

/home/git/.ssh - 包含 openssh 设置。指定由 gitlab-shell 管理的 authorized_keys 文件。 /home/git/gitlab - GitLab 核心软件。 /home/git/gitlab-shell - GitLab 核心的附加组件。包括 SSH 复制和其他功能。 /home/git/data/repositories - 由命名空间组织的所有项目的裸仓库(bare repository)。这是为所有项目维护推/拉的 git repository 的地方。这是项目的关键数据,最好备份。注意:repository 的默认位置可以在 GitLab 的 config/gitlab.yml 和 gitlab-shell 的 config.yml 中配置。


Gitlab配置文件:

Gitlab 的配置文件在 /home/git/gitlab/config/*目录下, 常用的有:

  • gitlab.yml - GitLab 配置.

  • unicorn.rb - Unicorn web server 配置.

  • database.yml - 数据库连接配置.

  • gitaly.yml - Gitaly 配置.

gitlab-shell 的配置文件在 /home/git/gitlab-shell/config.yml.

Gitlab备份与恢复:

# 执行备份命令
bundle exec rake gitlab:backup:create RAILS_ENV=production  
# 备份成功,你会找到一个类似 /home/git/data/backups/1531046569_2018_07_14_10.6.4_gitlab_backup.tar 的文件

# 执行恢复命令
bundle exec rake gitlab:backup:restore RAILS_ENV=production

详情请看官网。


Gitlab进程:

作为系统用户,它需要持久数据库(MySQL/PostreSQL)和 redis 数据库。它还使用 Nginx 来代理 Unicorn。作为 git 用户,它启动 Sidekiq 和 Unicorn(默认情况下运行在端口 8080 上的基于 ruby 的 HTTP 服务器)。在 GitLab 用户下,通常有 4 个进程:gitlab-workhorse (1进程) , unicorn_rails master(1进程),unicorn_rails worker(2进程),sidekiq(1进程),gitaly(1进程),具体启动进程数以各组件配置文件为准。


Repository访问:

可以通过 HTTP 或 SSH 访问代码库。HTTP 中的 cloning/push/pull 使用 GitLab API,SSH 克隆由 gitlab-shell 处理。


Gitlab环境检查:

GitLab 还提供了 rake 任务,可以用来查看版本信息或检查配置是否正确。详情可以参考 maintenance rake tasks。简而言之:

sudo -i -u git
cd gitlab
bundle exec rake gitlab:env:info RAILS_ENV=production
bundle exec rake gitlab:check RAILS_ENV=production

注意:建议使用 sudo -i -u gitsudo su - git 登录 git 用户。虽然 gitlabhq 提供的 sudo 命令在 Ubuntu 中工作,但它们并不总是在 RHEL 中工作。


Gitlab服务日志:

gitlabhq (includes Unicorn and Sidekiq logs)

  • /home/git/gitlab/log/ contains application.log, production.log, sidekiq.log, unicorn.stdout.log, githost.log and unicorn.stderr.log normally.

gitlab-shell

  • /home/git/gitlab-shell/gitlab-shell.log

ssh

  • /var/log/auth.log auth log (on Ubuntu).

  • /var/log/secure auth log (on RHEL).

nginx

  • /var/log/nginx/ contains error and access logs.

Apache httpd

  • Explanation of Apache logs.

  • /var/log/apache2/ contains error and output logs (on Ubuntu).

  • /var/log/httpd/ contains error and output logs (on RHEL).

redis

  • /var/log/redis/redis.log there are also log-rotated logs there.

PostgreSQL

  • /var/log/postgresql/*

MySQL

  • /var/log/mysql/*

  • /var/log/mysql.*


参考:

anzhihe安志合个人博客,版权所有丨 如未注明,均为原创 丨转载请注明转自:https://chegva.com/3229.html | ☆★★每天进步一点点,加油!★★☆

您可能还感兴趣的文章!

发表评论

电子邮件地址不会被公开。 必填项已用*标注