Debian系统中如何确保GitLab的高可用性

在 Debian 上构建 GitLab 高可用

一 架构总览与前置准备

• 架构选型建议
  • 小型团队：至少准备2 台应用节点 + 1 台外部数据库（PostgreSQL HA）+ 1 台外部 Redis（主从/哨兵）+ 入口 L4/L7 负载均衡器（如 HAProxy/Nginx/云LB）。
  • 中大型团队：将 PostgreSQL、Redis、Gitaly、Praefect、Sidekiq 拆分到独立集群，入口 LB 与内部服务 LB 分离，必要时引入 Consul 做数据库服务发现。
• 基础准备
  • 系统为 Debian，时间同步（如 chrony）、域名与 DNS 解析、稳定的内网/公网网络、必要的防火墙放行（80/443/22 或仅 443/22 并做 TLS 终止）。
  • 规划数据与日志目录、备份策略与恢复演练窗口，确保容量与 IOPS 充足。

二 部署与配置步骤

• 安装与基础配置
  • 在每台应用节点安装 GitLab（CE/EE 均可），建议统一版本与基础 OS 镜像；设置 external_url 为对外域名，按需开启 HTTPS。
  • 示例（Debian 包安装）：
    • 安装依赖与仓库：
      • sudo apt-get update && sudo apt-get install -y curl openssh-server ca-certificates tzdata perl
      • curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
    • 安装 GitLab（将域名替换为你的域名）：
      • sudo EXTERNAL_URL=“https://gitlab.example.com” apt-get install gitlab-ce
    • 应用配置并重启：
      • sudo gitlab-ctl reconfigure
      • sudo gitlab-ctl restart
• 入口负载均衡
  • 使用 HAProxy/Nginx 对外提供 80/443，后端指向多个 GitLab 节点；健康检查建议基于 HTTP 路径（如 /-/health）。
  • 示例（HAProxy 片段）：
    • frontend http_front
      • bind *:80
      • default_backend gitlab_http
    • backend gitlab_http
      • balance roundrobin
      • server gitlab1 10.0.0.11:80 check
      • server gitlab2 10.0.0.12:80 check
  • 若由 LB 终止 TLS，后端可用 HTTP；若由后端终止 TLS，LB 转发 TCP/443。SSH 建议保持直连各节点（见下一节）。
• 数据与状态服务拆分（推荐）
  • PostgreSQL：使用外部 PostgreSQL 高可用集群（云 RDS、Patroni、pg_auto_failover 等），在 GitLab 节点关闭内置数据库并指向外部实例。
    • 关键配置（/etc/gitlab/gitlab.rb）：
      • postgresql[‘enable’] = false
      • gitlab_rails[‘db_adapter’] = ‘postgresql’
      • gitlab_rails[‘db_database’] = ‘gitlabhq_production’
      • gitlab_rails[‘db_username’] = ‘gitlab’
      • gitlab_rails[‘db_password’] = ‘强密码’
      • gitlab_rails[‘db_host’] = ‘pg-vip.example.com’
      • gitlab_rails[‘db_port’] = 5432
  • Redis：使用外部 Redis 主从/哨兵，不建议 Redis Cluster；配置合适驱逐策略（如 allkeys-lru）。
    • 关键配置（/etc/gitlab/gitlab.rb）：
      • redis[‘enable’] = false
      • gitlab_rails[‘redis_host’] = ‘redis-vip.example.com’
      • gitlab_rails[‘redis_port’] = 6379
      • gitlab_rails[‘redis_password’] = ‘强密码’
  • Gitaly/Praefect（大规模必备）：将 Gitaly 集群化，前置 Praefect 做元数据与一致性管理；Praefect 需配置后端 Gitaly 列表与数据库（PostgreSQL）。
  • 对象存储：将 上传、LFS、Artifacts、Packages、Registry 指向对象存储（如 S3/兼容），降低本地磁盘依赖与复制复杂度。
• 存储与共享方案（按规模选择）
  • 小规模/快速起步：可用 NFS 共享 /var/opt/gitlab（或至少共享 repositories 等子目录），注意性能与单点风险。
  • 中大规模/更强韧性：使用 GlusterFS/CEPH 等分布式文件系统，或直接使用对象存储承载可迁移数据，避免共享块存储的单点。

三 运维与故障演练

• 配置生效与健康检查
  • 每次修改 /etc/gitlab/gitlab.rb 后执行：sudo gitlab-ctl reconfigure；使用 sudo gitlab-ctl status 检查组件状态；/var/log/gitlab 下按组件定位问题。
• 监控与告警
  • 启用内置 Prometheus/Grafana 或对接企业监控，关注：HTTP 5xx、Puma/Rails 队列、Sidekiq 重试与死信、PostgreSQL/Redis 延迟与复制滞后、磁盘/IO、证书到期。
• 备份与恢复
  • 使用 gitlab-backup 创建全量备份（含仓库与数据库），定期演练恢复流程；备份与对象存储、异地存储结合，保留策略按合规设定。
• 故障演练
  • 定期演练：停止单台应用节点、断开数据库主库、模拟网络分区、证书过期等，验证 LB 健康检查、数据库/Redis 故障转移、应用自愈 是否符合 SLA。

四 关键注意事项

• 版本与兼容性：确保 GitLab 版本与 PostgreSQL/Redis 版本满足官方支持矩阵；拆分部署时按官方参考架构进行组件版本匹配。
• SSH 访问
  • 建议保持 SSH 直连各 GitLab 节点（端口 22），在 DNS/负载均衡层使用 SRV 记录或文档告知用户多入口；若经 LB 转发 SSH，需处理 TCP 转发与健康检查的特殊性。
• 存储取舍
  • NFS 简单但存在单点风险；GlusterFS/CEPH 具备更高可用与扩展性；对象存储适合承载可迁移的大对象，减少共享存储依赖。
• 数据库与缓存
  • 生产环境优先使用 外部托管/集群化的 PostgreSQL/Redis，并配置主从复制、故障转移与健康检查；避免将内置数据库/Redis 用于生产高可用场景。
• 安全与合规
  • 强制 TLS 1.2+、禁用弱密码套件；最小权限访问数据库/Redis；开启审计日志；定期升级与漏洞修补；备份加密与访问控制。