目录
5.2.(可选)从 Gitaly 服务器确认 Gitaly 可以对内部 API 执行回调
前言
整体架构参考:Reference architecture: up to 50,000 users | GitLab
为了简化部署,Postgresql、Redis等,会使用云厂商提供的服务
(引用gitlab官网架构图)
负载均衡器准备
可以考虑使用云厂商的负载均衡器,提供7层和4层的负载均衡。
如果只是内网使用,或者测试场景。外部负载均衡器和内部负载均衡器可以考虑使用同一个负载均衡器,以节省资源。
配置外部负载均衡器: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
Postgresql拆分
参考文档:
1.gitlab版本和支持的postgresql版本对应关系:Installation system requirements | GitLab
2.配置外部postgresql:Configure GitLab using an external PostgreSQL service | GitLab
以下步骤默认已有高可用的pgstgresql数据库
1.准备postgresql集群
- 可以选择云厂商提供的pg集群,根据数据库需求文档,创建合适版本的postgresql高可用集群。
- 创建gitlab用户
- 创建数据库gitlabhq_production,并配置owner为gitlab用户
- 开启插件:pg_trgm、btree_gist、plpgsql
手动安装postgresql插件
#安装插件
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配置
#关闭内置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.生效配置文件
#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
- 可以选择云厂商提供的redis,16.x版本的gitlab建议使用6.2及以上的redis版本
- 特别不建议使用Redis集群,单可以使用高可用的Redis Standalone
- 配置适合的驱逐模式
1./etc/gitlab/gitlab.rb配置
#关闭内置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.生效配置文件
#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 数据库。
- 已拥有postgresql(复用gitlabhq_production库使用的postgresql)
- 创建praefect用户
- 创建数据库praefect_production,并配置owner为praefect用户
#登陆数据库,创建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:
2.1.部署准备&注意事项
- 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件,并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点,则可以跳过此步骤。
- Praefect必须部署在奇数个3个节点或更高节点中。这是为了确保节点可以将投票作为法定人数的一部分。
- Praefect需要连接Postgresql。
- Praefect 需要运行一些数据库迁移,就像主 GitLab 应用程序一样。为此,您应该仅选择一个 Praefect 节点来运行迁移,也称为部署节点。必须先配置此节点,然后再配置其他节点。
2.2./etc/gitlab/gitlab.rb配置
Praefect 需要运行一些数据库迁移,就像主 GitLab 应用程序一样。为此,您应该仅选择一个 Praefect 节点来运行迁移,也称为部署节点。必须先配置此节点,然后再配置其他节点,如下所示:
- 在/etc/gitlab/gitlab.rb文件中,将praefect['auto_migrate']设置值从更改false为true
- 要确保数据库迁移仅在重新配置期间运行,而不是在升级时自动运行,请运行:
sudo touch /etc/gitlab/skip-auto-reconfigure
- name: 'default'的值,需要和git_data_dirs配置中的name一致。
- storage: 'gitaly-1'...,需要和每个gitaly节点的gitaly['configuration'][:storage]中的name一致。
# 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.生效配置文件
#reconfigure生效配置文件
gitlab-ctl reconfigure
#重启
gitlab-ctl restart / gitlab-ctl restart praefect
2.4.验证Praefect与gitaly的连接配置状态
Praefect和Gitlay都配置完成后,可以连接到Praefect节点上执行命令进行验证
sudo /opt/gitlab/embedded/bin/praefect -config /var/opt/gitlab/praefect/config.toml dial-nodes
3.配置gitaly
1.配置gitaly:
3.1.部署准备&注意事项
- 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件,并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点,则可以跳过此步骤。
3.2. /etc/gitlab/gitlab.rb配置
#开启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')请求。
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用户拥有权限,否则会报错。
mkdir -p /var/opt/gitlab/git-data/repositories
chown git: /var/opt/gitlab/git-data/repositories
3.4.生效配置文件
#reconfigure生效配置文件
gitlab-ctl reconfigure
#重启
gitlab-ctl restart / gitlab-ctl restart gitaly
NFS配置
后续拆分Sidekiq & GitLab Rails集群需要用到NFS共享一些目录
gitlab官方不建议使用云服务商提供的NFS服务,会对影响有不可预估的影响。
部署NFS server可参考:https://docs.gitlab.com/ee/administration/nfs.html#nfs-server
(本问为了方便,没有部署NFS server,直接是有云服务商提供的NFS服务)
这边不得不吐槽一下官网文档,踩坑踩的很痛苦!
- 文档写有4个路径需要NFS共享,给出来的表格只列出来3个。而一番google之后,实际上最多有5个路径需要NFS共享。
- 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来做数据共享。
- Praefect不配置复制因子(default_replication_factor未设置),gitlay集群之间节点会互相同步数据,保持数据一致。
- 官网文档中提到,对于大性的gitaly cluster(多节点),将存储库复制到每个存储节点是不明智的,通常复制因子3就够了,过高的复制因子会对存储容量造成压力。意思就是说,不将存储库复制到每个存储节点,那么gitaly cluster可以通过增加node节点来横向扩容存储量;反之,每个节点数据都一样,则就意味着只能纵向扩容存储量。
- (自己猜想)为什么NFS中,官网提到需要共享git-data目录?在gitaly节点之间用NFS共享数据之后,就省去了在不配置复制因子时,节点之间相互同步数据的动作。也许是这样?
1、2点在官网文档中都可以得到印证,第3点是个人根据官网文档的猜想,目前官网文档中没有明确指出为什么要用NFS共享git-data目录。接下来我会自己测试一下,有结果我会继续更新。
Sidekiq拆分
拆分Sidekiq:
1.部署准备&注意事项
- 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件,并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点,则可以跳过此步骤。
- Sidekqi需要连接Redis、Postgresql、Gitaly。数据对象建议使用对象存储,替代NFS。所以也需要连接对象存储。
- 如用NFS共享目录,提前将NFS挂载到对应目录(配置文件中示例为:“/gitlab-nfs/xxx”)
2./etc/gitlab/gitlab.rb配置
# 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'
要确保数据库迁移仅在重新配置期间运行,而不是在升级时自动运行,请运行:
sudo touch /etc/gitlab/skip-auto-reconfigure
3.生效配置文件
#reconfigure生效配置文件
gitlab-ctl reconfigure
#重启
gitlab-ctl restart
Gitlab Rails拆分
1.部署准备&注意事项
- 从您配置的第一个Linux包节点复制/etc/gitlab/gitlab-securts.json文件,并在此服务器上添加或替换同名文件。如果这是您正在配置的第一个Linux包节点,则可以跳过此步骤。
- 从您配置的第一个Linux包节点复制SSH主机密钥(所有密钥的名称格式均为/etc/ssh/ssh_host_*_key*),并在此服务器上添加或替换相同名称的文件。这确保了当用户遇到负载平衡的Rails节点时,不会向用户抛出主机不匹配错误。如果这是您正在配置的第一个Linux包节点,则可以跳过此步骤。
- Rails需要连接Redis、Postgresql、Gitaly。数据对象建议使用对象存储,替代NFS。所以也需要连接对象存储。
- 如用NFS共享目录,提前将NFS挂载到对应目录(配置文件中示例为:“/gitlab-nfs/xxx”)
2./etc/gitlab/gitlab.rb配置
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'
要确保数据库迁移仅在重新配置期间运行,而不是在升级时自动运行,请运行:
touch /etc/gitlab/skip-auto-reconfigure
3.生效配置文件
#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. 要启用增量日志记录
#打开Rails控制台
gitlab-rails console
#启用功能标志
#正在运行的作业的日志继续写入磁盘,但新作业使用增量日志记录。
Feature.enable(:ci_enable_live_trace)
4.2.要禁用增量日志记录
#打开Rails控制台
gitlab-rails console
#禁用功能标志
#正在运行的作业继续使用增量日志记录,但新作业会写入磁盘。
Feature.disable(:ci_enable_live_trace)
5.配置确认
5.1.确认节点可以连接到 Gitaly
确认节点可以连接到Gitaly
sudo gitlab-rake gitlab:gitaly:check
在gitlay节点tail查看请求日志
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和使用对象存储的路径的对应关系描述不清,各个路径如果不共享具体影响也没有描述。不过组件确实很多,文档确实巨长,不能事无巨细的描述清楚也可以理解。
文章评论