python 你如何部署你的 WSGI 应用程序？（以及为什么它是最好的方法）

How do YOU deploy your WSGI application? (and why it is the best way)

提问by Ali Afshar

Deploying a WSGI application. There are many ways to skin this cat. I am currently using apache2 with mod-wsgi, but I can see some potential problems with this.

部署 WSGI 应用程序。有很多方法可以给这只猫剥皮。我目前正在使用带有 mod-wsgi 的 apache2，但我可以看到一些潜在的问题。

So how can it be done?

那么怎么做呢？

1. Apache Mod-wsgi (the other mod-wsgi's seem to not be worth it)
2. Pure Python web server eg paste, cherrypy, Spawning, Twisted.web
3. as 2 but with reverse proxy from nginx, apache2 etc, with good static file handling
4. Conversion to other protocol such as FCGI with a bridge (eg Flup) and running in a conventional web server.

1. Apache Mod-wsgi（其他 mod-wsgi 似乎不值得）
2. 纯 Python 网络服务器，例如 paste、cherrypy、Spawning、Twisted.web
3. 作为 2 但使用来自 nginx、apache2 等的反向代理，具有良好的静态文件处理
4. 转换为其他协议，例如带有桥接器（例如 Flup）并在传统 Web 服务器中运行的 FCGI。

More?

更多的？

I want to know how you do it, and why it is the best way to do it. I would absolutely loveyou to bore me with details about the whats and the whys, application specific stuff, etc. I will upvote any non-insane answer.

我想知道你是如何做到的，以及为什么这是最好的方法。我绝对希望你能详细介绍一下什么是什么和为什么，应用程序特定的东西等等。我会赞成任何非疯狂的答案。

采纳答案by MrTopf

As always: It depends ;-)

一如既往：这取决于;-)

When I don't need any apache features I am going with a pure python webserver like paste etc. Which one exactly depends on your application I guess and can be decided by doing some benchmarks. I always wanted to do some but never came to it. I guess Spawning might have some advantages in using non blocking IO out of the box but I had sometimes problems with it because of the patching it's doing.

当我不需要任何 apache 功能时，我会使用像 paste 等纯 python 网络服务器。我猜哪个完全取决于您的应用程序，并且可以通过做一些基准测试来决定。我一直想做一些，但从未实现。我想 Spawning 在使用非阻塞 IO 开箱即用方面可能有一些优势，但我有时会因为它正在修补而遇到问题。

You are always free to put a varnish in front as well of course.

当然，您也可以随时在前面涂上清漆。

If an Apache is required I am usually going with solution 3 so that I can keep processes separate. You can also more easily move processes to other servers etc. I simply like to keep things separate.

如果需要 Apache，我通常会使用解决方案 3，以便我可以将进程分开。您还可以更轻松地将进程移动到其他服务器等。我只是喜欢将事情分开。

For static files I am using right now a separate server for a project which just serves static images/css/js. I am using lighttpd as webserver which has great performance (in this case I don't have a varnish in front anymore).

对于静态文件，我现在正在为一个项目使用单独的服务器，该服务器仅提供静态图像/css/js。我使用 lighttpd 作为具有出色性能的网络服务器（在这种情况下，我前面不再有清漆）。

Another useful tool is supervisordfor controlling and monitoring these services.

另一个有用的工具是用于控制和监视这些服务的supervisord。

I am additionally using buildoutfor managing my deployments and development sandboxes (together with virtualenv).

我还使用buildout来管理我的部署和开发沙箱（与virtualenv一起）。

回答by Jason Baker

The absolute easiest thing to deploy is CherryPy. Your web application can also become a standalone webserver. CherryPy is also a fairly fast server considering that it's written in pure Python. With that said, it's not Apache. Thus, I find that CherryPy is a good choice for lower volume webapps.

最容易部署的是 CherryPy。您的 Web 应用程序也可以成为独立的 Web 服务器。CherryPy 也是一个相当快的服务器，因为它是用纯 Python 编写的。话虽如此，它不是Apache。因此，我发现 CherryPy 是低容量 web 应用程序的不错选择。

Other than that, I don't think there's any right or wrong answer to this question. Lots of high-volume websites have been built on the technologies you talk about, and I don't think you can go too wrong any of those ways (although I will say that I agree with mod-wsgi not being up to snuff on every non-apache server).

除此之外，我认为这个问题没有任何正确或错误的答案。许多高容量网站都建立在您所谈论的技术上，我认为您不会在任何这些方面出错（尽管我会说我同意 mod-wsgi 并没有对每个非 apache 服务器）。

Also, I've been using isapi_wsgito deploy python apps under IIS. It's a less than ideal setup, but it works and you don't always get to choose otherwise when you live in a windows-centric world.

另外，我一直在使用isapi_wsgi在 IIS 下部署 python 应用程序。这是一个不太理想的设置，但它可以工作，并且当您生活在以 Windows 为中心的世界中时，您并不总是可以选择其他方式。

回答by bobince

I would absolutely love you to bore me with details about the whats and the whys, application specific stuff, etc

我绝对希望你能详细介绍一下什么是什么和为什么，应用程序特定的东西等

Ho. Well you asked for it!

何。那么你要求它！

Like Daniel I personally use Apache with mod_wsgi. It is still new enough that deploying it in some environments can be a struggle, but if you're compiling everything yourself anyway it's pretty easy. I've found it very reliable, even the early versions. Props to Graham Dumpleton for keeping control of it pretty much by himself.

像丹尼尔一样，我个人使用带有 mod_wsgi 的 Apache。它仍然足够新，在某些环境中部署它可能会很困难，但如果你自己编译所有东西，这很容易。我发现它非常可靠，即使是早期版本。支持 Graham Dumpleton 自己几乎可以控制它。

However for me it's essential that WSGI applications work across all possible servers. There is a bit of a hole at the moment in this area: you have the WSGI standard telling you what a WSGI callable (application) does, but there's no standardisation of deployment; no single way to tell the web server where to find the application. There's also no standardised way to make the server reload the application when you've updated it.

然而对我来说，WSGI 应用程序在所有可能的服务器上工作是必不可少的。目前在这方面存在一些漏洞：您有 WSGI 标准告诉您 WSGI 可调用（应用程序）做什么，但没有部署标准化；没有单一的方法可以告诉 Web 服务器在哪里可以找到应用程序。当您更新应用程序时，也没有标准化的方法使服务器重新加载应用程序。

The approach I've adopted is to put:

我采用的方法是：

• all application logic in modules/packages, preferably in classes

• all website-specific customisations to be done by subclassing the main Application and overriding members

• all server-specific deployment settings (eg. database connection factory, mail relay settings) as class __init__() parameters

• one top-level ‘application.py' script that initialises the Application class with the correct deployment settings for the current server, then runs the application in such a way that it can work deployed as a CGI script, a mod_wsgi WSGIScriptAlias (or Passenger, which apparently works the same way), or can be interacted with from the command line

• a helper module that takes care of above deployment issues and allows the application to be reloaded when the modules the application is relying on change

• 模块/包中的所有应用程序逻辑，最好在类中

• 通过子类化主应用程序和覆盖成员来完成所有特定于网站的定制

• 所有特定于服务器的部署设置（例如数据库连接工厂、邮件中继设置）作为类 __init__() 参数

• 一个顶级“application.py”脚本，它使用当前服务器的正确部署设置初始化应用程序类，然后以一种可以部署为 CGI 脚本的方式运行应用程序，一个 mod_wsgi WSGIScriptAlias（或Passenger，显然以相同的方式工作），或者可以从命令行进行交互

• 一个帮助程序模块，负责处理上述部署问题，并允许在应用程序依赖的模块发生变化时重新加载应用程序

So what the application.py looks like in the end is something like:

那么 application.py 最终的样子是这样的：

#!/usr/bin/env python

import os.path
basedir= os.path.dirname(__file__)

import MySQLdb
def dbfactory():
    return MySQLdb.connect(db= 'myappdb', unix_socket= '/var/mysql/socket', user= 'u', passwd= 'p')

def appfactory():
    import myapplication
    return myapplication.Application(basedir, dbfactory, debug= False)

import wsgiwrap
ismain= __name__=='__main__'
libdir= os.path.join(basedir, 'system', 'lib')
application= wsgiwrap.Wrapper(appfactory, libdir, 10, ismain)

The wsgiwrap.Wrapper checks every 10 seconds to see if any of the application modules in libdir have been updated, and if so does some nasty sys.modules magic to unload them all reliably. Then appfactory() will be called again to get a new instance of the updated application.

wsgiwrap.Wrapper 每 10 秒检查一次，以查看 libdir 中的任何应用程序模块是否已更新，如果更新，一些讨厌的 sys.modules 魔术会可靠地卸载它们。然后将再次调用 appfactory() 以获取更新应用程序的新实例。

(You can also use command line tools such as

（您也可以使用命令行工具，例如

./application.py setup
./application.py daemon

to run any setup and background-tasks hooks provided by the application callable?—?a bit like how distutils works. It also responds to start/stop/restart like an init script.)

运行由可调用应用程序提供的任何设置和后台任务挂钩？—？有点像 distutils 的工作原理。它还像初始化脚本一样响应启动/停止/重启。）

Another trick I use is to put the deployment settings for multiple servers (development/testing/production) in the same application.py script, and sniff ‘socket.gethostname()' to decide which server-specific bunch of settings to use.

我使用的另一个技巧是将多个服务器（开发/测试/生产）的部署设置放在同一个 application.py 脚本中，然后嗅探 'socket.gethostname()' 来决定使用哪一组特定于服务器的设置。

At some point I might package wsgiwrap up and release it properly (possibly under a different name). In the meantime if you're interested, you can see a dogfood-development version at http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py.

在某些时候，我可能会打包 wsgiwrap 并正确释放它（可能以不同的名称）。同时，如果您有兴趣，可以在http://www.doxdesk.com/file/software/py/v/wsgiwrap-0.5.py 上查看 dogfood 开发版本。

回答by Vasil

Nginx reverse proxy and static file sharing + XSendfile + uploadprogress_module. Nothing beats it for the purpose.

Nginx 反向代理和静态文件共享 + XSendfile + uploadprogress_module。没有什么比它更好的了。

On the WSGI side either Apache + mod_wsgi or cherrypy server. I like to use cherrypy wsgi server for applications on servers with less memory and less requests.

在 WSGI 方面，Apache + mod_wsgi 或cherrypy 服务器。我喜欢将cherrypy wsgi 服务器用于内存和请求较少的服务器上的应用程序。

Reasoning:

推理：

I've done benchmarks with different tools for different popular solutions.

我已经针对不同的流行解决方案使用不同的工具进行了基准测试。

I have more experience with lower level TCP/IP than web development, especially http implementations. I'm more confident that I can recognize a good http server than I can recognize a good web framework.

我在较低级别的 TCP/IP 方面比 Web 开发有更多的经验，尤其是 http 实现。与识别良好的 Web 框架相比，我对识别良好的 http 服务器更有信心。

I know Twisted much more than Django or Pylons. The http stack in Twisted is still not up to this but it will be there.

我比 Django 或 Pylons 更了解 Twisted。Twisted 中的 http 堆栈仍然达不到这一点，但它会在那里。

回答by popcnt

TurboGears (2.0)

涡轮齿轮 (2.0)

TurboGears 2.0is leaving Betawithin the next month (has been in it for plenty of time). 2.0 improves upon 1.0 series and attempts to give you best-of-breed WSGI stack, so it makes some default choices for you, if you want the least fuss.

TurboGears 2.0将在下个月内离开Beta（已经有很多时间了）。2.0 改进了 1.0 系列并尝试为您提供同类最佳的 WSGI 堆栈，因此如果您不想大惊小怪，它会为您提供一些默认选择。

it has the tg*tools for testing and deployment in 1.x series, but now transformed to pasterequivalents in 2.0 series, which shoud seem familiar if you've expermiented with pylons.

它具有tg*1.x 系列中的测试和部署工具，但现在转换为paster2.0 系列中的等效工具，如果您体验过pylons.

tg-admin quickstart —> paster quickstart
tg-admin info —> paster tginfo
tg-admin toolbox –> paster toolbox
tg-admin shell –> paster shell
tg-admin sql create –> paster setup-app development.ini

Pylons

塔架

It you'd like to be more flexible in your WSGI stack (choice of ORM, choice of templater, choice of form-ing), Pylons is becoming the consolidated choice. This would be my recommended choice, since it offers excellent documentation and allows you to experiment with different components.

如果您希望在 WSGI 堆栈中更加灵活（ORM 的选择、模​​板程序的选择、形成的选择），Pylons 正在成为综合选择。这将是我推荐的选择，因为它提供了出色的文档并允许您试验不同的组件。

It is a pleasure to work with as a result, and works on under Apache (production deployment) or stand-alone (helpful for testing and experimenting stage).

结果很高兴使用，并且可以在 Apache（生产部署）或独立（有助于测试和试验阶段）下工作。

so it follows, you can do both with Pylons:

所以接下来，你可以用 Pylons 做到这两点：

• 2 option for testing stage (pythonstandalone)

• 4 for scalable production purposes (FastCGI, assuming the database you choose can keep up)

• 2 测试阶段选项（python独立）

• 4 用于可扩展的生产目的（FastCGI假设您选择的数据库可以跟上）

The Pylons admin interface is very similar to TurboGears. Here's a toy standaloneexample:

Pylons 管理界面与 TurboGears 非常相似。这是一个独立的玩具示例：

$ paster create -t pylons helloworld
$ cd helloworld
$ paster serve --reload development.ini

for production-class deployment, you could refer to the setup guide of Apache + FastCGI + mod_rewriteis available here. this would scale up to most needs.

对于生产级部署，您可以参考此处Apache + FastCGI + mod_rewrite提供的设置指南。这将扩大到大多数需求。

回答by Baltimark

I'm using Google App Engine for an application I'm developing. It runs WSGI applications. Here's a couple bits of info on it.

我正在将 Google App Engine 用于我正在开发的应用程序。它运行 WSGI 应用程序。 这里有一些关于它的信息。

This is the first web-app I've ever really worked on, so I don't have a basis for comparison, but if you're a Google fan, you might want to look into it. I've had a lot of fun using it as my framework for learning.

这是我真正工作过的第一个网络应用程序，所以我没有比较的基础，但如果你是谷歌的粉丝，你可能想研究一下。使用它作为我的学习框架，我获得了很多乐趣。

回答by Bjorn

Apache httpd + mod_fcgid using web.py (which is a wsgi application).

Apache httpd + mod_fcgid 使用 web.py（这是一个 wsgi 应用程序）。

Works like a charm.

奇迹般有效。

回答by Daniel Von Fange

Apache+mod_wsgi,

Apache+mod_wsgi，

Simple, clean. (only four lines of webserver config), easy for other sysadimns to get their head around.

简单，干净。（只有四行网络服务器配置），其他系统管理员很容易理解。

回答by Jacob Gabrielson

We are using pure Paste for some of our web services. It is easy to deploy (with our internal deployment mechanism; we're not using Paste Deploy or anything like that) and it is nice to minimize the difference between production systems and what's running on developers' workstations. Caveat: we don't expect low latency out of Paste itself because of the heavyweight nature of our requests. In some crude benchmarking we did we weren't getting fantasticresults; it just ended up being moot due to the expense of our typical request handler. So far it has worked fine.

我们正在为我们的一些网络服务使用纯粘贴。它很容易部署（使用我们的内部部署机制；我们没有使用 Paste Deploy 或类似的东西），并且可以最大限度地减少生产系统与开发人员工作站上运行的系统之间的差异。警告：由于我们请求的重量级性质，我们不期望 Paste 本身具有低延迟。在一些粗略的基准测试中，我们没有得到很好的结果；由于我们典型的请求处理程序的开销，它最终变得毫无意义。到目前为止，它运行良好。

Static data has been handled by completely separate (and somewhat "organically" grown) stacks, including the use of S3, Akamai, Apache and IIS, in various ways.

静态数据已由完全独立（并且有些“有机”增长）的堆栈以各种方式处理，包括使用 S3、Akamai、Apache 和 IIS。