多数据库支持指南

1. 你在这里:
2. 极狐 Handbook
3. 极狐研发团队
4. 极狐GitLab 贡献指南 -- 后端部分
5. 多数据库支持指南

• 前言
• 需要实现的点
  • GitLab
  • GDK
  • Omnibus GitLab
  • Helm chart
  • Docker GitLab 的支持
• 解决方案
  • GitLab 侧解决方案
  • GDK 侧解决方案
  • Omnibus GitLab 侧解决方案
  • Helm chart 侧解决方案

前言

在极狐GitLab 开发的过程中，因为要持续和上游的代码保持同步，使得我们在数据库增加表或者字段时，需要到上游提交 MR，上游 review 完成后需要等代码同步到 main-jh 之后才可以使用，这就使得整个周期变得比较长。而且由于极狐GitLab 和上游的客户群体不同，当我们两边要同时实现一个功能点的时候，客户想要支持的需求也是不同的，所以很可能在实现这个需求的时候，两边设计的表结构也是完全不同的，这个时候我们可以为这个新功能来使用一个单独的数据库。那么这个单独的数据库需要考虑到哪些方面呢，我们接着往下看。

需要实现的点

GitLab

1. 添加一个新的数据库，用来给极狐GitLab 专属的新功能使用。
2. 需要有独立的数据库配置文件、独立的 migrate、schema_migrations 目录、独立的 structure.sql。
3. 需要将生成极狐GitLab 专属数据库配置文件的任务，以及创建数据库、执行数据库迁移的操作添加到 GDK 中。
4. 需要可以生成 rails db:migrate:main-jh 这样的 rake 命令来单独执行极狐GitLab 数据库的迁移和 rollback。
5. 需要实现极狐GitLab 数据库的 CI/CD 支持。
6. 需要实现不同 model 连接不同数据库。
7. 需要实现多数据库的表关联。

GDK

1. gdk install JH 数据库自动创建并运行迁移
2. gdk reconfigure 需要可以更新 jh/config/database.yml

Omnibus GitLab

1. 需要在 Omnibus GitLab 中添加对极狐GitLab 数据库的支持，安装 Omnibus GitLab 后可以自动创建极狐GitLab 数据库并完成数据库的初始化。

Helm chart

1. 需要在使用 Helm chart 安装极狐GitLab 的时候，完成极狐GitLab 专属数据库的初始化。

Docker GitLab 的支持

1. 需要在使用 Docker 安装极狐GitLab 的时候，完成极狐GitLab 专属数据库的初始化。

解决方案

GitLab 侧解决方案

1. 在 GDK 中添加程序来生成 jh/config/database.yml 文件，并可以创建数据库并执行迁移。
2. 通过 database.yml 中配置 migrations_paths: ['jh/db/migrate'] 来指定 migrate 目录为 jh/db/migrate ，通过配置 schema_migrations_path: 'jh/db/schema_migrations' 来指定 schema_migrations 的目录为 jh/db/schema_migrations。用这个方式来实现数据库迁移的隔离。
3. 数据库的专属 rake 任务是 lib/tasks/gilab/db.rake 文件中生成的，其中 databases = ActiveRecord::Tasks::DatabaseTasks.setup_initial_database_yaml 是找到当前配置的所有数据库，但是 databases 中并不会包含 jh/config/database.yml 中的配置，这个配置默认读取的是 config/database.yml ，需要我们通过魔改的方式把 jh/config/database.yml 中的配置加进去。
4. CI/CD 的支持需要我们修改 spec 的配置，支持极狐GitLab 专属的数据库，在执行极狐GitLab 专属数据库相关的测试时，在 before do 中改变数据库的连接，使其连接极狐GitLab 专属数据库。
5. 要实现不同 model 连接不同数据库，有两种方式： 一是我们为极狐GitLab 专属数据库创建一个基类，在这个类中使用 Rails 的 connects_to 方法指定连接极狐GitLab 专属数据库。然后需要连接极狐GitLab 专属数据库的 model 直接继承这个类即可； 二是为 model 单独添加 connects_to 方法。个人推荐第一个方式。
6. 跨数据库的表关联可以参考 Ruby on Rails Guides 中的介绍来做，只需要在设置关联时指定 disable_joins: true 即可，相关链接： https://guides.rubyonrails.org/active_record_multiple_databases.html#handling-associations-with-joins-across-databases

GDK 侧解决方案

GDK 侧对于 1 和 2 有两种不同的方案，区别在于 GDK 项目改动的大小，但是无论大小都需要改动 GDK。

• 在 GDK 项目中添加写入极狐GitLab 数据库配置的脚本，将数据库配置写入 jh/config/database.yml，在 gdk install 和 gdk reconfigure 命令中执行。
• 在极狐GitLab 项目中添加 rake 任务，rake 任务的内容是读取 config/database.yml 的配置并根据此配置来组合极狐GitLab 数据库的配置并写入 jh/config/database.yml 文件中。在 GDK 项目中执行 gdk install 和 gdk reconfigure 相关的代码中加入执行这个 rake 任务的代码。

Omnibus GitLab 侧解决方案

1. 在 Omnibus GitLab 项目中添加根据 license 来决定是否添加极狐GitLab 数据库配置的代码，如果有对应的 license，需要在安装过程中自动创建极狐GitLab 的配置文件，在安装完成后可以初始化数据库。

Helm chart 侧解决方案

1. 通过查看 安装文档中有这样一段话：

• The stateful components, like PostgreSQL or Gitaly (a Git repository storage dataplane), must run outside the cluster on PaaS or compute instances. This configuration is required to scale and reliably service the variety of workloads found in production GitLab environments.

Helm chart 主要用于在 k8s 集群中安装极狐GitLab，PostgreSQL 服务和 Gitaly 服务都是在 cluster 之外的，如果我们想启用 GEO，需要在外部的 PostgreSQL 中配置好一个空的数据库，GitLab 推荐 self-managed 使用 Omnibus-gitlab 来安装 PostgreSQL 的服务，所以我们无需对 Helm chart 的代码做修改。