Django live/staging 的服务器软件选择
为了开发我们的 Django Web 应用程序，我想迁移到一个自治系统，该系统会自动更新应用程序临时副本的源（来自 VCS），该副本具有与应用程序的实时版本几乎相同的属性。这样做的总体思路已经在 SO #625256。 Django 文档还讨论了 设置虚拟主机以在同一 Apache 上托管 2 个 Django 实例。我需要设置的许多部分已经就位。
我的具体问题是什么 - 如果此设置将在 Windows Server 2000 下运行，我应该选择什么服务器软件？
Apache+mod-wsgi 似乎是自然的选择，但根据 这篇博文，作者：Graham Dumpleton mog-wsgi在 Windows 上运行的 Apache 无法重新加载其单独的进程，需要重新启动整个 Apache 服务。这是一个不行，因为我不希望每当我们更新暂存代码时实时站点就会退出。
对于这种情况，服务器软件的最佳选择是什么？
- 维护 2 个可以独立重新启动的 Apache 副本（这感觉很糟糕）？
- 迁移到 Apache 以外的其他平台？
- ???
For developing our Django web app, I'd like to move to an autonomous system that automatically updates the source (from VCS) of a staging copy of the app which has near identical properties to the live version of the application. The general idea of doing this has already been covered here on SO #625256. The Django documentation also talks about setting up virtual hosts to host 2 instances of Django on the same Apache. Many of the pieces I need to set this up are already in place.
What my question specifically -- What server software should I choose if this setup will be running under Windows Server 2000?
Apache+mod-wsgi seems like the natural choice, but according to this blog post by Graham Dumpleton mog-wsgi on Apache running on Windows can't reload it's individual process and needs to restart the whole Apache service. This is a no-go as I don't want the live site dropping out whenever we update the staging's code.
What is the best choice of server software for this situation?
- Maintain 2 copies of Apache which can be independently restarted (this feels bad)?
- Migrate to something other than Apache?
- ???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
使用 Apache 时，Windows 上没有“单独的进程”，只有一个 Apache 工作进程。另外，Windows 上也没有守护进程模式。无论如何，这意味着两个 Django 实例确实在同一个进程中运行，尽管是在不同的子解释器中。所以，是的，重新加载一个 Django 站点的代码将会对另一个站点产生影响，因为它们位于同一进程中。
如果在 UNIX 系统上，可以向工作进程/守护进程发送终止信号，它们将重新启动，而无需重新启动整个 Apache。在 UNIX 上，即使多个站点与接受 HTTP 请求的端口的侦听器套接字始终保持打开状态相同进程中的多个站点，这也不会过度导致问题，因此在重新启动期间到达的后续请求只需排队并处理一次工作进程/守护进程再次运行。
在 Windows 上，当你正确选择时，整个 Apache 都必须重新启动。这意味着侦听器套接字将在很短的时间内关闭，并且会有一个小窗口，其中请求将连接失败。您确实需要对其进行一些测试，这个窗口有多长。通常这不是一个大问题，因为时间足够短，请求在该精确时刻命中的概率很低。换句话说，如果您只是谈论暂存环境，那么您可能会过度担心，因为它不会经常重新启动。如果您尝试在同一个 Apache 实例上运行开发站点，那么这将是一个问题。
总而言之，如果您希望登台实例尽可能接近生产环境，那么仍然需要运行 Apache，因此不同端口上的多个 Apache 实例将是唯一合理的解决方案。您可以在 CherryPy WSGI 服务器之上运行 Django，或者粘贴 WSGI 服务器并代理到它，但它是一个不同的托管系统，并且行为会有所不同，以至于您可能不会发现在生产设置时最终会出现的问题。
总而言之，我建议您实际做一些测试，针对 Apache 运行基准测试并同时执行重新启动，看看有多少请求因此失败。这将帮助您了解这是否是您认为的大问题。
There are no 'individual processes' on Windows when using Apache, there is only one Apache worker process. Also, there is no daemon mode on Windows either. Anyway, what it all means is that both Django instances do run in the one process, albeit in different sub interpreters. So yes, to cause code for one Django site to be reloaded will have impacts on the other site because of them being in the same process.
If one was on a UNIX system one could send a kill signal to the worker/daemon processes and they would restart without restart whole of Apache. On UNIX this does not overly cause problems even when multiple sites in same process as the listener socket for port on which HTTP requests are accepted is maintained open at all times, so subsequent requests which arrive during the restart just queue up and will be handled once worker/daemon processes are running again.
On Windows as you rightly pick up the whole of Apache has to be restarted. This means that for ever so small a time that listener socket will be closed off and there will be a small window where requests will get a connection failed. How long a window this is you will really need to do some testing on. Usually it isn't a huge problem as is short enough that low probability that request will hit at that precise moment. In other words, you may be unduly worrying if you are only talking about a staging environment given that wouldn't expect to restart very often. If you were trying to run a development site on same Apache instance then that would be a problem.
That all said, if you want the staging instance to be as close as possible to production then would still need to be running Apache so multiple Apache instances on different ports would be only logical solution. You could run Django on top of CherryPy WSGI server or Paste WSGI server and proxy to it, but then it is a different hosting system and will behave differently to the extent that you may not pick up issues which would ultimately occur when on production setup.
All up, I would suggest you actually do some tests where you run benchmarks against Apache and perform a restart at same time and see how many requests fail as a result. This will help you understanding whether it is the big problem you think it is.
默认情况下，Django 会话是持久的并且由数据库支持。重新启动网络服务器不会中断会话；当服务器恢复时，用户将像以前一样继续操作。重新启动后，会话密钥将由 cookie 提供，数据库会调用会话变量，然后我们就可以不间断地继续进行。
http://docs.djangoproject.com/en/dev/topics/http /sessions/
如果您担心会话被劫持，请缩短过期时间，在关闭浏览器时销毁 cookie，并定期从数据库中清除过期会话。
至少我是这么读的。
我会坚持使用最常见的实现，因为这将使您获得最多的支持。我希望在unix上是apache+mod_wsgi。三分之二就必须做。显然，登台和生产连接到同一个数据库。
你引起了我的兴趣，因为我正在考虑在另一个域名下建立一个“临时”部署，所以在我们对所有备用域名进行测试并准备好之后，我们只需将 apache conf 中的“servername”变量交换即可上线。通过优雅的重启，我希望用户不会注意到......除了突然出现的所有新功能:-)
Django sessions are, by default, persistent and database backed. Restarting the webserver does not interrupt the session; when the server comes back up the user will proceed as before. After a restart the session key is presented by the cookie, the database recalls the session variables, and we proceed uninterrupted.
http://docs.djangoproject.com/en/dev/topics/http/sessions/
If you're worried about hijacked sessions then reduce the expiry time, destory the cookie with browser close, and routinely clear expired sessions from the database.
At least that's how I read it.
I'd stick to the most common implementation simply because that will expose you to the most support. I expect that is apache+mod_wsgi on unix. Two out of three will have to do. Obviously staging and production connect to the same database.
You get my interest because I'm considering establishing a 'staging' deployment under another domainname so after we get the alternate all tested and ready then we simply swap the "servername" variable in the apache conf to go-live. With a graceful restart I'm hoping it would be unnoticeable to users... excepting all the new features suddenly appearing :-)