「日志记录」GitLab 升级后的 HTTPS 配置之坑插图

最近在升级到新版本的 GitLab CE 并尝试配置 HTTPS 访问时,碰到了一件让我哭笑不得的事。GitLab 会自动切换到 443 端口,甚至在没有有效证书的情况下,还会尝试申请 Let’s Encrypt 的证书。这也太离谱了吧!

(PS:具体哪个版本开始这样的我也不清楚,我用的是 17.0.0。)

GitLab 的本意是,既然你修改了 external_url 包含 HTTPS,那么它就会自动化切换到 HTTPS 模式。但问题是,external_url 顾名思义只是外部 URL,GitLab 在没有配置 ACME 的情况下去申请 Let’s Encrypt 证书铁定会失败。这样一来,配置就无法通过,简直是自找麻烦。

「日志记录」GitLab 升级后的 HTTPS 配置之坑插图1

作为运维,在部署 GitLab 走 HTTPS 的时候,为了证书的统一管理,通常会在外面垫一层负载均衡或者反向代理。我们需要的是 GitLab 乖乖监听 80 端口,同时在仓库的 URL 显示中展示最终代理的 URL。

要解决这个问题,需要以下几个步骤。老版本只需要改 external_url,现在搞得很麻烦。要是运维稍微不熟练,这玩意根本没法用了。

关闭 Let’s Encrypt 申请

   vi /etc/gitlab/gitlab.rb
   # 找到并修改配置
   letsencrypt['enable'] = false

修改 external_url 的同时,强行指定 GitLab 内部的 Nginx 配置

   external_url='https://xxx.com'
   nginx['listen_port'] = 80
   nginx['listen_https'] = false

重新配置并重启

   gitlab-ctl reconfigure
   gitlab-ctl restart

搞定!我必须得吐槽一下 GitLab 团队,但凡是个正常的架构设计不会这样搞。要是让我来设计,我会这样做:

  1. external_url 的配置随便写都不会影响内部 Nginx,仅用于 Web 界面上显示仓库 URL。
  2. Nginx 的配置独立化,不要集成到 gitlab.rb,单独留一个配置文件。修改后我们只需要重启 Nginx,而不是重新配置整个 GitLab。(PS:重新配置这里其实还有一个大坑,要是你用 Docker 运行会更麻烦,不展开了。)
  3. ACME 配置默认关闭,在 Web 界面的管理后台留一个配置菜单供用户编辑,输出证书即可。需要的用户再回到 GitLab 的 Nginx 改配置。

这有那么难吗?