version: '1.0'
services:
gitlab:
image: gitlab/gitlab-ce:16.11.10-ce.0
container_name: gitlab
restart: always
hostname: '172.16.9.15'
environment:
GITLAB_OMNIBUS_CONFIG: |
external_url 'http://172.16.9.15'
gitlab_rails['gitlab_shell_ssh_port'] = 8822
ports:
-
"80:80"
-
"443:443"
-
"8822:22"
volumes:
-
"/srv/gitlab/config:/etc/gitlab"
-
"/srv/gitlab/logs:/var/log/gitlab"
-
"/srv/gitlab/data:/var/opt/gitlab"
shm_size: '256m'
在 GitLab 迁移时,这两个重要的文件都需要覆盖
/etc/gitlab/gitlab-secrets.json:必须覆盖,绝不能省略。/etc/gitlab/gitlab.rb:强烈建议覆盖(然后再按新环境微调,如果抛弃以前的配置,也可以)。
下面详细解释原因和正确做法。
1. gitlab-secrets.json ------ 必须覆盖
这个文件保存着 GitLab 所有加密数据的主密钥,包括:
- 数据库中加密的字段(如 CI/CD 变量、自定义凭证)
- 用户的 OTP 二次验证密钥
- 集成 webhook 的 secret token
- 加密的 Runner 认证信息等
如果不覆盖会发生什么?
新实例会生成一套全新的密钥,导致所有从旧实例备份中恢复的加密数据永久无法解密。具体表现有:
- 所有已配置的 CI/CD 变量全部失效
- 用户无法通过二次验证登录
- Webhook、Integrations 需要重新配置
- 部分 Runner 需要重新注册
正确做法:
直接将旧服务器的 /etc/gitlab/gitlab-secrets.json 复制到新服务器的相同路径,并确保权限正确(通常 root:root,400 或 600)。这是 GitLab 官方备份恢复流程中的强制步骤。
2. gitlab.rb ------ 强烈建议覆盖
这是 GitLab 的主配置文件,包含外部 URL、端口、数据库连接、SMTP 邮件、备份策略等所有自定义设置。
不建议直接在新环境用全新默认配置,因为:
- 你之前调优过的参数(如 Unicorn/Puma worker 数、内存限制)都会丢失
- 邮件、LDAP、对象存储等集成可能需要重新调试
- 可能导致服务行为与旧实例不一致,增加排错成本
正确做法:
- 将旧服务器的
gitlab.rb复制到新服务器。 - 先根据新环境修改必要项 ,如:
external_url(如果域名或 IP 变了)- 与主机名、IP 绑定相关的配置
- 如果数据库、Redis 等外部服务地址有变,也要同步修改
- 修改完成后,执行
sudo gitlab-ctl reconfigure让配置生效。 - 最后再执行备份恢复(
gitlab-backup restore)。
标准迁移流程摘要
- 将旧服务器的
/etc/gitlab/gitlab-secrets.json和/etc/gitlab/gitlab.rb复制到新服务器的相同路径。 - 按需修改
gitlab.rb(重点检查 URL、外部依赖地址)。 - 运行
sudo gitlab-ctl reconfigure。 - 将备份文件(通常是
/var/opt/gitlab/backups/下的 tar 包)复制到新服务器相同目录。 - 执行恢复命令:
sudo gitlab-backup restore BACKUP=时间戳。 - 重启并检查服务:
sudo gitlab-ctl restart,然后验证登录和关键功能。
在执行恢复前,必须停止连接数据库的服务:
sudo gitlab-ctl stop puma
sudo gitlab-ctl stop sidekiq
我测试的时候不能sudo gitlab-ctl stop,否则报错误找不到数据库之类的。
gitlab-backup restore BACKUP=1750765308_2025_06_24_16.7.6
记得后面只是日期,而不是整个备份文件的全名。