Django live / staging的服务器软件选择

时间:2009-11-06 03:14:45

标签: django apache mod-wsgi

为了开发我们的Django Web应用程序,我想转移到一个自动系统,该系统自动更新应用程序的暂存副本的源(从VCS),该应用程序具有与应用程序的实时版本几乎相同的属性。 SO #625256已经涵盖了这样做的一般想法。 Django文档还讨论了在同一个Apache上托管2个Django实例的setting up virtual hosts。我需要设置的许多部分已经到位。

我的问题具体是什么 - 如果此设置将在Windows Server 2000下运行,我应该选择哪种服务器软件?

Apache + mod-wsgi似乎是自然的选择,但根据this blog post Graham Dumpleton mog-wsgi在Windows上运行的Apache无法重新加载它的单个进程并需要重新启动整个Apache服务。这是 no-go ,因为我不希望每当我们更新登台代码时,实时网站都会丢失。

针对这种情况,服务器软件的最佳选择是什么?

  1. 维护2份可以独立重启的Apache (这感觉不好)
  2. 迁移到Apache以外的其他内容?
  3. ???

2 个答案:

答案 0 :(得分:2)

使用Apache时,Windows上没有“单个进程”,只有一个Apache工作进程。此外,Windows上也没有守护进程模式。无论如何,这一切意味着两个Django实例都在一个进程中运行,尽管在不同的子解释器中。所以,是的,导致重新加载一个Django站点的代码会对其他站点产生影响,因为它们处于同一个进程中。

如果一个人在UNIX系统上,可以向worker / daemon进程发送一个kill信号,他们会重启而不重启整个Apache。在UNIX上,即使与接受HTTP请求的端口的侦听器套接字在同一进程中的多个站点始终保持打开状态,也不会过度导致问题,因此在重新启动期间到达的后续请求将排队并将被处理一次worker / daemon进程再次运行。

在Windows上,你正确地拿起整个Apache必须重新启动。这意味着,只有很小的时间才能关闭监听器套接字,并且会有一个小窗口,请求将使连接失败。这个窗口需要多长时间才能进行一些测试。通常这不是一个很大的问题,因为它足够短,以至于请求在该精确时刻达到的概率很低。换句话说,如果你只是谈论一个不会经常重启的暂存环境,你可能会过分担心。如果您尝试在同一个Apache实例上运行开发站点,那么这将是一个问题。

如果你想让登台实例尽可能接近生产,那么仍然需要运行Apache,因此不同端口上的多个Apache实例将只是逻辑解决方案。您可以在CherryPy WSGI服务器上运行Django或者将WSGI服务器和代理粘贴到它上面,但是它是一个不同的托管系统,并且行为方式不同,以至于您可能无法获取在生产设置时最终会出现的问题。

总而言之,我建议你实际做一些测试,在这些测试中你对Apache运行基准测试并同时执行重启,看看有多少请求因此而失败。这将有助于您了解它是否是您认为的大问题。

答案 1 :(得分:1)

默认情况下,Django会话是持久的并且是数据库支持的。重新启动Web服务器不会中断会话;当服务器恢复时,用户将像以前一样继续。重新启动后,cookie会显示会话密钥,数据库会调用会话变量,然后我们不间断地继续。

http://docs.djangoproject.com/en/dev/topics/http/sessions/

如果您担心被劫持的会话,那么减少到期时间,在浏览器关闭时破坏cookie,并定期清除数据库中过期的会话。

至少这是我读它的方式。

我坚持最常见的实现只是因为这会让你得到最多的支持。我希望在unix上是apache + mod_wsgi。三分之二必须要做。显然,登台和生产连接到同一个数据库。

你得到了我的兴趣,因为我正在考虑在另一个域名下建立一个'staging'部署,所以在我们得到备用所有测试并准备就绪后,我们只需将apache conf中的“servername”变量交换为go-live。通过优雅的重启,我希望用户不会注意到......除了突然出现的所有新功能外: - )