升级到新版gitlab-ce后,所有runner都失效了,于是升级runners后再次register,此时,由于刚刚为gitlab-ce服务器启用了我们的通配符证书(就等8.17出来后的pages功能了),于是runner们都注册不了了:

# gitlab-ci-multi-runner register

Running in system-mode.                            

                                                   

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):

https://git.xxxxx.net/ci

Please enter the gitlab-ci token for this runner:

FvgXX_XXXXXXXXX_XXFY

Please enter the gitlab-ci description for this runner:

[sw0bak00]: 

Please enter the gitlab-ci tags for this runner (comma separated):

ERROR: Registering runner... failed                 runner=FvgJZ_Jf status=couldn't execute POST against https://git.xxxxx.net/ci/api/v1/runners/register.json: Post https://git.xxxxx.net/ci/api/v1/runners/register.json: x509: certificate signed by unknown authority

PANIC: Failed to register this runner. Perhaps you are having network problems

百思不得其解。

在参考了gitlab issues后,发觉我遇到的问题竟然木有人遇到过!

我们总是这么独特么?

今天突然想到了一个途径,于是进入runner服务器找配置,最后顺利解决问题的方法是:

替换/etc/gitlab-runner/certs/中拉取的不正确的证书为我们的通配符证书完整的bundle crt,也就是嵌入了intermediet ca以及root ca的那一份,接着“restart gitlab-runner”,现在再次注册就顺利过了。如果/etc/gitlab-runner/certs/还没有拉取到哪怕是不正确的证书,怎么办?同样将bundle crt复制进去,注意为 ${gitlab-server-fqdn}.crt 这个名字就行了。

所以这个思路的核心是:

gitlab-ci-multi-runner在查询gitlab ci api时,只会拉取网站的HTTPS证书本身,而不会拉取多级的证书链。对于通常由中间CA颁发的证书来讲验证有可能遇到问题,如果runner所在的服务器的证书库中缺失了该中间CA的登记信息的话。

显然我们刚才的解决路数是直接暴力补全。

稍微规范一点的方法是 将中间CA,根CA都向runner服务器的证书库中注册一次。然而由于runner的服务器系统可能的多样性,这个思路搞起来怪繁琐的,没有暴力法来的简便直接。

 

参考:

安装: