如何在CentOS中实现GitLab的高可用性

在 CentOS 上落地 GitLab 高可用

一 架构总览与前提

• 组件拆分：至少准备2–3 台 GitLab 应用节点，前置Nginx/HAProxy 做反向代理与健康检查；数据库采用 PostgreSQL 高可用（主从/流复制或 pg_auto_failover）；缓存采用 Redis 主从 + Sentinel；仓库数据使用 NFS/GlusterFS/CephFS 共享，或基于容器编排的分布式卷；跨地域可叠加 GitLab Geo。目标是消除单点并实现自动/半自动故障转移与快速恢复。
• 基础要求：建议使用 CentOS 7+，规划统一域名与证书，开放 80/443/22 及数据库、Redis 端口；为外部负载均衡器与后端节点间开放健康检查与管理端口；确保 NTP/chrony 时间同步与稳定网络。

二 部署步骤

• 安装 GitLab 应用节点（Omnibus）
  • 在所有节点安装：
    • curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.rpm.sh | sudo bash
    • sudo yum install -y gitlab-ce
  • 编辑 /etc/gitlab/gitlab.rb：设置唯一 external_url（如 http://gitlab1.example.com）、时区、日志级别；如需由外部 LB 终止 TLS，可关闭内置 Nginx：nginx[‘enable’] = false；如需自定义 SSH 端口，设置 gitlab_rails[‘gitlab_shell_ssh_port’]（如 2222）。
  • 应用配置：sudo gitlab-ctl reconfigure。
• 部署入口负载均衡
  • 方案 A（单 LB）：Nginx/HAProxy 配置 upstream 分发至各节点，开启 HTTP 健康检查，设置 X-Real-IP/X-Forwarded-For/X-Forwarded-Proto 等头。
  • 方案 B（入口高可用）：两台入口节点部署 HAProxy + Keepalived，对外暴露 VIP，健康检查脚本监控 HAProxy，故障时 VIP 漂移。
• 数据库高可用（PostgreSQL）
  • 方案 A：PostgreSQL 主从流复制，配置 replication 用户与权限，主库开启 WAL 归档，备库通过 basebackup/流复制同步；故障切换时提升备库为主并更新应用连接。
  • 方案 B：使用 pg_auto_failover（2 节点起步）快速搭建主从与监视器，简化故障检测与切换流程。
• 缓存高可用（Redis）
  • 部署 Redis 主从 + Sentinel，Sentinel 提供故障发现与自动主从切换；应用侧配置连接 Sentinel 集群 的地址与端口（默认 26379）。
• 共享存储与仓库数据
  • 方案 A：使用 NFS/GlusterFS/CephFS 共享仓库根目录（如 /var/opt/gitlab/git-data），所有节点挂载同一目录，注意权限一致与挂载稳定性。
  • 方案 B：基于 Docker Swarm/Kubernetes 的分布式编排，将配置、日志、数据分别挂载为卷/持久卷，实现多实例横向扩展与调度高可用。

三 关键配置示例

• 外部 LB 终止 TLS（关闭内置 Nginx，调整 SSH 端口）
  • /etc/gitlab/gitlab.rb：
    • external_url ‘https://gitlab.example.com’
    • nginx[‘enable’] = false
    • gitlab_rails[‘gitlab_shell_ssh_port’] = 2222
  • 在 LB 发布 443→后端 80/8080（取决于是否启用内置 Nginx），发布 22→后端 2222，并配置正确的转发头。
• 数据库与缓存连接（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”
    • gitlab_rails[‘db_username’] = “gitlab”
    • gitlab_rails[‘db_password’] = “your_password”
  • 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 }]
• 共享存储（NFS 示例）
  • NFS Server：/etc/exports 添加
    • /srv/gitlab/repo *(rw,sync,no_root_squash)
  • GitLab 节点：
    • mount -t nfs nfs-server:/srv/gitlab/repo /var/opt/gitlab/git-data/repositories
    • 写入 /etc/fstab 实现开机自动挂载。

四 备份恢复与异地容灾

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

五 监控验证与运维要点

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