一、背景与需求分析

在企业级DevOps环境中，GitLab作为核心代码管理平台，其域名稳定性直接影响开发效率。本次域名修改源于三方面需求：

品牌统一性：原域名gitlab.old-domain.com与公司新品牌战略不符，需替换为code.company-domain.com
安全合规：原域名未配置HTTPS，存在中间人攻击风险
负载均衡优化：新域名可接入CDN网络，提升全球访问速度

修改前需完成风险评估：

服务中断时间预估：≤15分钟（低峰期操作）
依赖系统检查：Jenkins、SonarQube等工具的GitLab Webhook配置
数据备份验证：确认/var/opt/gitlab/backups/目录存在7日内完整备份

二、技术实施步骤

1. 基础环境准备

# 确认GitLab版本（需≥13.0支持动态域名更新）
sudo gitlab-rake gitlab:env:info | grep "GitLab version"
# 准备SSL证书（以Let's Encrypt为例）
sudo certbot certonly --manual -d code.company-domain.com \
  --preferred-challenges dns \
  --server https://acme-v02.api.letsencrypt.org/directory

将生成的fullchain.pem和privkey.pem文件复制至/etc/gitlab/ssl/目录，权限设置为600。

2. 核心配置修改

（1）主配置文件调整

编辑/etc/gitlab/gitlab.rb，重点修改以下参数：

# 外部URL配置（关键修改点）
external_url "https://code.company-domain.com"
# Nginx监听配置
nginx['listen_addresses'] = ['*']
nginx['ssl_certificate'] = "/etc/gitlab/ssl/fullchain.pem"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/privkey.pem"
# 邮件服务域名同步更新
gitlab_rails['gitlab_email_from'] = "gitlab@company-domain.com"

（2）数据库迁移准备

-- 检查是否存在硬编码的旧域名（PostgreSQL示例）
SELECT * FROM application_settings WHERE value LIKE '%old-domain%';
-- 如存在需手动更新：
UPDATE application_settings SET value = replace(value, 'old-domain', 'company-domain') 
WHERE value LIKE '%old-domain%';

3. 服务重启与验证

执行配置重载前，建议先检查配置语法：

sudo gitlab-ctl check-config
# 预期输出：Configuration files check passed
sudo gitlab-ctl reconfigure
# 观察输出日志，确认无ERROR级别信息
sudo gitlab-ctl restart

重启后验证项：

服务可达性：

curl -I https://code.company-domain.com/users/sign_in
# 应返回200状态码及正确的Server头信息

证书有效性：

openssl s_client -connect code.company-domain.com:443 -showcerts </dev/null 2>/dev/null | openssl x509 -noout -dates
# 检查有效期是否覆盖未来90天

功能完整性：
- 创建测试项目并推送代码
- 验证Webhook触发是否正常
- 检查CI/CD流水线能否正确拉取代码

三、常见问题处理

1. 502 Bad Gateway错误

原因：Nginx与Unicorn进程通信异常
解决方案：

# 检查进程状态
sudo gitlab-ctl tail nginx
sudo gitlab-ctl tail unicorn
# 常见修复命令
sudo gitlab-ctl hup nginx  # 优雅重启Nginx
sudo gitlab-ctl restart unicorn

2. 邮件发送失败

现象：用户注册邮件未送达
排查步骤：

检查Sidekiq队列：

sudo gitlab-rails runner "puts Sidekiq::Queue.new('mailer').size"

验证SMTP配置：

# 在gitlab.rb中确认
gitlab_rails['smtp_domain'] = 'company-domain.com'

3. Git操作超时

优化方案：

调整Git超时设置：

gitlab_rails['git_timeout'] = 600  # 默认180秒

优化SSH配置：

# 在/etc/ssh/sshd_config中添加
ClientAliveInterval 60
ClientAliveCountMax 3

四、最佳实践建议

灰度发布策略：
- 先在内网环境测试（使用hosts文件绑定）
- 逐步开放至测试团队→开发团队→全员

监控体系搭建：

# Prometheus监控配置示例
- job_name: 'gitlab'
  static_configs:
    - targets: ['code.company-domain.com:9168']  # GitLab Exporter端口

文档更新清单：
- 更新Confluence中的GitLab访问指南
- 修改Jenkinsfile中的git仓库地址
- 通知安全团队更新防火墙白名单

五、总结与反思

本次域名修改历时3小时27分钟，实际服务中断仅9分钟（发生在Nginx证书更新阶段）。关键成功因素包括：

提前72小时完成DNS的TTL调整（从3600秒降至300秒）
采用蓝绿部署方式，新旧域名并行运行2小时
准备详细的回滚方案（包含数据库回滚脚本）

改进点：

自动化测试覆盖率不足，下次应增加Selenium Web测试
变更通知邮件未分类发送，导致非技术人员收到技术细节

通过此次实践，团队积累了宝贵的域名变更经验，后续可封装为Ansible Playbook实现自动化操作。建议每季度进行一次域名健康检查，包括证书有效期监控、DNS解析一致性验证等。

记一次GitLab域名修改全流程实践