如何确保Linux上GitLab的高可用性

Linux上实现 GitLab 高可用的落地方案

一、总体架构与前提

• 架构要点：至少准备2–3台 Linux 服务器，前置负载均衡器（如 Nginx/HAProxy），后端多台 GitLab 应用节点共享同一套后端数据平面（数据库、缓存、仓库存储）。数据库建议采用 PostgreSQL 高可用（主从/流复制或 pg_auto_failover），缓存采用 Redis 高可用（主从 + Sentinel）。存储层可用 NFS/GlusterFS/Ceph 共享仓库数据，或采用分布式/容器编排方案。跨地域容灾可叠加 GitLab Geo。以上组件共同目标是消除单点故障并实现自动故障转移与快速恢复。

二、部署步骤

• 基础准备
  • 规划域名、证书、端口与防火墙策略；对外暴露 HTTP/HTTPS/SSH，并为负载均衡器与后端节点间开放健康检查与管理端口。
• 安装与基础配置
  • 在每台节点安装 GitLab（Omnibus 包或 Docker），编辑 /etc/gitlab/gitlab.rb 设置 external_url、时区、日志与监控等基础项；如需由外部负载均衡器终止 TLS，可关闭内置 Nginx 并配置外部证书。完成后执行 gitlab-ctl reconfigure 使配置生效。
• 负载均衡与入口高可用
  • 使用 Nginx/HAProxy 做反向代理与健康检查，示例 Nginx upstream：
    • upstream gitlab { server gitlab1.example.com; server gitlab2.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 + Keepalived 提供 VIP，健康检查脚本监控 HAProxy 进程，故障时 VIP 漂移到备机。
• 数据库高可用
  • 方案 A：PostgreSQL 主从流复制 + 手动/脚本切换；在 gitlab.rb 中配置 gitlab_rails[‘db_adapter’] = “postgresql” 与 gitlab_rails[‘db_host’] 指向当前主库。
  • 方案 B：使用 pg_auto_failover 一键化搭建主从与监视器，简化故障检测与切换流程（适合 2 节点起步）。
• 缓存高可用
  • 部署 Redis 主从 + Sentinel，Sentinel 提供故障发现与自动主从切换；在 gitlab.rb 中配置 gitlab_rails[‘redis_host’]、[‘redis_port’]、[‘redis_sentinels’] 等参数指向 Sentinel 集群。
• 存储与仓库数据
  • 方案 A：使用 NFS/GlusterFS/CephFS 等共享存储，所有节点挂载同一仓库根目录（如 /var/opt/gitlab/git-data），确保权限一致与挂载稳定性。
  • 方案 B：基于 Docker Swarm/Kubernetes 的分布式编排，将配置、日志、数据分别挂载为卷/持久卷，实现多实例横向扩展与调度高可用。

三、关键配置与参数示例

• 外部负载均衡场景（关闭内置 Nginx，由外部 LB 终止 TLS）
  • /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 体验。
• HAProxy + Keepalived 入口示例
  • /etc/haproxy/haproxy.cfg
    • 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
  • Keepalived 健康检查脚本示例（检查 HAProxy 进程存活），主节点优先级更高，故障时 VIP 漂移至备机。
• 数据库与缓存示例
  • PostgreSQL（gitlab.rb）
    • 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.rb）
    • 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 } ]

四、备份恢复与异地容灾

• 备份策略
  • 使用 gitlab-backup create 定期备份（建议每日），可结合对象存储做异地归档；数据库与存储分离的场景可分别备份，降低恢复复杂度。
• 恢复演练
  • 定期在隔离环境演练全量恢复，验证备份可用性与恢复时间目标（RTO/RPO）。
• 异地容灾
  • 跨城市/机房部署 GitLab Geo，实现只读镜像、差异同步与灾难切换，缩短跨区域不可用时间。

五、监控、验证与运维要点

• 健康检查与可视化
  • 配置 Prometheus + Grafana 监控 GitLab 组件（Unicorn/Workhorse、Sidekiq、PostgreSQL、Redis、节点资源等），设置告警规则覆盖进程宕机、延迟异常、复制滞后等。
• 故障转移演练
  • 定期模拟节点宕机、数据库主从切换、入口 VIP 漂移、存储不可用等场景，验证自动/半自动切换与数据一致性，记录 RTO/RPO 指标并优化。
• 日常运维
  • 统一配置管理（如 gitlab.rb 通过 Git 管理）、变更窗口与回滚预案、证书自动续期（如 certbot）、内核与网络参数调优（如 somaxconn、swappiness）、存储健康与容量预警。

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