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

现象

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

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

Error response from daemon: login attempt to http://registry.xxx.com/v2/ failed with status: 503 Service Unavailable

从本机执行 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 功能。

开启registry['debug_addr'] = "localhost:5001"
后，执行：curl "localhost:5001/debug/health"　

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

curl "localhost:5001/debug/health"{"storagedriver_filesystem":"filesystem: stat /var/opt/gitlab/gitlab-rails/shared/registry: permission denied"}

由此可以初步判定，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 服务器这种公司级的关键性服务器，其运维操作一定要规范化，

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

特此记录。