Closed edwinhuish closed 1 year ago
感谢你的建议!我此前也考虑过使用 warp-cli status
来检测 warp-svc
的状态,这确实是一种更好的方案。但是此命令并没有良好的文档,我担心在未来它的行为可能会发生改变,因此我最终没有使用。
如果你担心的是 warp-svc
挂掉后的重启间隔,你可以在 docker-compose.yml 中修改 healthcheck 的参数,例如减少重试次数或者重试间隔。
感谢你的建议!我此前也考虑过使用
warp-cli status
来检测warp-svc
的状态,这确实是一种更好的方案。但是此命令并没有良好的文档,我担心在未来它的行为可能会发生改变,因此我最终没有使用。如果你担心的是
warp-svc
挂掉后的重启间隔,你可以在 docker-compose.yml 中修改 healthcheck 的参数,例如减少重试次数或者重试间隔。
我现在用 warp-svc
作为主进程貌似更好,只要它这个进程退出,整个容器都会立即退出。完全无须 healthcheck。 我之所以保留 healthcheck 主要是为了 gost
保活。虽然一般它不会有问题。。。
而且这样做,也符合docker容器运行单进程的理念。gost 是运行在主进程下的子进程,所以仍可视作单一进程
我考虑了一下,我觉得可能可以这么干:
init
修改为类似你的结构,将 warp-svc
作为主进程,将 warp-cli
的注册和 connect 移至子进程warp-cli status
轮询,而是仍然使用固定的等待时间(因为 warp-cli status
在未来的行为不被保证)healthcheck
不变你觉得这样的方案如何?
暂时来说,warp-cli status
没有问题,sleep
会导致配置差的机器未启动完成。从命令上来看,不太可能有其他改动的可能。就算有,那应该是后面的 bug fix,不应该砍脚趾避沙虫,畏手畏脚。
当然,具体怎么做,请自行斟酌。
我仍然认为应当避免使用没有文档的命令。参考 Boostport/setup-cloudflare-warp 我认为可以使用指数退避来实现对不同配置的机器的适应。
非常感谢作者的优秀项目。
但是在使用你的docker时,由于你的
warp-svc
不是主进程,导致warp-svc
挂了也必须要等 HEALTHCHECK 重试 3次失败,间隔15秒,至少1分钟之后,容器才会重启。我在你的基础上改良了一下,将
warp-svc
作为主进程,另写了一个subscript.sh
作为子进程,通过死循环的形式,检查warp-svc
是否已启动成功,成功就进行检查注册、注册licence、connect 后退出。healthcheck仅作为检查warp的健康状态,以及gost保活。
由于我是自用,代码写得比较糙,就不提PR了。写此 issues,仅为技术讨论,如果对你有用,可以按我的思路改良,如果没用,请忽视我就好。
我的项目地址: https://github.com/edwinhuish/warp-docker