新版GITLAB的external_url巨坑
如果使用新版本的gitlab-ce同时修改external_url使用https进行访问那么gitlab的服务会自动切换至443端口，并且如果没有提供有效的证书它甚至会去申请Let’s Encrypt的甚至，这尼玛就离谱。
（PS：具体哪个版本开始就这样了我也不知道，我使用的17.0.0）
它的本意是你既然修改了external_url包含了https那么它就会自动化将整个GIT切换至https模式，但是这个external_url的英文本意就是外部url，卧槽在完全没有配置acme的情况下跑去申请Let’s Encrypt铁定会失败，这样一来配置就没法通过，简直了，拖了裤子放屁。因为但凡是个运维在部署gitlab走https的时候为了证书统一化管理肯定都是在外面垫了一层负载均衡或者反向代理，我们需要的就是gitlat老实去监听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团队，但凡是个脑子正常的架构设计不会去这样设计，要是我来搞我会这么做：
external_url的配置随便写都不会影响内部nginx，仅仅用于web界面上显示仓库url- nginx的配置独立化，不要集成到
gitlab.rb，单独留一个配置文件放出来，修改之后我们只需要重启nginx就行而不是将整个gitlab重新配置（PS：重新配置这里其实还有一个大坑，要是你用docker运行会更伤，不展开了） - acme配置默认关闭，在web界面的管理后台留一个配置菜单给用户编辑，输出证书就行了，需要的自己再回到gitlab的nginx改配置
这他妈很难吗？