hupwatch 0.0.3

为什么？

今天必须优雅地重新加载web应用程序代码。每个 德沃斯应该已经告诉你了。许多python web服务器允许 这种情况下，但处理方式不同。通常你只会 很少有合理的选择：

• gunicorn 允许这样做 只需向gunicorn进程发送unix hup 信号。它 将优雅地停止现有的工人并以新的工人开始新的工人 代码的版本。另一种选择是发送 usr2 信号 使用一组udpated workers生成新的主gunicorn进程。你 然后能够
• uwsgi 提供了几个选项，并且 最好的一个在效果上与发送 usr2 到 冈尼科恩 。uwsgi对此提供了非常详细的文档。一 可以说"太啰嗦了"。祝你理解它！
• 您可能依赖于更高级别的负载平衡 架构堆栈。你仍然需要能够完成当前 正在部署期间处理的请求。所以你 需要一个至少可以正常关闭其 工人。

gunicorn和uwsgi提供的优雅的重新加载实现是 当你尝试自动化或者使用它的时候，两者都很好但是实际上都失败了 使用任何常用的流程/服务监督工具：

• 如果你使用 小精灵。这是许多组织中非常流行的技术。 Gunicorn也不会更新Gunicorn自己的配置 但只会用新代码重新启动工作者。这个 如果您只需在原位替换代码 和 不需要优化配置选项，如工作类或 并发设置。不过，我还是祝你好运 使用django，您使用最新的 释放。老古尼科恩工人将"优雅地"关闭，但也可能 如果替换了中的代码，则"优雅地"响应服务器错误 地点。Gunicorn接受一个 --chdir 参数，这个参数应该可以修复这个问题 但它同样不适合一些流行的深度解决方案 就像建筑一样。
• 第二种方法（生成新的主服务器进程）似乎是 一种更好的方法，通常与符号链接一起工作，但不能播放 有很多过程监控工具。最受欢迎的 python world-supervisord-必须在 为了能够控制它。一次Gunicorn（在 usr2 信号之后） 或者uwsgi（不管需要什么）生成（重新执行）一个新的主控 处理不再由主管作为其父级。简言之，它 最终将成为 init 的子进程 主管"采用"此类流程的方法。主管会尽力 再繁殖一次，你的工人就比你多出两倍 预期。如果你不注意到这一点并执行许多后续操作 以这种方式重新加载，最终可能会耗尽资源。
• 通常在负载均衡器的帮助下处理更新看起来像 一个更安全的解决方案，因为只要重新启动web服务器 从堆栈中移除。不幸的是这很难 自动化并增加整体复杂性 操作。

<当然，您可以通过提供一些定制来解决这些问题 集成您正在使用或正在执行的任何过程监视工具 一些疯狂的下一个/当前实例切换和mantain翻倍 仅为此目的配置服务。这将使 您的解决方案要么不可移植到其他工具，要么使整个 解决方案很难以可靠的方式实现自动化。