一次非典型的gitlab镜像库（registry服务）故障排除

现象

公司内机房一次停电与服务器重启后，有人反应gitlab内的CI无法执行了。

查看CI作业日志发现是registry镜像库访问返回了503错误。

?

从本机执行docker login发现果然同样异常。

查询镜像库的日志 /var/logs/gitlab/registry/current 文件发现，确实有大量503日志，但是日志中并没有特别具体的原因。

从gitlab页面上查看各项目的镜像库，发现所有的镜像列表都变为空了；但确认硬盘/var/opt/gitlab/gitlab-rails/shared/registry目录中，所有的镜像文件都存在。

试探

网络查询类似的报错，有外国网友说修改/etc/gitlab/gitlab.rb中的registry[“storagedriver_health_enabled”]为false即可。

修改后，执行gitlab-ctl reconfigure 和 gitlab-ctl restart后，果然 docker login可以了。

但是进入gitlab页面发现所有的镜像列表还是为空， 执行CI作业docker push还是失败。

也就是说，问题是出现在storage上，但是将storage的健康检查关闭，仅仅是无视了问题，并没有解决这个问题。

线索

继续查询官方文档，在https://docs.gitlab.cn/14.0/ee/administration/packages/container_registry.html中找到一个说明，

通过gitlab.rb中的该选项可以开启镜像库服务registry的DEBUG功能。

?

通过curl访问health后，终于得到了一个具体的错误信息：

?

由此可以初步判定，gitlab进程内部会通过stat命令访问 /var/opt/gitlab/gitlab-rails/shared/registry 这个目录，判断是否可用。

执行stat的时候碰到了权限问题。但是究竟是什么问题呢？

从 /var/opt/gitlab/gitlab-rails/shared/registry 开始一层层进行追查，由于目录内的内容都是由gitlab进程生产和管理的，一般情况下文件所有用户和权限设置都是OK的。

经过全局备份后，尝试对该目录进行 chmod -R 777 发现仍然报错。

破案

这就有意思了，如果/var/opt/gitlab/gitlab-rails/shared/registry 开始往下都变成777还不行，那一定是上层目录出了问题。

不停的向上层目录查看，翻到 /var/opt/gitlab这一层的时候终于发现问题：/var/opt/gitlab/gitlab-rails居然是个软链接，链接到一个 /data/xxx/xxx/xxx/xxx/gitlab-rails目录上。

咨询运维小哥才发现，原来是他为了加一个新的4T硬盘，把原来的gitlab-rails目录给链接到这个新硬盘的挂载点上了。

查询一层一层查询 /data/xxx/xxx/xxx/xxx/ 权限发现果然gitlab相关用户组及用户是无法访问的。

修改/data/xxx/xxx/xxx/xxx/ 每一级的权限后问题消失。

疑问

此时仍然有个谜团还没有解决，按照运维小哥所说，加装挂载大硬盘已经有一段时间了（具体时间都记不清了），

为何一直没有出问题，直到最近一次停电重启后才发生问题呢？

总结

gitlab的registry服务是CI的基础服务，但是其启动日志等并不是很详细，出问题后几乎没有什么帮助。

好在其提供了DEBUG的接口，并在官方文档中有所说明，这才能找到问题的具体原因。

另外，像git服务器这种公司级的关键性服务器，其运维操作一定要规范化，

任何操作一定要有【方案 – 评审 – 执行 – 记录】的完整可回溯文档，出问题后才能节省排查的时间。

特此记录。