用docker-compose部署gitlab ce是最稳、最易维护的方式，尤其适合中小团队；不推荐直接yum/apt安装，因其易与系统服务冲突、升级困难、配置混乱。

直接上结论：用 docker-compose 部署 GitLab CE 是目前最稳、最易维护的方式，尤其适合中小团队；不推荐直接在宿主机用 yum/apt 安装，容易和系统服务冲突、升级困难、配置路径混乱。

为什么选 docker-compose 而不是包管理器安装

GitLab 本身是个重型 Ruby on Rails + Sidekiq + PostgreSQL + Redis + Nginx 的组合体，直接装进系统会污染环境：

• gitlab-ctl reconfigure 会接管整个系统级的 systemd、postfix、nginx 配置，和你已有的邮件或 Web 服务打架
• 升级时若版本跨度大（比如从 15.x 升到 16.x），gitlab-ctl upgrade 常卡住或丢数据，而容器可一键回滚镜像
• 默认监听 22 端口，但很多云服务器（如阿里云）默认屏蔽该端口，还得额外配 SSH 映射；docker-compose 可直接映射到 2222，绕过限制
• /etc/gitlab/gitlab.rb 是 Ruby 语法配置文件，写错一个括号就 reconfigure 失败，且错误提示极不友好；而 environment.GITLAB_OMNIBUS_CONFIG 是纯字符串拼接，调试更直观

docker-compose.yml 关键字段必须改什么

以下字段不改，GitLab 启动后根本无法访问或推送代码：

Gitcrawl

GitHub 归档：议题/PR 搜索、同步时效性、重复议题聚类、`gh-shim` PR 状态、以及 `Gitcrawl` 仓库相关工作。

下载

• external_url 必须填你实际能访问的地址，比如 'http://gitlab.your-company.com' 或 'http://192.168.1.100'；填 localhost 或 127.0.0.1 会导致 Git 克隆地址生成错（变成 http://localhost/xxx.git）
• gitlab_rails['gitlab_shell_ssh_port'] = 2222 必须显式声明，否则 Git over SSH 默认走容器内 22，但宿主机 22 通常被占，且没暴露
• volumes 三路径必须分开挂载：./gitlab/config:/etc/gitlab（配置）、./gitlab/logs:/var/log/gitlab（日志）、./gitlab/data:/var/opt/gitlab（仓库+数据库）；混挂或少挂一个，重启后项目全丢
• 如果宿主机 80/443 已被占用，别硬抢，直接改 ports 为 '8080:80' 和 '8443:443'，然后在 external_url 里写成 'http://ip:8080'

启动后连不上？先查这三处

常见现象：浏览器打不开页面、git clone 报 Connection refused、SSH 推送超时。按顺序排查：

• 执行 docker ps -a | grep gitlab，确认容器状态是 Up；如果显示 Restarting 或 Exited，立刻跑 docker logs -f gitlab，重点搜 error 和 failed —— 90% 是 shm_size 不够或磁盘满
• 检查宿主机防火墙：sudo ufw status（Ubuntu）或 sudo firewall-cmd --list-ports（CentOS），确保你映射的端口（如 8080）已放行
• 云服务器用户务必去控制台安全组补一条入方向规则：协议 TCP，端口填你映射的宿主机端口（不是容器内端口），源 IP 可设 0.0.0.0/0（测试用）或限定团队 IP 段
• 验证基础服务是否就绪：执行 docker exec -it gitlab gitlab-ctl status，看 nginx、postgresql、redis 是否都是 run；如果 sidekiq 或 gitlab-workhorse 是 down，大概率是内存不足（4GB 是底线，8GB+ 才稳）

团队协作前必须关掉的两个默认开关

刚装好的 GitLab 默认开放注册、默认项目公开，对私有仓库是严重安全隐患：

• 登录后点右上角头像 → Admin Area → Settings → Sign-up restrictions → 关闭 Sign-up enabled，防止陌生人注册账号
• 同一 Settings 页面下拉到 Visibility and access controls → 把 Default project creation level 改成 Private，Default group creation level 也设为 Private
• 顺手把 Account and limit settings 里的 Default projects limit 调高（比如 100），避免开发者建项目时突然被拦
• 别信“等团队用起来再配”，新成员第一次点击 New project 就可能误建公开仓库，泄露代码

真正麻烦的从来不是部署那十几分钟，而是后续权限模型怎么划：Owner / Maintainer / Developer 的边界在哪，MR 是否强制双人审批，CI/CD 流水线能否被普通成员修改——这些得在第一个项目创建前就白纸黑字定下来，不然后期收权比重建仓库还费劲。