.jpg?table=block&id=30052c4c-a1ae-819c-99ec-fe08ef355808&t=30052c4c-a1ae-819c-99ec-fe08ef355808)
type
Post
status
Published
date
Feb 12, 2022 21:14
slug
summary
本文介绍如何使用 Docker 在内网快速搭建 GitLab CE 自建实例。从镜像拉取、容器启动到 external_url 配置，解决项目地址使用容器 hostname 的问题；详解数据持久化三要素（config/data/logs）与异机备份策略（rsync + 定时任务）；对比单机灾备、双机热备、多节点 HA 三种高可用方案的成本与适用场景；提供管理员密码重置、端口冲突、内存不足等常见问题的避坑清单，适合个人与小团队快速落地。
tags
Docker
Infrastructure
Git
category
DevOps
icon
password
wordCount
1821
为什么要自建 GitLab：
在团队协作或个人项目管理中，GitLab 不只是代码仓库，还能把 代码托管、权限管理、Issue、Wiki、CI/CD 等能力整合到一个平台里。
选择自建 GitLab（Self-Managed）通常有这些目的：
- 内网可用：在公司内网、实验室网络、或不方便访问外网的环境里，也能稳定使用代码托管与协作能力。
- 数据可控：代码与制品保存在自己的服务器上，便于满足合规、审计、数据安全等要求。
- 统一协作入口：用一个系统管理项目、成员权限、Merge Request 流程，以及代码评审记录。
- 扩展 DevOps 能力：后续可以接入 Runner，实现自动构建、自动测试、自动部署。
本文使用 Docker 快速部署 GitLab CE，并记录关键配置与常见坑，确保“能跑起来、能访问、地址正确、数据不丢”。
实验环境（含软件依赖）
- 操作系统：Deepin OS 20 社区版
- Docker：19.03.8（建议使用与本文一致或更高的稳定版本）
- 建议执行
docker version确认客户端与服务端版本 - 确认 Docker 服务已启动：
systemctl status docker
- 网络要求
- 能访问 Docker Hub（若网络受限，建议提前配置镜像加速）
- GitLab 需要稳定的内网 IP 或域名（用于生成项目克隆地址）
安装 GitLab
- 拉取 GitLab 镜像
gitlab-ce为社区稳定版，默认会拉取最新标签。
- 启动 GitLab 容器
-d：后台运行-p：端口映射（宿主机端口:容器端口）--name：容器名称--restart always：Docker 重启后自动拉起容器-v：挂载目录（配置、日志、数据持久化）
参数说明：
运行成功后会输出一串字符串，为容器 ID。
配置 GitLab（解决项目 URL 使用容器 hostname 的问题）
GitLab 在生成项目访问地址时，可能会默认使用容器的 hostname（通常就是容器 ID）。作为服务端，我们通常希望对外暴露一个固定的访问地址，因此需要修改
gitlab.rb。- 获取宿主机 IP
- Windows：
ipconfig - Linux：
ifconfig或ip a
- 编辑配置文件
宿主机路径：
/home/gitlab/config/gitlab.rb- 配置对外访问地址与端口
按实际 IP 和端口替换以下内容：
如果你希望通过域名访问（更推荐），可以将192.168.1.231替换为域名，并在 DNS 或 hosts 中做好解析。
- 重启容器使配置生效
重置管理员（root）密码
- 进入 GitLab 容器
- 进入 Rails 控制台（生产环境）
- 找到 root 用户（通常 id 为 1）
- 设置新密码并保存
请将示例密码
secret_pass 替换为强密码，并注意不要把真实密码提交到笔记或代码仓库。数据灾备（备份与恢复）
备份需要覆盖什么？
对象 | 本文对应路径（宿主机） | 目的 |
配置（config） | /home/gitlab/config | 恢复域名、端口、SMTP、认证等配置 |
数据（data） | /home/gitlab/data | 仓库、附件、LFS、CI 产物等核心资产 |
日志（logs） | /home/gitlab/logs | 排障定位问题（可选但推荐） |
常见备份策略怎么选？
策略 | 成本 | 恢复速度 | 适用场景 |
本机备份（同机同盘） | 低 | 快 | 仅用于临时防误删，不算灾备 |
异机备份（rsync/NAS） | 低-中 | 中 | 个人/小团队最实用，推荐起步方案 |
对象存储备份（S3 兼容） | 中 | 中 | 异地容灾、跨机房，网络稳定时体验好 |
硬性建议： 定期做一次恢复演练（在测试机上恢复），否则备份“可能不可用”。
示例（推荐起步）：异机 rsync + 定时任务
下面以“把备份同步到 NAS 或另一台 Linux 机器”为例。
1）准备备份目录（本机）
2）写一个同步脚本（本机）
保存为：
/usr/local/bin/backup_gitlab_dirs.sh赋权：
3）配置免密 SSH（一次性）
4）加入定时任务（每天 2:30）
加入：
5）简单验证
- 检查日志：
tail -f /var/log/gitlab_backup.log
- 去 NAS/备份机确认目录是否有更新。
高可用（HA）方案（按复杂度递进）
方案 | 核心思路 | 优点 | 缺点 | 适合谁 |
A. 单机 + 灾备（DR） | 单点运行，但异机备份 + 快速重建 | 最简单，投入小，落地快 | 故障期间不可用（需人工恢复） | 个人/小团队（推荐） |
B. 双机热备/冷备（DR） | 准备一台备用机，故障时切换入口 | 恢复更快，风险更低 | 仍需切换流程，维护成本上升 | 对恢复时间有要求的小团队 |
C. 多节点 HA | LB + 多 Web 节点 + 外置 PG/Redis + 共享存储 | 可做到单点故障不中断 | 部署维护复杂，组件多，排障成本高 | 中大型团队/生产高可用要求 |
示例：方案 A（单机 + 灾备）
对 Docker 单机部署来说，最“性价比高”的 HA 其实是 先把 DR 做到位：
- 规范化挂载目录（本文已做：
config/logs/data）
- 异机定时备份（上面的 rsync + cron）
- 预先准备好重建步骤（镜像拉取、docker run 参数、gitlab.rb）
当你能做到“删容器、换机器、靠备份恢复”这件事时，你的 GitLab 就已经具备非常强的抗风险能力了。
常见坑与注意事项
- 首次启动很慢：第一次启动会初始化配置与数据库，可能需要几分钟。可以用
docker logs -f gitlab观察进度。
- 端口冲突：宿主机若已有 Nginx/Apache 占用 80/443，会导致容器启动失败或访问异常。可改用其他端口映射，例如
-p 8080:80 -p 8443:443。
- SSH 克隆端口要一致：本文将容器 22 映射到宿主机 222，所以克隆地址需要带上
:222，并确保防火墙放行。
- 内存不足导致 502/卡死：GitLab 对资源要求较高，内存偏小的机器容易出现启动失败、页面 502 等问题。建议至少 4GB 内存（更推荐 8GB+）。
- 数据一定要做持久化：务必保留
config/logs/data三个挂载目录，否则容器删除后数据会丢。
- external_url 配置要正确：若访问地址变更（IP 改了或换域名），记得同步更新
gitlab.rb并重启，否则项目 URL、回调地址等可能异常。