云服务器Ubuntu部署GitLab高可用案例分享

在云服务器Ubuntu系统上部署GitLab并实现高可用，能有效保障代码管理的稳定性。我曾接触过一个创业团队，因GitLab单点故障导致三天代码成果丢失，最终花了一周时间恢复数据。这让我深刻意识到，高可用部署不是“加分项”，而是“必选项”。下面结合实际案例，分享从前期准备到运维监控的全流程经验。

前期准备：硬件与环境的“地基”

部署前的准备工作像盖房子打地基——看似基础，却决定了整个系统的“抗风险能力”。首先是云服务器的选择：建议搭配Ubuntu 20.04 LTS系统，这个长期支持版本社区活跃，遇到问题能快速找到解决方案。硬件配置方面，我们团队实测发现，8GB内存+4核至强CPU+200GB高效云盘是起步配置——内存不足会导致CI/CD流水线卡顿，磁盘空间小则可能因日志堆积影响服务。

域名和SSL证书也不能忽视。我们为GitLab绑定了“git.example.com”域名，并通过Let’s Encrypt申请了免费SSL证书。别小看这一步，启用HTTPS后，团队成员从公网访问时数据加密传输，曾有次排查发现，未加密的测试环境被截获过一次临时分支代码，虽未造成损失，但足以敲响警钟。

安装与基础配置：从“能用”到“稳定用”

安装阶段需要耐心。首先更新系统包，执行这两条命令：

sudo apt update
sudo apt upgrade -y

完成后添加GitLab官方仓库，这里有个小技巧：直接用curl命令导入脚本更高效：

curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash

接着安装GitLab企业版（GitLab EE），命令是“sudo apt install gitlab-ee”。安装过程中会提示设置外部URL，这里要填之前准备的“https://git.example.com”。曾有同事手滑写成了IP地址，结果后续配置Nginx反向代理时折腾了半天才修正。

高可用架构：让服务“不打烊”

单点部署的GitLab就像单车道公路，一旦“堵车”（服务崩溃）或“事故”（硬件故障），整个团队的开发都会停摆。我们采用的是“负载均衡+多节点”架构：主节点和备用节点部署在不同可用区的云服务器上，通过HAProxy做负载均衡。HAProxy的配置文件里，后端节点设置为两个GitLab实例的内网IP，权重各设为50。这样即使一个节点宕机，负载均衡器会自动将请求转发到另一个节点，实测切换时间不超过30秒。

前端用Nginx做反向代理，关键配置如下（/etc/nginx/sites-available/gitlab.conf）：

server {
    listen 443 ssl;
    server_name git.example.com;
    ssl_certificate /etc/letsencrypt/live/git.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/git.example.com/privkey.pem;

    location / {
        proxy_pass http://haproxy_backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

这里要注意，Nginx和HAProxy都部署在独立的云服务器上，避免单点故障。

数据安全：备份与存储的“双保险”

代码是开发团队的“命根子”，数据存储和备份必须万无一失。我们选择Ceph分布式存储作为GitLab的主存储，它支持自动副本机制，数据会同步存储在3个不同的存储节点上。曾有次一个存储节点硬盘损坏，Ceph自动从副本恢复数据，全程无感知。

备份方面，GitLab自带的备份工具足够用。设置定时任务每天凌晨2点自动备份：

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

备份文件会存到Ceph的备份专用桶里，每周还会手动下载一次到本地归档——多一层物理隔离，心里更踏实。

监控与运维：让问题“提前举手”

系统跑起来不是终点，持续监控才能防患于未然。我们用Prometheus+Grafana搭建了监控平台，重点关注三个指标：

• CPU/内存使用率：超过70%时触发预警，曾因CI流水线同时运行多个任务，内存使用率飙到85%，及时扩容了云服务器内存；


• API请求延迟：超过500ms时检查Nginx或HAProxy配置，有次发现是负载均衡器规则写错，导致部分请求绕远路；


• 备份任务状态：每天检查备份日志，确保“Backup successful”字样出现，否则人工干预。

此外，每天早上花10分钟查看/var/log/gitlab/下的日志，重点看unicorn（Web服务）和sidekiq（后台任务）的日志，能提前发现慢查询或任务堆积问题。

常见问题与解决：实战踩过的“坑”

部署过程中遇到的问题，总结下来有两个高频场景：
- 502 Bad Gateway：有次团队反馈无法访问GitLab，检查Nginx日志发现502错误。排查后是HAProxy后端节点的GitLab服务未启动，用“sudo gitlab-ctl start”启动服务后恢复。建议定期用“sudo gitlab-ctl status”检查各组件状态（如nginx、postgresql、redis）。
- 备份失败：曾有备份任务连续两天失败，查看日志发现是Ceph存储桶权限不足。修改存储桶的读写权限后，备份任务恢复正常。

在云服务器Ubuntu上部署GitLab高可用，本质是构建一套“抗风险系统”——从硬件选型到数据备份，从架构设计到实时监控，每个环节都在回答“如果某一步出问题，系统能否自动应对”。这套方案我们已稳定运行8个月，经历过一次云服务器硬件故障、两次突发流量高峰，GitLab始终保持可用。对于需要代码协作的团队来说，这或许就是“安全感”最好的注脚。