Dockerfile实现方式讨论

[edwinhuish]

非常感谢作者的优秀项目。

但是在使用你的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

[cmj2002]

感谢你的建议！我此前也考虑过使用 warp-cli status 来检测 warp-svc 的状态，这确实是一种更好的方案。但是此命令并没有良好的文档，我担心在未来它的行为可能会发生改变，因此我最终没有使用。

如果你担心的是 warp-svc 挂掉后的重启间隔，你可以在 docker-compose.yml 中修改 healthcheck 的参数，例如减少重试次数或者重试间隔。

[edwinhuish]

感谢你的建议！我此前也考虑过使用 warp-cli status 来检测 warp-svc 的状态，这确实是一种更好的方案。但是此命令并没有良好的文档，我担心在未来它的行为可能会发生改变，因此我最终没有使用。

如果你担心的是 warp-svc 挂掉后的重启间隔，你可以在 docker-compose.yml 中修改 healthcheck 的参数，例如减少重试次数或者重试间隔。

我现在用 warp-svc 作为主进程貌似更好，只要它这个进程退出，整个容器都会立即退出。完全无须 healthcheck。 我之所以保留 healthcheck 主要是为了 gost 保活。虽然一般它不会有问题。。。

而且这样做，也符合docker容器运行单进程的理念。gost 是运行在主进程下的子进程，所以仍可视作单一进程

[cmj2002]

我考虑了一下，我觉得可能可以这么干：

• 将 init 修改为类似你的结构，将 warp-svc 作为主进程，将 warp-cli 的注册和 connect 移至子进程
• 子进程不使用 warp-cli status 轮询，而是仍然使用固定的等待时间（因为 warp-cli status 在未来的行为不被保证）
• 保持 healthcheck 不变

你觉得这样的方案如何？

[edwinhuish]

暂时来说，warp-cli status 没有问题，sleep 会导致配置差的机器未启动完成。从命令上来看，不太可能有其他改动的可能。就算有，那应该是后面的 bug fix，不应该砍脚趾避沙虫，畏手畏脚。

当然，具体怎么做，请自行斟酌。

[cmj2002]

我仍然认为应当避免使用没有文档的命令。参考 Boostport/setup-cloudflare-warp 我认为可以使用指数退避来实现对不同配置的机器的适应。