gitlab集群高可用架构拆分部署

一边学习一边哭2024-05-09 15:55

目录

前言

负载均衡器准备

外部负载均衡器

内部负载均衡器

(可选)Consul服务

Postgresql拆分

1.准备postgresql集群

手动安装postgresql插件

2./etc/gitlab/gitlab.rb配置

3.生效配置文件

Redis拆分

1./etc/gitlab/gitlab.rb配置

2.生效配置文件

Gitaly拆分

[1.Praefect Postgresql数据库配置](#1.Praefect Postgresql数据库配置)

2.配置Praefect

2.1.部署准备&注意事项

2.2./etc/gitlab/gitlab.rb配置

2.3.生效配置文件

2.4.验证Praefect与gitaly的连接配置状态

3.配置gitaly

3.1.部署准备&注意事项

[3.2. /etc/gitlab/gitlab.rb配置](#3.2. /etc/gitlab/gitlab.rb配置)

3.3.创建git-data目录

3.4.生效配置文件

NFS配置

Sidekiq拆分

1.部署准备&注意事项

2./etc/gitlab/gitlab.rb配置

3.生效配置文件

[Gitlab Rails拆分](#Gitlab Rails拆分)

1.部署准备&注意事项

2./etc/gitlab/gitlab.rb配置

3.生效配置文件

4.启用增量日志

[4.1. 要启用增量日志记录](#4.1. 要启用增量日志记录)

4.2.要禁用增量日志记录

5.配置确认

[5.1.确认节点可以连接到 Gitaly](#5.1.确认节点可以连接到 Gitaly)

[5.2.(可选)从 Gitaly 服务器确认 Gitaly 可以对内部 API 执行回调](#5.2.(可选)从 Gitaly 服务器确认 Gitaly 可以对内部 API 执行回调)

总结

前言

整体架构参考：Reference architecture: up to 50,000 users | GitLab

为了简化部署，Postgresql、Redis等，会使用云厂商提供的服务

（引用gitlab官网架构图）

负载均衡器准备

  1. 可以考虑使用云厂商的负载均衡器，提供7层和4层的负载均衡。

  2. 如果只是内网使用，或者测试场景。外部负载均衡器和内部负载均衡器可以考虑使用同一个负载均衡器，以节省资源。

配置外部负载均衡器：Reference architecture: up to 50,000 users | GitLab

配置内部负载均衡器：Reference architecture: up to 50,000 users | GitLab

外部负载均衡器

LB端口 后端端口 协议 说明
80 80 HTTP
443 80/443 HTTPS/TCP 1.如果在LB卸载SSL证书，则可以通过HTTPS协议，转发至后端80端口 2.如果需要在后端gitlab的nginx卸载证书，则可以通过TCP协议，转发至后端443端口

内部负载均衡器

(可选)Consul服务

官方文档中对于Consul服务在gitlab中的作用定位是：数据库服务发现。

由于本示例使用的Postrgresql和Redis都是使用云厂商提供的服务，所以跳过Consul的部署。

Consul部署参考：Reference architecture: up to 50,000 users | GitLab

Consul:https://archives.docs.gitlab.com/16.7/ee/administration/reference_architectures/index.html#available-reference-architectures

Postgresql拆分

参考文档：

1.gitlab版本和支持的postgresql版本对应关系：Installation system requirements | GitLab

2.配置外部postgresql：Configure GitLab using an external PostgreSQL service | GitLab

以下步骤默认已有高可用的pgstgresql数据库

1.准备postgresql集群

  1. 可以选择云厂商提供的pg集群，根据数据库需求文档，创建合适版本的postgresql高可用集群。
  2. 创建gitlab用户
  3. 创建数据库gitlabhq_production，并配置owner为gitlab用户
  4. 开启插件：pg_trgm、btree_gist、plpgsql

手动安装postgresql插件

bash 复制代码 
#安装插件
gitlabhq_production=# CREATE EXTENSION IF NOT EXISTS pg_trgm
gitlabhq_production=# CREATE EXTENSION IF NOT EXISTS btree_gist
gitlabhq_production=# CREATE EXTENSION IF NOT EXISTS plpgsql

#查看插件
gitlabhq_production=# \dx

2./etc/gitlab/gitlab.rb配置

bash 复制代码 
#关闭内置postgresql
postgresql['enable'] = false

#连接postgresql配置信息
gitlab_rails['db_adapter'] = 'postgresql'
gitlab_rails['db_encoding'] = 'unicode'
gitlab_rails['db_database'] = 'gitlabhq_production'
gitlab_rails['db_username'] = 'gitlab'
gitlab_rails['db_password'] = 'your_password'
gitlab_rails['db_host'] = 'your_pg_host'
gitlab_rails['db_port'] = 5432

3.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启postgresql，生效TCP端口
gitlab-ctl restart

Redis拆分

参考文档：

1.redis版本选择：Installation system requirements | GitLab

2.配置外部redis：Redis replication and failover providing your own instance | GitLab

3.redis驱逐策略：Redis replication and failover providing your own instance | GitLab

  1. 可以选择云厂商提供的redis，16.x版本的gitlab建议使用6.2及以上的redis版本
  2. 特别不建议使用Redis集群，单可以使用高可用的Redis Standalone
  3. 配置适合的驱逐模式

1./etc/gitlab/gitlab.rb配置

bash 复制代码 
#关闭内置redis服务
redis['enable'] = false

#配置连接外部redis服务胚子和
gitlab_rails['redis_host'] = "your_redis_host"
gitlab_rails['redis_port'] = redis_port
gitlab_rails['redis_password'] = "your_redis_password"

2.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启
gitlab-ctl restart / gitlab-ctl restart redis

Gitaly拆分

1.Praefect Postgresql数据库配置

1.Praefect数据库配置：Reference architecture: up to 50,000 users | GitLab

Praefect 是 Gitaly Cluster 的路由和事务管理器，需要自己的数据库服务器来存储有关 Gitaly Cluster 状态的数据。

如果您想要高可用性设置，Praefect 需要第三方 PostgreSQL 数据库。

  1. 已拥有postgresql（复用gitlabhq_production库使用的postgresql）
  2. 创建praefect用户
  3. 创建数据库praefect_production，并配置owner为praefect用户
bash 复制代码 
#登陆数据库，创建praefect用户
CREATE ROLE praefect WITH LOGIN CREATEDB PASSWORD '<praefect_postgresql_password>';


#切换praefect用户登陆数据库
psql -U praefect -d template1 -h POSTGRESQL_SERVER_ADDRESS

#创建数据库praefect_production
CREATE DATABASE praefect_production WITH ENCODING=UTF8;

#查看数据库创建结果
\l

2.配置Praefect

1.配置Praefect：

Reference architecture: up to 50,000 users | GitLab

Configure Gitaly Cluster | GitLab

2.1.部署准备&注意事项

  1. 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件，并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。
  2. Praefect必须部署在奇数个3个节点或更高节点中。这是为了确保节点可以将投票作为法定人数的一部分。
  3. Praefect需要连接Postgresql。
  4. Praefect 需要运行一些数据库迁移，就像主 GitLab 应用程序一样。为此，您应该仅选择一个 Praefect 节点来运行迁移，也称为部署节点。必须先配置此节点，然后再配置其他节点。

2.2./etc/gitlab/gitlab.rb配置

Praefect 需要运行一些数据库迁移，就像主 GitLab 应用程序一样。为此，您应该仅选择一个 Praefect 节点来运行迁移，也称为部署节点。必须先配置此节点，然后再配置其他节点，如下所示：

  • 在/etc/gitlab/gitlab.rb文件中，将praefect['auto_migrate']设置值从更改false为true
  • 要确保数据库迁移仅在重新配置期间运行，而不是在升级时自动运行，请运行：
bash 复制代码 
sudo touch /etc/gitlab/skip-auto-reconfigure
  • name: 'default'的值，需要和git_data_dirs配置中的name一致。
  • storage: 'gitaly-1'...，需要和每个gitaly节点的gitaly['configuration'][:storage]中的name一致。
bash 复制代码 
# Avoid running unnecessary services on the Praefect server
gitaly['enable'] = false
postgresql['enable'] = false
redis['enable'] = false
nginx['enable'] = false
puma['enable'] = false
sidekiq['enable'] = false
gitlab_workhorse['enable'] = false
prometheus['enable'] = false
alertmanager['enable'] = false
gitlab_exporter['enable'] = false
gitlab_kas['enable'] = false

# Praefect Configuration
praefect['enable'] = true

# Prevent database migrations from running on upgrade automatically
praefect['auto_migrate'] = false
gitlab_rails['auto_migrate'] = false

# Configure the Consul agent
#consul['enable'] = true
## Enable service discovery for Prometheus
#consul['monitoring_service_discovery'] = true

# START user configuration
# Please set the real values as explained in Required Information section
#

praefect['configuration'] = {
   # ...
   listen_addr: '0.0.0.0:2305',
   auth: {
     # ...
     #
     # Praefect External Token
     # This is needed by clients outside the cluster (like GitLab Shell) to communicate with the Praefect cluster
     token: '<praefect_external_token>',
   },
   # Praefect Database Settings
   database: {
     host: 'POSTGRESQL_HOST',
     user: 'praefect',
     port: 5432,
     password: 'PRAEFECT_SQL_PASSWORD',
     dbname: 'praefect_production',
   },
   # Praefect Virtual Storage config
   # Name of storage hash must match storage name in git_data_dirs on GitLab
   # server ('praefect') and in gitaly['configuration'][:storage] on Gitaly nodes ('gitaly-1')
   # name: 'default'的值，需要和git_data_dirs配置中的name一致
   # storage: 'gitaly-1'...，需要和每个gitaly节点的gitaly['configuration'][:storage]中的name一致
   virtual_storage: [
      {
         # ...
         name: 'default',
         node: [
            {
               storage: 'gitaly-1',
               address: 'tcp://10.6.0.91:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-2',
               address: 'tcp://10.6.0.92:8075',
               token: '<praefect_internal_token>'
            },
            {
               storage: 'gitaly-3',
               address: 'tcp://10.6.0.93:8075',
               token: '<praefect_internal_token>'
            },
         ],
      },
   ],
   # Set the network address Praefect will listen on for monitoring
   prometheus_listen_addr: '0.0.0.0:9652',
}

# Set the network address the node exporter will listen on for monitoring
#node_exporter['listen_address'] = '0.0.0.0:9100'

## The IPs of the Consul server nodes
## You can also use FQDNs and intermix them with IPs
#consul['configuration'] = {
#   retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13),
#}
#
# END user configuration

2.3.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启
gitlab-ctl restart / gitlab-ctl restart praefect

2.4.验证Praefect与gitaly的连接配置状态

Praefect和Gitlay都配置完成后，可以连接到Praefect节点上执行命令进行验证

bash 复制代码 
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes

3.配置gitaly

1.配置gitaly：

Reference architecture: up to 50,000 users | GitLab

Configure Gitaly Cluster | GitLab

3.1.部署准备&注意事项

  1. 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件，并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。

3.2. /etc/gitlab/gitlab.rb配置

bash 复制代码 
#开启gitaly服务
gitaly['enable'] = true

#
gitaly['configuration'] = {
  #配置gitaly服务监听地址
  listen_addr: '0.0.0.0:8075',
  #与Praefect服务中的PRAEFECT_INTERNAL_TOKEN需要一致
  auth: {
    token: 'PRAEFECT_INTERNAL_TOKEN',
  },
  #配置存储地址，每个gitaly服务应该有不一样的name('gitaly-1')
  storage: [
    {
      name: 'gitaly-1',
      path: '/var/opt/gitlab/git-data/repositories',
    },
  ],
}

storage配置方法二：

可以在同一配置中包括所有节点的数据目录，因为Praefect只会根据自身配置文件中提供的地址路由（如：storage: 'gitaly-1'）请求。

bash 复制代码 
gitaly['configuration'] = {
   # ...
   storage: [
     {
       name: 'gitaly-1',
       path: '/var/opt/gitlab/git-data/repositories',
     },
     {
       name: 'gitaly-2',
       path: '/var/opt/gitlab/git-data/repositories',
     },
     {
       name: 'gitaly-3',
       path: '/var/opt/gitlab/git-data/repositories',
     },
   ],
}

3.3.创建git-data目录

gitaly-data目录需要git用户拥有权限，否则会报错。

bash 复制代码 
mkdir -p /var/opt/gitlab/git-data/repositories

chown git: /var/opt/gitlab/git-data/repositories

3.4.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启
gitlab-ctl restart / gitlab-ctl restart gitaly

NFS配置

后续拆分Sidekiq & GitLab Rails集群需要用到NFS共享一些目录

Using NFS with GitLab | GitLab
gitlab官方不建议使用云服务商提供的NFS服务，会对影响有不可预估的影响。

部署NFS server可参考：https://docs.gitlab.com/ee/administration/nfs.html#nfs-server

（本问为了方便，没有部署NFS server，直接是有云服务商提供的NFS服务）

这边不得不吐槽一下官网文档，踩坑踩的很痛苦！

  1. 文档写有4个路径需要NFS共享，给出来的表格只列出来3个。而一番google之后，实际上最多有5个路径需要NFS共享。
  2. git-data的路径为什么要共享？也没说清楚。gitaly cluster配置中也没有提到任何需要配置NFS的地方。并且通过Praefect可以配置复制因子来看，gitaly node上存的仓库数据并不一定完全一样的，更像是分布式存储。那为什么需要NFS来共享仓库数据目录？用NFS共享和不用NFS共享的区别是什么？只能自己去探索？
位置 描述 默认配置
/var/opt/gitlab/gitlab-rails/uploads 用户上传的附件 gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads'
/var/opt/gitlab/gitlab-rails/shared 诸如构建工件、GitLab 页面、LFS 对象和临时文件等对象。如果您使用 LFS，这也可能占您数据的很大一部分 gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared'
/var/opt/gitlab/gitlab-ci/builds GitLab CI/CD 构建跟踪 gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds'
/var/opt/gitlab/.ssh （*可选）SSH authorized_keys文件和用于从其他一些Git服务导入存储库的密钥 user['home'] = '/var/opt/gitlab/'
/var/opt/gitlab/git-data （*可选）Git存储库数据。这将占你数据的很大一部分。 git_data_dirs({"default" => "/var/opt/gitlab/git-data"})

（可选）/var/opt/gitlab/.ssh

如果没有使用NFS共享此目录，用户上传的public key会存放再sidekiq其中的一个节点的authorized_keys文件中，但是此文件需要在Gitlab Rails集群的每个节点上都有相同的文件。否则，通过ssh的所有操作都将因没有权限而失败（如git clone ...）。

那为什么说是可选？官网提到了"Fast lookup of authorized SSH keys"，通过修改OpenSSH的配置文件（/etc/ssh/sshd_config），可以将原本从authorized_keys查找SSH key，改为从数据库中查找。各人觉得这个方法更合适。

具体配置方式：Fast lookup of authorized SSH keys in the database | GitLab
（可选）/var/opt/gitlab/git-data

为什么这项也是可选？从官网文档中提到可以配置复制因子来看，gitaly cluster上存储的仓库数据，对我来说 gitaly cluster看上去像是可以作为分布式存储。那就不需要NFS来做数据共享。

  1. Praefect不配置复制因子（default_replication_factor未设置），gitlay集群之间节点会互相同步数据，保持数据一致。
  2. 官网文档中提到，对于大性的gitaly cluster（多节点），将存储库复制到每个存储节点是不明智的，通常复制因子3就够了，过高的复制因子会对存储容量造成压力。意思就是说，不将存储库复制到每个存储节点，那么gitaly cluster可以通过增加node节点来横向扩容存储量；反之，每个节点数据都一样，则就意味着只能纵向扩容存储量。
  3. （自己猜想）为什么NFS中，官网提到需要共享git-data目录？在gitaly节点之间用NFS共享数据之后，就省去了在不配置复制因子时，节点之间相互同步数据的动作。也许是这样？

1、2点在官网文档中都可以得到印证，第3点是个人根据官网文档的猜想，目前官网文档中没有明确指出为什么要用NFS共享git-data目录。接下来我会自己测试一下，有结果我会继续更新。

Sidekiq拆分

拆分Sidekiq：

Reference architecture: up to 3,000 users | GitLab

Configure an external Sidekiq instance | GitLab

1.部署准备&注意事项

  1. 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件，并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。
  2. Sidekqi需要连接Redis、Postgresql、Gitaly。数据对象建议使用对象存储，替代NFS。所以也需要连接对象存储。
  3. 如用NFS共享目录，提前将NFS挂载到对应目录（配置文件中示例为："/gitlab-nfs/xxx"）

2./etc/gitlab/gitlab.rb配置

bash 复制代码 
       # https://docs.gitlab.com/omnibus/roles/#sidekiq-roles
   roles(["sidekiq_role"])

   ##
   ## To maintain uniformity of links across nodes, the
   ## `external_url` on the Sidekiq server should point to the external URL that users
   ## use to access GitLab. This can be either:
   ##
   ## - The `external_url` set on your application server.
   ## - The URL of a external load balancer, which routes traffic to the GitLab application server.
   ##
   external_url 'https://gitlab.example.com'

   # Configure the gitlab-shell API callback URL. Without this, `git push` will
   # fail. This can be your 'front door' GitLab URL or an internal load
   # balancer.
   gitlab_rails['internal_api_url'] = 'GITLAB_URL'
   #gitlab_shell['secret_token'] = 'SHELL_TOKEN'

   ########################################
   ####              Redis              ###
   ########################################

   ## Must be the same in every sentinel node.
   #redis['master_name'] = 'gitlab-redis' # Required if you have setup redis cluster
   ## The same password for Redis authentication you set up for the master node.
   #redis['master_password'] = '<redis_master_password>'

   ### If redis is running on the main Gitlab instance and you have opened the TCP port as above add the following
   gitlab_rails['redis_host'] = '<redis_host>'
   gitlab_rails['redis_port'] = 6379
   gitlab_rails['redis_password'] = "<redis_password>"

   #######################################
   ###              Gitaly             ###
   #######################################

   ## Replace <gitaly_token> with the one you set up, see
   ## https://docs.gitlab.com/ee/administration/gitaly/configure_gitaly.html#about-the-gitaly-token
   git_data_dirs({
     "default" => {
        "gitaly_address" => "tcp://<praefect_lb_host>:2305",
        "gitaly_token" => "<praefect_external_token>"
     }
   })

   #######################################
   ###            Postgres             ###
   #######################################

   # Replace <database_host> and <database_password>
   gitlab_rails['db_host'] = '<database_host>'
   gitlab_rails['db_port'] = 5432
   gitlab_rails['db_password'] = '<database_password>'
   ## Prevent database migrations from running on upgrade automatically
   gitlab_rails['auto_migrate'] = false

   #######################################
   ###      Sidekiq configuration      ###
   #######################################
   sidekiq['enable'] = true
   sidekiq['listen_address'] = "0.0.0.0"

   ## Set number of Sidekiq queue processes to the same number as available CPUs
   sidekiq['queue_groups'] = ['*'] * 4

   ## Set number of Sidekiq threads per queue process to the recommend number of 20
   sidekiq['max_concurrency'] = 20

   gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads'
   gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
   gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'

要确保数据库迁移仅在重新配置期间运行，而不是在升级时自动运行，请运行：

bash 复制代码 
sudo touch /etc/gitlab/skip-auto-reconfigure

3.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启
gitlab-ctl restart

Gitlab Rails拆分

1.部署准备&注意事项

  1. 从您配置的第一个Linux包节点复制**/etc/gitlab/gitlab-securts.json**文件，并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。
  2. 从您配置的第一个Linux包节点复制SSH主机密钥（所有密钥的名称格式均为**/etc/ssh/ssh_host_*_key***），并在此服务器上添加或替换相同名称的文件。这确保了当用户遇到负载平衡的Rails节点时，不会向用户抛出主机不匹配错误。如果这是您正在配置的第一个Linux包节点，则可以跳过此步骤。
  3. Rails需要连接Redis、Postgresql、Gitaly。数据对象建议使用对象存储，替代NFS。所以也需要连接对象存储。
  4. 如用NFS共享目录，提前将NFS挂载到对应目录（配置文件中示例为："/gitlab-nfs/xxx"）

2./etc/gitlab/gitlab.rb配置

bash 复制代码 
external_url 'https://gitlab.example.com'

# git_data_dirs get configured for the Praefect virtual storage
# Address is Internal Load Balancer for Praefect
# Token is praefect_external_token
git_data_dirs({
  "default" => {
    "gitaly_address" => "tcp://<praefect_lb_host>:2305", # internal load balancer IP <praefect_service>
    "gitaly_token" => '<praefect_external_token>'
  }
})

## Disable components that will not be on the GitLab application server
roles(['application_role'])
gitaly['enable'] = false
nginx['enable'] = true
sidekiq['enable'] = false

## PostgreSQL connection details
# Disable PostgreSQL on the application node
postgresql['enable'] = false
gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
gitlab_rails['db_port'] = 6432
gitlab_rails['db_password'] = '<postgresql_user_password>'

# Prevent database migrations from running on upgrade automatically
gitlab_rails['auto_migrate'] = false

## Redis connection details
gitlab_rails['redis_host'] = 'redis_host'
gitlab_rails['redis_port'] = 6379
gitlab_rails['redis_password'] = "redis_password"

# Set the network addresses that the exporters used for monitoring will listen on
#node_exporter['listen_address'] = '0.0.0.0:9100'
#gitlab_workhorse['prometheus_listen_addr'] = '0.0.0.0:9229'
#sidekiq['listen_address'] = "0.0.0.0"
puma['listen'] = '0.0.0.0'


## Uncomment and edit the following options if you have set up NFS
##
## Prevent GitLab from starting if NFS data mounts are not available
##
#high_availability['mountpoint'] = '/var/opt/gitlab/git-data'
##
## Ensure UIDs and GIDs match between servers for permissions via NFS
##
#user['uid'] = 9000
#user['gid'] = 9000
#web_server['uid'] = 9001
#web_server['gid'] = 9001
#registry['uid'] = 9002
#registry['gid'] = 9002

gitlab_rails['uploads_directory'] = '/gitlab-nfs/gitlab-data/uploads'
gitlab_rails['shared_path'] = '/gitlab-nfs/gitlab-data/shared'
gitlab_ci['builds_directory'] = '/gitlab-nfs/gitlab-data/builds'

要确保数据库迁移仅在重新配置期间运行，而不是在升级时自动运行，请运行：

bash 复制代码 
touch /etc/gitlab/skip-auto-reconfigure

3.生效配置文件

bash 复制代码 
#reconfigure生效配置文件
gitlab-ctl reconfigure

#重启
gitlab-ctl restart

4.启用增量日志

GitLab Runner 以块的形式返回作业日志，Linux 包默认将这些日志临时缓存在磁盘上 /var/opt/gitlab/gitlab-ci/builds，即使在使用统一对象存储时也是如此。作业完成后，后台作业将归档作业日志。默认情况下，日志将移至工件目录，或者如果配置，则移至对象存储。

使用默认配置时，虽然支持通过 NFS 共享此目录（作业日志），但建议通过启用增量日志记录（未部署 NFS 节点时需要）来避免使用 NFS。增量日志记录使用Redis而不是磁盘空间来临时缓存作业日志。

启用增量日志：Job logs | GitLab

4.1. 要启用增量日志记录

bash 复制代码 
#打开Rails控制台
gitlab-rails console

#启用功能标志
#正在运行的作业的日志继续写入磁盘，但新作业使用增量日志记录。
Feature.enable(:ci_enable_live_trace)

4.2.要禁用增量日志记录

bash 复制代码 
#打开Rails控制台
gitlab-rails console

#禁用功能标志
#正在运行的作业继续使用增量日志记录，但新作业会写入磁盘。
Feature.disable(:ci_enable_live_trace)

5.配置确认

5.1.确认节点可以连接到 Gitaly

确认节点可以连接到Gitaly

bash 复制代码 
sudo gitlab-rake gitlab:gitaly:check

在gitlay节点tail查看请求日志

bash 复制代码 
gitlab-ctl tail gitaly

5.2.(可选)从 Gitaly 服务器确认 Gitaly 可以对内部 API 执行回调

  • 对于 GitLab 15.3 及更高版本，运行sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml.
  • 对于 GitLab 15.2 及更早版本，运行sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml.

总结

  • Sidekiq和Gitlab Rails需要用到Redis和Postgresql，Praefect需要使用到Postgresql。
  • Sidekiq和Gitlab Rails需要配置Praefect的连接信息，Praefect需要配置gitaly的连接信息。（访问存储库）
  • 负载均衡器80/443端口后面代理Gitlab Rails（入口）
  • 负载均衡器内部使用的话，可以考虑将外部/内部负载均衡器放在同一个LB上，没有必要一定要分开。
  • 拆分没有特别强依赖的先后顺序，如果此前是all in one的部署方式（直接yum安装，所有组件默认在同一个node），各个组件也可以通过修改配置文件一步一步单独拆出来。
  • 需要Redis6.2以上时，一定要确认Redis是否可以执行Hello 3
  • 对于需要通过NFS/对象存储共享的目录，一定要好好共享，不然踩坑。
  • 吐槽：对于官网文档，使用NFS还是使用对象存储的选择部分，描述太笼统。只知道使用对象存储能带来更好的性能，但是对于使用NFS和使用对象存储的路径的对应关系描述不清，各个路径如果不共享具体影响也没有描述。不过组件确实很多，文档确实巨长，不能事无巨细的描述清楚也可以理解。
相关推荐
麦聪聊数据24 分钟前
Web 原生架构如何重塑企业级数据库协作流？
数据库·sql·低代码·架构
Fcy64842 分钟前
Linux下 进程(一)（冯诺依曼体系、操作系统、进程基本概念与基本操作）
linux·运维·服务器·进程
袁袁袁袁满44 分钟前
Linux怎么查看最新下载的文件
linux·运维·服务器
代码游侠1 小时前
学习笔记——设备树基础
linux·运维·开发语言·单片机·算法
程序员侠客行1 小时前
Mybatis连接池实现及池化模式
java·后端·架构·mybatis
Harvey9031 小时前
通过 Helm 部署 Nginx 应用的完整标准化步骤
linux·运维·nginx·k8s
珠海西格电力科技2 小时前
微电网能量平衡理论的实现条件在不同场景下有哪些差异？
运维·服务器·网络·人工智能·云计算·智慧城市
bobuddy3 小时前
射频收发机架构简介
架构·射频工程
释怀不想释怀3 小时前
Linux环境变量
linux·运维·服务器
zzzsde3 小时前
【Linux】进程（4）：进程优先级&&调度队列
linux·运维·服务器
热门推荐
01GitHub 镜像站点02Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services03openclaw配置教程（linux+局域网ollama）04OpenClaw Chrome扩展使用教程 - 浏览器中继控制05Linux下V2Ray安装配置指南06UV安装并设置国内源07Claude Code Skills 实用使用手册08一文了解国产算子编程语言 TileLang，TileLang 对国产开源生态的影响与启示09让 Trae IDE 智能体 “读懂”文档 Excel+PDF+DOCX ：mcp-documents-reader 工具使用指南10Vue-skills的中文文档