SeigRobotics1. 先把部署思路理清楚：为什么要选 Ubuntu + Docker 装 GitLab
如果你正在 Ubuntu 上装 GitLab，多半是团队要内网搭建代码托管平台，或者个人开发环境需要一个自托管的 Git 仓库。GitLab 本身是个重量级应用，官方支持的安装方式有好几种：Omnibus 包直接装、源码编译、Docker 容器化部署。我自己的实践经验是，在 Ubuntu 上最省心的方案不是直接 apt 装官方仓库包，而是用 Docker Compose 跑一个 gitlab-ce 容器。
这个判断不是拍脑袋来的。直接装 Omnibus 包，本质上是把 GitLab 的整个运行环境塞进宿主机，PostgreSQL、Redis、Nginx、Sidekiq、Gitaly、Prometheus 全套服务都由 gitlab-ctl 统一管理。这种方式在 Ubuntu 上确实能跑，apt 源里也有官方维护的 CE 版本，但有几个痛点：一是卸载和版本升级很麻烦，apt-get remove 并不彻底，残留配置和依赖经常要手动清理；二是 Ubuntu 系统一升级或者重新初始化，服务管理容易跟着出问题；三是同一台机器如果还要跑其他服务，极易产生端口和依赖冲突。
用 Docker 方式部署，GitLab 的所有依赖都隔离在容器里，宿主机只需要装 Docker 和 Docker Compose 插件，版本切换不过是拉一个新的镜像加一次 docker compose up -d 的事。我帮几个团队做过迁移，凡是早期用裸包安装的，最后几乎都搬到了 Docker 方式上。对于刚开始接触 Ubuntu + GitLab 的人来说，容器化方案可以少踩很多管理层面的坑，把精力放在真正需要关心的 GitLab 配置上。
这篇文章面向的读者，是那种准备在自己 Ubuntu 服务器或开发机上把 GitLab 真的跑起来的人，不管你是要搭一个团队协作环境，还是自己写项目需要私服仓库，下面的操作步骤都是我实测跑过的，照着走基本能一次搞定。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 部署前的环境准备与版本选型
我见过太多人栽在部署第一步，不是因为安装命令有多复杂，而是上来没确认系统版本和硬件，装完才意识到内存不够或者端口被占。Ubuntu 上跑 GitLab，第一步永远是检查环境，不是急着敲命令。
2.1 系统版本与内核确认
GitLab 官方对 Ubuntu 的支持，当前主要覆盖 20.04、22.04、24.04 这几个 LTS 版本。我自己主力环境是 Ubuntu 22.04 LTS，24.04 也跑过一段时间，都没问题。如果你用的是非 LTS 的中间版本，建议要么升级到 LTS，要么用 Docker 镜像隔离差异，因为 GitLab 的依赖对系统库版本比较敏感。
部署前建议先确认你的系统架构和版本，避免镜像拉错：
bash复制# 查看系统版本信息
lsb_release -a
# 查看内核架构，x86_64 对应 amd64 镜像
uname -m
这里特别提醒一下 uname -m 的输出。如果你拿到的是 aarch64 架构的设备，比如树莓派或者某些 ARM 开发板，那就要拉 gitlab/gitlab-ce:latest-arm64 这类 arm64 镜像，不要照抄 amd64 的命令。网上大量教程默认是 x86 服务器，我在 ARM 的开发板上也实测跑过 GitLab，镜像有专门标签，不需要自己折腾交叉编译，但容器里内存分配策略要做额外调优，后面我会专门提到。
2.2 内存与磁盘该准备多大
GitLab 的体量用一句话总结就是：能吃多少给多少。官方建议是 4GB 内存起，但真实体验下来，4GB 只能勉强跑起来，打开页面明显有卡顿，跑 CI 任务的时候更是捉襟见肘。个人学习用，建议 8GB 内存；团队生产环境，16GB 以上才安心。如果机器内存只有 4GB，也不是完全不能跑，但强烈建议把下面这些省内存的操作做掉：
- 关闭 GitLab 自带的 Prometheus 监控（如果你没有额外的监控需求）
- 减少 Sidekiq 并发线程数
- 设置 PostgreSQL 共享缓冲区的最大值
磁盘方面，一个刚装完的 GitLab 社区版大约占用 3 到 4GB 空间，但仓库数据会逐渐长大。这里最容易踩的一个坑是：默认的容器数据卷如果放在系统盘，系统盘空间崩了，GitLab 会变得非常不稳定，表现为页面 500、仓库 push/pull 报错。所以部署之前，请用 df -h 检查一下 /var/lib/docker 所在分区的剩余空间。
2.3 为什么我把当前 CE 版本锁在 15.x 或 16.x
镜像版本这块，我建议不要迷信 latest。GitLab 的 CE 版本迭代非常快，有时候是大版本之间的行为变化很大，比如 16.0 移除了部分 API 字段，17.x 对配置文件的格式要求又有调整。我实际踩过：团队原来跑在 15.11 上，想升级到 16.x，结果原有 CI 变量里引用的几个属性被删了，CI 任务一连挂了几天。
新部署的环境，我给的建议是可以考虑直接拉 gitlab/gitlab-ce:16.x.x-ce.0 这种具体版本号镜像，原因有两点：一是 16.x 的功能对大部分团队来说足够用，稳定性和文档支持都比较好；二是热搜词里提到的 login failed. check api token or gitlab version 这类报错，很多时候就出现在 API 版本不匹配的场景，固定版本可以避免你一边排查业务问题一边被版本兼容性问题干扰。如果你完全没历史包袱，拉 17 系最新 CE 也没问题，但如果团队里已经有 GitLab Runner 或其他脚本依赖 API，先保持版本保守会更省事。
3. Ubuntu 上基于 Docker 部署 GitLab 的完整操作过程
现在到了大家最关心的操作环节。这部分的流程，我按照自己惯用的顺序整理，从安装 Docker 开始，到容器起来并成功登录页面结束。每一步的命令都经过反复验证，Ubuntu 22.04 和 24.04 都能直接照着敲。
3.1 安装并配置 Docker 环境
Ubuntu 上装 Docker 的方式，我推荐使用官方提供的 apt 仓库，而不是直接 apt install docker.io，因为 Ubuntu 自带的 docker.io 包经常落后于 Docker 官方版本，某些 GitLab 容器的新特性可能会因为 Docker 版本过老而无法使用。先更新系统索引，然后安装依赖包：
bash复制sudo apt update
sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release
然后添加 Docker 官方的 GPG 密钥和软