GitLab Linux版如何实现负载均衡

Linux 上 GitLab 实现负载均衡的落地方案

一 架构与前提

• 组件拆分：至少准备2–3 台 GitLab 应用节点，前置Nginx/HAProxy 作为反向代理与健康检查；后端共享同一套数据平面（PostgreSQL 高可用、Redis 高可用、仓库数据）。
• 数据与存储：数据库建议主从/流复制或 pg_auto_failover；缓存采用 Redis 主从 + Sentinel；仓库数据使用 NFS/GlusterFS/CephFS 共享，或基于 Kubernetes/Swarm 的分布式卷。
• 入口高可用：两台入口节点部署 HAProxy + Keepalived 提供 VIP，实现故障自动漂移。
• 端口规划：对外暴露 HTTP/HTTPS/SSH；如由外部 LB 终止 TLS，可关闭内置 Nginx，并调整 GitLab Shell 的 SSH 端口（如 2222）。

二 部署步骤

• 安装与基础配置
  • 各节点安装 GitLab（Omnibus 或 Docker），编辑 /etc/gitlab/gitlab.rb 设置 external_url、时区、日志与监控等；完成后执行 gitlab-ctl reconfigure 使配置生效。
• 配置负载均衡器（两种常见做法）
  • 方案 A（外部 LB 终止 TLS）：关闭内置 Nginx，由 LB 管理证书与 HTTPS；GitLab 节点对外仅提供 HTTP。
  • 方案 B（内置 Nginx 终止 TLS）：LB 以 HTTP 转发到各节点，证书在节点上管理。
• 数据库与缓存高可用
  • PostgreSQL：配置主从复制或使用 pg_auto_failover；在 gitlab.rb 中设置 gitlab_rails[‘db_adapter’]、db_host、db_port、db_database 等指向当前主库。
  • Redis：部署主从 + Sentinel；在 gitlab.rb 中配置 gitlab_rails[‘redis_host’]、redis_port、redis_sentinels 指向 Sentinel 集群。
• 存储与仓库数据
  • 共享存储：所有节点挂载同一仓库根目录（如 /var/opt/gitlab/git-data），确保权限一致与挂载稳定性。
  • 容器/编排：使用 Kubernetes/Swarm 时，将配置、日志、数据分别挂载为卷/持久卷，实现横向扩展与调度高可用。
• 入口高可用（可选）
  • 两台入口节点部署 HAProxy + Keepalived，配置 VIP 与健康检查脚本，故障时 VIP 漂移到备机。

三 关键配置示例

• 外部 LB 终止 TLS（关闭内置 Nginx）
  • /etc/gitlab/gitlab.rb

    external_url 'https://gitlab.example.com'
    nginx['enable'] = false
    gitlab_rails['gitlab_shell_ssh_port'] = 2222
    

  • 系统 SSH 端口调整为 2222，并在 LB 发布 22 → 后端 2222 的端口映射，保持 Git 原生 SSH 体验（git@gitlab.example.com:repo.git）。
• Nginx 作为负载均衡器（HTTP 转发到后端节点）

  upstream gitlab {
      
    server gitlab1.example.com;
      
    server gitlab2.example.com;
      
    # 可选：least_conn;
       或 ip_hash;
   用于会话保持
  }
  
  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 作为负载均衡器（HTTP）

  global
    daemon
    maxconn 256
  
  defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms
  
  frontend gitlab_http
    bind *:80
    default_backend gitlab_nodes
  
  backend gitlab_nodes
    balance roundrobin
    server node1 10.0.0.11:80 check inter 2000 rise 2 fall 5
    server node2 10.0.0.12:80 check inter 2000 rise 2 fall 5
  

• 数据库与缓存指向示例（gitlab.rb）

  # PostgreSQL
  gitlab_rails['db_adapter']  = "postgresql"
  gitlab_rails['db_host']     = "pg-primary.example.com"
  gitlab_rails['db_port']     = 5432
  gitlab_rails['db_database'] = "gitlabhq_production"
  
  # Redis Sentinel
  gitlab_rails['redis_host']       = "redis-sentinel.example.com"
  gitlab_rails['redis_port']       = 6379
  gitlab_rails['redis_sentinels']  = [
    {
   host: '10.0.0.21', port: 26379 }
  ,
    {
   host: '10.0.0.22', port: 26379 }
      
  ]
  

• 重要提示
  • 各节点的 external_url 应统一为 LB 的域名（如 https://gitlab.example.com），避免页面跳转与资产链接异常。
  • 不建议在多实例间使用不同端口作为“实例标识”（如 8080/8081）；端口冲突应通过反向代理或编排解决，保持应用配置一致性。

四 验证与运维要点

• 健康检查与服务状态
  • Nginx：systemctl status nginx；访问日志：tail -f /var/log/nginx/access.log
  • HAProxy：systemctl status haproxy；统计页：curl http://localhost:1936/stats（需开启 stats）。
• 故障演练与流量验证
  • 停止某台 GitLab 实例（gitlab-ctl stop），验证 LB 是否自动剔除故障节点并将流量分发至健康实例；恢复后确认重新加入。
• 监控与告警
  • 集成 Prometheus + Grafana，监控 Unicorn/Workhorse、Sidekiq、PostgreSQL、Redis、节点资源 等指标，设置告警规则覆盖进程宕机、延迟异常、复制滞后等。
• 备份与容灾
  • 使用 gitlab-backup create 定期备份（建议每日），可结合对象存储异地归档；定期演练全量恢复，验证 RTO/RPO。
  • 跨地域容灾可叠加 GitLab Geo，实现只读镜像、差异同步与灾难切换。

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