ubuntu中gitlab集群搭建方案

Ubuntu 上 GitLab 集群搭建方案

一 架构选型与总体设计

• 目标：在 Ubuntu 22.04/24.04 上构建可横向扩展、具备故障转移能力的 GitLab 集群，覆盖 前端接入、应用层、数据与缓存、存储、监控与备份 五大域。
• 推荐三种落地路径（按复杂度与弹性排序）：
  • Omnibus 多节点 + 外部数据库/缓存 + 共享存储（最稳妥，便于传统运维）
  • Docker Compose 多实例（轻量快速，适合验证与中小规模）
  • Kubernetes Helm Chart（弹性最佳，适合云原生与大规模）
• 核心组件与职责：
  • 前端接入：Nginx/HAProxy + Keepalived VIP（对外统一域名与端口）
  • 应用层：多台 GitLab Rails/Unicorn/Puma 实例（无状态，会话保持建议关闭）
  • 数据与缓存：外部 PostgreSQL（主从/流复制）、外部 Redis（主从 + Sentinel）
  • 存储：NFS/GlusterFS/CephFS（承载 repositories、uploads、artifacts、lfs、backups 等共享目录）
  • 监控与备份：Prometheus/Alertmanager（可选）、gitlab-backup create 定时任务与对象存储远端备份

二 方案一 Omnibus 多节点高可用（Ubuntu 推荐）

• 节点与网络规划（示例）
  • 节点：
    • gitlab-web-01/02：运行 GitLab 应用（无状态）
    • db-01/02：PostgreSQL 主从
    • redis-01/02：Redis 主从 + Sentinel
    • nfs-01：NFS/GlusterFS/CephFS 共享存储
    • lb-01/02：HAProxy + Keepalived（对外 VIP 192.168.10.100）
  • 端口：
    • HTTP/HTTPS：80/443
    • SSH Git：22（通过 LB VIP 或每台主机 22 转发）
• 安装与基础配置（两台 Web 节点）
  • 安装 Omnibus 包：
    • 导入 GPG 并添加源后执行：sudo apt-get install gitlab-ce
  • 统一配置 /etc/gitlab/gitlab.rb（两台一致，除主机名等差异）：
    • external_url ‘https://gitlab.example.com’
    • nginx[‘listen_port’] = 80
    • nginx[‘listen_https’] = true
    • letsencrypt[‘enable’] = true
    • gitlab_rails[‘gitlab_shell_ssh_port’] = 22
    • postgresql[‘enable’] = false
    • redis[‘enable’] = false
    • gitlab_rails[‘db_adapter’] = “postgresql”
    • gitlab_rails[‘db_host’] = “db-vip.example.com”
    • gitlab_rails[‘db_port’] = 5432
    • gitlab_rails[‘db_database’] = “gitlabhq_production”
    • gitlab_rails[‘db_username’] = “gitlab”
    • gitlab_rails[‘db_password’] = “<db_password>”
    • gitlab_rails[‘redis_host’] = “redis-vip.example.com”
    • gitlab_rails[‘redis_port’] = 6379
    • gitlab_rails[‘redis_password’] = “<redis_password>”
    • git_data_dirs({ “default” => { “path” => “/mnt/gitlab/git-data” } })
    • uploads_dir “/mnt/gitlab/uploads”
    • artifacts_dir “/mnt/gitlab/artifacts”
    • lfs_storage_path “/mnt/gitlab/lfs-objects”
    • pages_nginx[‘enable’] = true
  • 应用配置并启动：
    • sudo gitlab-ctl reconfigure
    • sudo gitlab-ctl restart
• 数据与缓存高可用
  • PostgreSQL：部署 主从流复制 或 pg_auto_failover，对外暴露 VIP 给 GitLab；创建数据库与用户：
    • CREATE DATABASE gitlabhq_production;
    • CREATE USER gitlab WITH ENCRYPTED PASSWORD ‘<db_password>’;
    • GRANT ALL PRIVILEGES ON DATABASE gitlabhq_production TO gitlab;
  • Redis：部署 主从 + Sentinel，对外暴露 VIP 与端口 6379；Sentinel 提供故障自动切换与健康检查。
• 共享存储
  • 选择其一：
    • NFS：简单可靠，适合中小规模（注意性能与锁一致性）
    • GlusterFS/CephFS：具备副本/纠删码、横向扩展与更高可用性
  • 将以下目录挂载到共享存储（示例）：
    • /var/opt/gitlab/git-data
    • /var/opt/gitlab/uploads
    • /var/opt/gitlab/artifacts
    • /var/opt/gitlab/lfs-objects
    • /var/opt/gitlab/pages
• 负载均衡与健康检查（HAProxy 示例）
  • 前端：
    • frontend gitlab_http
      • bind *:80
      • bind *:443 ssl crt /etc/ssl/gitlab.pem
      • redirect scheme https if !{ ssl_fc }
      • default_backend gitlab_web
    • backend gitlab_web
      • balance roundrobin
      • option httpchk GET /-/health
      • server web01 gitlab-web-01:80 check inter 2000 rise 2 fall 5
      • server web02 gitlab-web-02:80 check inter 2000 rise 2 fall 5
  • 可选：SSH 转发（保持 22 端口直连每台 Web 或使用 TCP 转发）
• 故障转移要点
  • DB/Redis 切换由 VIP + 流复制/Sentinel 自动完成
  • Web 节点无状态，LB 健康检查自动摘除异常实例
  • 存储层异常需优先恢复副本或切换至健康后端

三 方案二 Docker Compose 多实例（轻量快速）

• 适用：验证环境、中小规模、对 K8s 无依赖的场景
• 架构：多台 Ubuntu 主机运行 GitLab 容器，前置 HAProxy/Keepalived VIP
• 单节点 docker-compose.yml 示例（每台主机相同，仅主机名与端口映射不同）
  • version: ‘3.8’
  • services:
    • gitlab:
      • image: ‘gitlab/gitlab-ce:latest’
      • hostname: ‘gitlab-web-01.example.com’
      • environment:
        • GITLAB_OMNIBUS_CONFIG: | external_url ‘https://gitlab.example.com’ gitlab_rails[‘gitlab_shell_ssh_port’] = 2222 postgresql[‘enable’] = false redis[‘enable’] = false gitlab_rails[‘db_adapter’] = “postgresql” gitlab_rails[‘db_host’] = “db-vip.example.com” gitlab_rails[‘db_port’] = 5432 gitlab_rails[‘db_database’] = “gitlabhq_production” gitlab_rails[‘db_username’] = “gitlab” gitlab_rails[‘db_password’] = “<db_password>” gitlab_rails[‘redis_host’] = “redis-vip.example.com” gitlab_rails[‘redis_port’] = 6379 gitlab_rails[‘redis_password’] = “<redis_password>”
      • ports:
        • “80:80”
        • “443:443”
        • “2222:22”
      • volumes:
        • /srv/gitlab/config:/etc/gitlab
        • /srv/gitlab/logs:/var/log/gitlab
        • /srv/gitlab/data:/var/opt/gitlab
        • /mnt/gitlab/repositories:/var/opt/gitlab/git-data
        • /mnt/gitlab/uploads:/var/opt/gitlab/uploads
        • /mnt/gitlab/artifacts:/var/opt/gitlab/artifacts
        • /mnt/gitlab/lfs-objects:/var/opt/gitlab/lfs-objects
      • restart: always
• 运行与扩展
  • 每台主机：docker-compose up -d
  • 前置 HAProxy + Keepalived VIP 统一入口，健康检查指向各实例 80/443
  • 共享目录（repositories/uploads/artifacts/lfs）建议使用 NFS/GlusterFS/CephFS 挂载到容器内相同路径

四 方案三 Kubernetes Helm Chart（云原生与大规模）

• 前置：Ubuntu 节点上部署 Kubernetes 集群（如 kubeadm），并安装 Helm
• 部署步骤
  • 添加仓库并安装：
    • helm repo add gitlab https://charts.gitlab.io
    • helm repo update
    • kubectl create namespace gitlab
    • helm install gitlab gitlab/gitlab --namespace gitlab -f values.yaml
  • 关键 values.yaml 指引（示例）
    • global:
      • hosts:
        • domain: gitlab.example.com
      • ingress:
        • tls:
          • enabled: true
          • secretName: gitlab-tls
      • postgresql:
        • enabled: false
        • host: postgresql-ha.default.svc.cluster.local
        • password:
          • secret: gitlab-postgresql-password
          • key: password
      • redis:
        • enabled: false
        • host: redis-ha.default.svc.cluster.local
        • password:
          • secret: gitlab-redis-password
          • key: password
    • gitlab:
      • webservice:
        • replicas: 3
      • sidekiq:
        • replicas: 2
      • gitlab-shell:
        • replicas: 2
      • registry:
        • enabled: true
    • minio: # 对象存储（可选，用于 LFS/Artifacts/Registry 等）
      • enabled: true
• 获取初始管理员密码
  • kubectl get secret gitlab-gitlab-initial-root-password -n gitlab -ojsonpath=“{.data.password}” | base64 --decode
• 优势与注意
  • 弹性伸缩、滚动升级、自动恢复
  • 需正确配置 外部 DB/Redis/对象存储，并按需开启 Prometheus/Alertmanager 与备份（如 Velero）

五 运维与高可用要点

• 存储与一致性
  • repositories 等共享目录务必使用 NFS/GlusterFS/CephFS 等共享存储，避免单机数据孤岛
  • 定期校验挂载点与副本健康（如 Gluster volume status、df -h）
• 数据库与缓存
  • PostgreSQL 建议 主从流复制 或 pg_auto_failover；Redis 建议 主从 + Sentinel
  • 为 GitLab 创建专用数据库与用户，并限制权限
• 负载均衡与健康检查
  • HTTP 健康检查建议访问 /-/health；SSH 建议 TCP 转发或每台主机开放 22
  • 健康检查失败阈值与超时需结合实例启动时间合理设置
• 备份与恢复
  • Omnibus：/opt/gitlab/bin/gitlab-backup create（可配合 SKIP 参数）
  • K8s：使用 Velero 或对象存储直传方案
  • 定期演练恢复流程，验证 RPO/RTO
• 安全与合规
  • 启用 HTTPS/TLS，限制 22/80/443 访问，禁用不必要端口
  • 使用 强密码/Secret 管理，开启 2FA、审计日志与备份加密
• 监控与告警
  • 启用 Prometheus/Alertmanager 监控关键指标（HTTP 5xx、Sidekiq 队列、DB/Redis 延迟等）
  • 设置 节点/Pod/存储 容量阈值告警

以上方案可按团队规模与运维能力选择落地：传统环境优先 Omnibus 多节点，轻量验证选 Docker Compose，云原生与大规模选 Kubernetes Helm。无论哪种方案，核心在于将 数据库、缓存、存储 外置并实现 自动故障转移，前端通过 VIP/LB 提供统一入口，最终达成高可用与可扩展的目标。