昨天到今天,我终于解决了一个脑残的问题!!

事情是这样子的,我自己搭建了 GitLab ,并导入了我在 GitHub 所有的仓库,并打算未来就在这里提交我的代码了。一方面是因为 GitHub 实在是太慢了,目前使用 iPad 代理切换不智能;另一方面是我想要搭建自己的一套 Git Hosting + CI/CD 系统。搭建过程很顺利、导入过程也十分顺利,但是到了 CI/CD 这里就出了问题,我想要通过 GitLab Runner 编译我的 MKDocs 页面并自动部署到 GitLab Pages,但我被一个错误坑了整整两天:

错误日志如下:


$ mv site/ public
$ du -sh public
6.2M    public
Uploading artifacts...
public: found 185 matching files                   
ERROR: Uploading artifacts to coordinator... too large archive  id=102 responseStatus=413 Request Entity Too Large status=413 Request Entity Too Large token=DwkMS97K
FATAL: too large                                   
ERROR: Job failed: exit code 1

大概是说提交体积过大引发接受端 413 错误,可是这是怎么回事呢?于是我使用 ERROR: Uploading artifacts to coordinator... too large archive 搜索了 BING cn, Google, BaiDu, 最终有两种方案:

1.

In your gitlab, go to Settings > Continuous Integration and Deployment > Maximum artifacts size (MB) and set it to the desired value. The default is 100MB. 

2.

In the gitlab.rb file, mine at /etc/gitlab/gitlab.rb, set or uncomment the following line.

nginx['client_max_body_size'] = '250m' 

尝试后 终无果。

终于在今天晚上,今天晚上,再错误中挣扎了 48 小时后,突然灵光一现,是反代的 nginx 设置错误!!!

我的 GitLab 服务器配置在一台裸金属服务器内部的虚拟机上,没有为它分配外网 IP ,为了使用域名解析,我在宿主机上使用反向代理将域名请求反向代理到内网 IP 上,从而实现了外网访问 GitLab ,但问题就出在这个反代的服务器上了,我思前想后找遍了 GitLab 的配置文件就是没有往它身上想。终于今天我打算使用境外服务器 Runner 配置一下,拉取代码的时候我突然意识到这个问题。

修改后完成,在经历了100多次尝试后,我终于找到了问题所在!!!

好了好了,这件事情带给我几点启示:

  • 在实践过程中可能会遇到很多奇葩问题,且并不是所有问题都是“讲理的”
  • 遇到问题别慌,想办法,理思路,实在解决不了放一放,别钻牛角尖

收工睡觉,我终于能好好睡个觉了。本来想着随便弄一弄,没想到一下子弄这么久,教训还是挺实用的,正好可以用于研究生入学考试,遇到问题别慌,用自己的脑子理性思考!

宋天伦
2019.12.1

最后修改:2019 年 12 月 01 日
如果觉得我的文章对你有用,请随意赞赏