增加健康检查脚本

[pacoxu]

当 镜像拉取失败，报错为 500 Internal Server Error， 通常是因为 ufile 故障导致的。

此时 比较简单的解决方法是 重启对应的容器。（需要验证） 镜像仓库不能自动恢复。

必要时需要重启docker 😓

[github-actions[bot]]

Hi @pacoxu, 感谢您的反馈! 我们会尽快跟进.

Details

Instructions for interacting with me using comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the [gh-ci-bot](https://github.com/wzshiming/gh-ci-bot) repository.

[yankay]

是不是把 部署到 Kubernetes，配置 liveness 就可以解决了

[wzshiming]

是不是把 部署到 Kubernetes，配置 liveness 就可以解决了

这样现有服务器配置可能吃不消

我感觉基于 register 镜像, 构建一个新的镜像加上健康检查的逻辑, 几次不健康就自己退出, 这样可能会轻量一点

[wzshiming]

https://github.com/distribution/distribution/blob/main/docs/configuration.md

health:
  storagedriver:
    enabled: true
    interval: 10s
    threshold: 3

看了下好像自身有健康检查的配置

[pacoxu]

compose 可以直接配置

- healthcheck:
    test: ["curl xx"]

[wzshiming]

compose 可以直接配置

- healthcheck:
    test: ["curl xx"]

这个不会重启

[pacoxu]

想到一个简单方法

• kubelet + static-pod
• pod 配置健康检查

[pacoxu]

https://kubernetes.io/docs/tasks/configure-pod-container/translate-compose-kubernetes/ 用这个生成的话 一般是生成 deployment 把 pod yaml 抽出来

[wzshiming]

现在是用内网域名去区分不同register, 简单的 kubelet + static-pod 应该不行, 还有 DNS 和 内网 问题, 还要试一下 us3fs 在容器里挂载会有啥问题

[wzshiming]

测试了一下是 us3fs 挂载的 存在两个问题

1. 一个 us3fs 挂载的目录重新挂载, 在容器里挂载目录里文件还是不可见, 必须重启容器才能恢复
2. registry 自身的健康检查, 在 us3fs 挂载断开之后, 才能正确响应不健康的状态, 在 us3fs 重新挂载后响应健康, 由于问题 1, 这个健康检查相当于无效的.

us3fs 进程还存在内存占用不释放的问题 以及挂载进容器的目录, 会实际占用磁盘, 经过排查容器里没其他文件但是就是占用着磁盘, 重建容器后, 这部分磁盘才会释放

[wzshiming]

us3fs 的源码没有找到...

我感觉直接改 registry 对接一个 us3 的驱动, 应该可以解决上述问题 https://github.com/distribution/distribution/tree/main/registry/storage/driver

us3 自称兼容 aws-s3 但是测试下来在 registry 的 driver 并不完全兼容

看了一下 us3 的 sdk 感觉质量有点差, 而且已经很久没维护过了, 感觉有很多坑不太想对接... https://github.com/ufilesdk-dev/ufile-gosdk

registry 的 driver 接 s3 和 存目录, 两者同一个文件存的路径不一样, 这也有个坑

[wzshiming]

计划这么修复

1. 修改 registry 镜像的 entrypoint 为一个脚本, fork 启动原entrypoint, 然后每隔几秒钟检查挂载的目录是否存在, 如果不存在直接退出, 由 docker-compose 重新拉起
2. 每天凌晨的时候重启一次 us3fs, 和 registry
3. 把 us3fs 进程直接起在 修改的registry镜像 里 (可选, 我猜测是 由于 us3fs 没有处理挂载到目录, 这个目录又被挂载到容器这种情况, 所以造成的 内存 和 磁盘 泄露, 此举可以避免这种情况, 这样就不用重启了, 不确定会咋样试试效果)

@pacoxu @yankay

[wzshiming]

计划这么修复

1. 修改 registry 镜像的 entrypoint 为一个脚本, fork 启动原entrypoint, 然后每隔几秒钟检查挂载的目录是否存在, 如果不存在直接退出, 由 docker-compose 重新拉起
2. 每天凌晨的时候重启一次 us3fs, 和 registry
3. 把 us3fs 进程直接起在 修改的registry镜像 里 (可选, 我猜测是 由于 us3fs 没有处理挂载到目录, 这个目录又被挂载到容器这种情况, 所以造成的 内存 和 磁盘 泄露, 此举可以避免这种情况, 这样就不用重启了, 不确定会咋样试试效果)

@pacoxu @yankay

/enhancement 完成 1 和 3 看起来没啥问题过几天看下效果

[wzshiming]

/assign

[wzshiming]

跑了几天看着效果不错,

1. 这段时间服务都没挂
2. 内存没在泄露了
3. 磁盘占用增长也减缓了

/close