Omnibus GitLab 架构和组件
Omnibus GitLab 是 Chef Omnibus 项目的定制分支,它使用诸如 cookbooks and recipes 之类的 Chef 组件来执行在用户计算机中配置极狐GitLab 的任务。Omnibus GitLab 仓库 托管 Omnibus GitLab 的所有必要组件。其中包括构建包所需的 Omnibus 部分,如配置和项目元数据,以及安装后将在用户计算机中使用的 Chef 相关组件。
软件定义
极狐GitLab 项目定义文件
Omnibus 架构的一个主要组成部分是一个项目定义文件,它列出了项目细节以及与外部软件和库的依赖关系。
这个项目定义文件的主要组成部分是:
- 项目元数据:包括项目名称和描述等属性。
- 项目的许可证详细信息。
- 依赖列表:构建或运行极狐GitLab 所需的外部工具和软件列表,有时还有它们的元数据。
- 用于安装极狐GitLab 的全局配置变量:包括安装目录、系统用户和系统组。
单独的软件定义
Omnibus GitLab 遵循 batteries-included 的分发方式。极狐GitLab 实例正常运行所需的所有软件、库和二进制文件都作为包的一部分以嵌入式格式提供。
所以 Omnibus 架构的另一个主要组成部分是软件定义和配置。典型的软件配置由以下部分组成:
- 所需软件的版本。
- 软件许可。
- 要构建/运行的软件的依赖项。
- 构建软件并将其嵌入包中所需的命令。
有时,软件的源代码可能需要打补丁才能与极狐GitLab 一起使用。这可能是为了修复安全漏洞,添加极狐GitLab 所需的一些功能,或者使其与极狐GitLab 的其它组件一起使用。为此,Omnibus GitLab 包含一个补丁目录,其中存储了不同软件的补丁。
对于更广泛的更改,在镜像上的一个分支中跟踪所需的更改可能会更方便。要遵循的模式是从上游标记或 sha 创建一个分支,并在分支名称中引用该分支点。例如,从 Omnibus 代码库中,gitlab-omnibus-v5.6.10
基于上游项目的 v5.6.10
标签。
全局极狐GitLab 配置模板
Omnibus GitLab 附带一个配置文件,可用于配置极狐GitLab 实例的每个部分,这些部分将安装到用户的计算机上。此配置文件充当将应用于极狐GitLab 实例的所有配置设置的规范来源。它列出了极狐GitLab 实例的常规设置以及不同组件的各种选项。此文件的通用结构由以<component>['<setting>'] = <value>
格式指定的配置组成。配置模板中列出了所有可用选项,但默认情况下,除了极狐GitLab 基本工作所需的选项之外的所有选项都被注释掉了。如有必要,用户可以取消注释并指定相应的值。
极狐GitLab Cookbook
Omnibus GitLab 的 Chef 相关部分的主要部分如下:
默认属性
默认属性,顾名思义,为配置文件中提供的不同设置指定默认值。如果用户没有为设置提供值,这些值将作为 fail-safe 并被使用,从而确保一个有效的极狐GitLab 实例,并且需要最少的用户调整。
Recipes
在使用 Omnibus 包安装极狐GitLab 时,Recipes 完成了大部分繁重的工作,因为它们负责在用户的计算机中设置极狐GitLab 生态系统的每个组件。它们在对应的位置创建必要的文件、目录和链接,设置它们的权限和所有者,配置、启动和停止必要的服务,并在它们对应的文件发生变化时通知这些服务。一个名为 default
的 recipe 充当入口点,它为各种组件和服务调用所有其他必要的配方。
Custom Resources
Custom Resources 可被视为可跨 recipe 使用的全局级宏。Custom Resources 的常见用途是定义用于公共服务的端口,并列出不同 recipe 可能使用的重要目录。它们定义了可由不同 recipe 重用的资源。
组件配置模板
如前所述,Omnibus GitLab 提供了一个配置文件来调整极狐GitLab 实例的所有组件。但是,不同组件的架构设计可能要求它们在特定位置具有单独的配置文件。这些配置文件必须根据用户在通用配置文件中指定的值或从指定的默认值生成。因此,Omnibus GitLab 随附了此类配置文件的模板,其中带有占位符,这些占位符可以由默认值或来自用户的值填充。Recipe 通过填充它们并将它们放置在必要的位置,完成这些模板的工作。
通用库方法
Omnibus GitLab 还提供了一些库方法,主要用于代码重用。这包括检查服务是否启动并运行的方法、检查文件是否存在的方法以及与不同组件交互的辅助方法。它们经常用于 Chef recipes。
在 Omnibus GitLab 中使用的所有库中,有一些特殊的:主要的极狐GitLab 模块和它调用的所有特定于组件的库。特定于组件的库包含解析配置文件以获取为其相应组件定义的设置的方法。主要的极狐GitLab 模块包含协调这个的方法。它负责识别默认值、调用特定于组件的库、合并默认值和用户指定的值、验证它们并基于它们的初始值生成附加配置。Omnibus GitLab 包提供的每个顶级组件都被添加到这个模块中,以便它们可以在配置文件和默认属性中被提及并被正确解析。
runit
极狐GitLab 使用 runit recipe 用于服务管理和监督。runit recipes 负责识别操作系统使用的初始化系统,并执行基本的服务管理任务,例如为极狐GitLab 创建必要的服务文件、服务启用和服务重新加载。runit 提供了 runit_service
定义,可以被其它 recipe 用来与服务交互,参见 /files/gitlab-cookbooks/runit
了解更多信息。
Services
Services 是我们使用 runit 进程 init/supervisor 运行的软件进程。您可以使用 gitlab-ctl
命令检查它们的状态、启动、停止和重新启动它们。Recipes 还可以根据它们的进程组和为极狐GitLab 实例配置的设置/角色禁用或启用这些服务。Services 列表和与之关联的 Services 组可以在 files/gitlab-cookbooks/package/libraries/config/services.rb
中找到。
附加的 gitlab-ctl
命令
默认情况下,Omnibus 提供了一些包装命令,如 gitlab-ctl reconfigure
和 gitlab-ctl restart
来管理极狐GitLab 实例。还有一些额外的包装命令,针对 Omnibus GitLab 仓库中定义的一些特定用例。这些命令与一般的 gitlab-ctl
命令一起使用,来执行某些操作,例如运行数据库迁移或删除休眠账号和类似的不那么常见的任务。
Tests
Omnibus GitLab 仓库使用 ChefSpec 来测试 cookbooks and recipes。通常的策略是检查 recipe 以查看它在两种(或更多)条件下的行为是否正确:当用户未指定任何相应的配置时(即使用默认值时)和使用用户指定的配置时。测试可能包括检查文件是否在正确的位置生成,服务是否启动/停止/通知,正确的二进制文件被调用,以及正确的参数被传递给方法调用。Recipe 和库方法有与之相关的测试。Omnibus GitLab 还使用了一些支持方法或宏来帮助测试过程。在可能的情况下,测试被定义为与并行化兼容,以减少运行整个测试套件所需的时间。
因此,在上述组件中,一些(例如软件定义、项目元数据和测试)在包构建期间、构建环境中使用,而另一些(例如 Chef cookbooks and recipes、GitLab 配置文件、runit 和 gitlab-ctl
命令)用于配置用户安装的实例。
Omnibus GitLab 的工作生命周期
包构建期间会发生什么
正在构建的包的类型取决于运行构建过程的操作系统。 如果构建是在 Debian 环境中完成的,则会创建一个 .deb
包。 包构建过程中发生的事情可以总结为以下步骤:
- 获取依赖软件的来源:
- 解析软件定义,找出对应的版本。
- 从远端或缓存中获取源代码。
- 构建单独的软件组件:
- 设置必要的环境变量和标志。
- 应用补丁(如果适用)。
- 执行组件的构建和安装,包括将其安装到适当的位置(在
/opt/gitlab
内)。
- 生成所有捆绑组件的许可信息 - 包括外部软件、Ruby gems 和 JS 模块。这涉及分析每个依赖项的定义以及组件提供的任何其它许可文件(如极狐GitLab Rails 提供的
licenses.csv
文件) - 检查组件的许可证以确保我们不传递具有不兼容许可证的组件
- 对包运行健康检查以确保二进制文件与可用库相关联。对于捆绑库,二进制文件应该链接到它们而不是全局可用的。
- 使用
/opt/gitlab
的内容构建包。利用gitlab.rb
文件中给出的元数据,包括包名称、版本、维护者、主页以及有关与其它包冲突的信息。
多数据库
之前,极狐GitLab Rails 应用程序是唯一连接到 Omnibus GitLab 数据库的客户端。随着演进,情况已经发生了变化:
- Praefect 和容器镜像仓库使用它们自己的数据库。
- Rails 应用程序现在也在用解耦的数据库。
因为额外的数据库是必要的: