GitLab Linux集群如何部署

GitLab Linux集群部署与高可用实践

一 架构选型与准备

• 架构选型
  • 单机多实例：在每台服务器安装 Omnibus GitLab，前面用 Nginx/HAProxy 做 7 层或 4 层负载均衡，后端共享存储承载仓库数据。适合中小规模或过渡阶段。
  • 拆分架构：将 PostgreSQL、Redis 等状态服务外置（云数据库或自建高可用集群），应用层无状态横向扩展，配合 Gitaly/Consul 管理仓库与内部服务发现，适合生产级高可用与弹性扩容。
• 节点与网络
  • 建议至少 3 台应用节点，并准备 1 台或多台 数据库/缓存/存储节点；生产环境建议数据库与 GitLab 节点分离。
  • 开放端口：对外 80/443（HTTP/HTTPS），SSH 建议通过 4 层负载均衡暴露 22/TCP 到各实例的 22 端口；实例间开放管理端口以便集群通信。
• 存储与共享
  • 无 Gitaly Cluster 时可用 NFS/GlusterFS/CephFS 共享 /var/opt/gitlab/git-data；使用 Gitaly Cluster 时以复制因子保障数据一致性，通常 复制因子 3 更均衡。
• 基础组件
  • 负载均衡器：Nginx/HAProxy（支持健康检查、会话保持按需开启）。
  • 数据库与缓存：PostgreSQL（建议 ≥12，启用 pg_trgm、btree_gist、plpgsql 扩展）、Redis（建议 ≥6）。
  • 操作系统与资源：推荐 Ubuntu 20.04+/CentOS 7+；单实例建议 4–8 GB 内存起步，生产环境按规模加配 CPU/内存与 IOPS。

二 方案一 单机多实例加负载均衡

• 安装 Omnibus GitLab（以 CentOS 7 为例）
  • 安装依赖与仓库：
    • sudo yum install -y curl policycoreutils openssh-server openssh-clients postfix
    • sudo systemctl enable --now sshd postfix
    • curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
  • 安装 GitLab CE：
    • sudo yum install -y gitlab-ce
• 配置实例与负载均衡
  • 在各节点编辑 /etc/gitlab/gitlab.rb：
    • external_url ‘https://gitlab.example.com’
    • 统一或区分各节点 SSH 端口（如 2222/2223/2224）：gitlab_rails[‘gitlab_shell_ssh_port’] = 2222
    • 建议开启健康与优雅停机：nginx[‘worker_processes’]、unicorn[‘worker_processes’] 按 CPU 核数调整
  • 应用配置并启动：
    • sudo gitlab-ctl reconfigure
    • sudo gitlab-ctl restart
  • 配置 Nginx 作为 7 层负载均衡（示例）：
    • upstream gitlab { server gitlab1.example.com; server gitlab2.example.com; server gitlab3.example.com; }
    • server { listen 80; server_name gitlab.example.com; location / { proxy_pass http://gitlab; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }
  • 配置 HAProxy（示例，4 层转发 SSH 与 7 层转发 HTTP/HTTPS）：
    • frontend http-in bind *:80 mode http default_backend gitlab_http
    • frontend https-in bind *:443 mode tcp default_backend gitlab_https
    • frontend ssh-in bind *:22 mode tcp default_backend gitlab_ssh
    • backend gitlab_http mode http balance roundrobin server gitlab1 gitlab1.example.com:80 check
    • backend gitlab_https mode tcp balance roundrobin server gitlab1 gitlab1.example.com:443 check
    • backend gitlab_ssh mode tcp balance roundrobin server gitlab1 gitlab1.example.com:22 check
• 共享存储（无 Gitaly Cluster 时）
  • 以 NFS 为例：在所有节点挂载同一共享目录到 /var/opt/gitlab/git-data，确保 UID/GID 与权限一致；Git 克隆使用 SSH 22 或 HTTP(S) 80/443。

三 方案二 拆分架构与 Gitaly Cluster

• 外部数据库
  • 关闭内置数据库：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’] = ‘pg-vip.example.com’
    • gitlab_rails[‘db_port’] = 5432
  • 在数据库中创建扩展：CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE EXTENSION IF NOT EXISTS btree_gist; CREATE EXTENSION IF NOT EXISTS plpgsql;
• 外部 Redis
  • 关闭内置 Redis：redis[‘enable’] = false
  • 配置外部 Redis（示例）：
    • gitlab_rails[‘redis_host’] = ‘redis-vip.example.com’
    • gitlab_rails[‘redis_port’] = 6379
    • gitlab_rails[‘redis_password’] = ‘your_redis_password’
• Gitaly Cluster
  • 部署 3+ 个 Gitaly 节点，启用 Praefect 做事务一致性与路由；设置复制因子（如 default_replication_factor = 3），确保写入多数派成功。
  • 在 gitlab.rb 中配置 Gitaly/Praefect 地址与令牌，执行 gitlab-ctl reconfigure 使配置生效。
• SSH 公钥快速查询（可选）
  • 启用数据库查询公钥以提升一致性与扩展性：配置 GitLab 使用数据库进行 authorized_keys 查找，避免多节点 /var/opt/gitlab/.ssh/authorized_keys 同步问题。
• 服务发现（可选）
  • 若不使用云托管数据库/Redis，可用 Consul 做数据库服务发现与健康检查，简化内部依赖管理。

四 部署后的安全与运维

• 安全加固
  • 全站 HTTPS（证书可用 Let’s Encrypt 或企业 CA），对外仅暴露 80/443 与 22（通过 4 层 LB）；启用 防火墙 与 SELinux/AppArmor 策略；限制管理接口与数据库访问来源。
• 备份与恢复
  • Omnibus 内置备份：/opt/gitlab/bin/gitlab-backup create；建议定时任务每日备份并将备份文件存储到独立存储/对象存储；定期演练恢复流程。
• 监控与告警
  • 启用 Prometheus + Grafana（Omnibus 内置），监控 Unicorn/Puma、Sidekiq、PostgreSQL、Redis、Gitaly 等关键指标；配置告警规则与通知渠道（邮件/企业微信/钉钉/Slack）。
• 升级与变更
  • 采用 滚动升级：先升级非生产环境，验证通过后分批升级生产节点；每一步执行 gitlab-ctl reconfigure 与必要的数据迁移检查；保持版本一致性与回滚预案。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！