How do you deploy your WSGI application? (and why is this the best way)

Question

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

So how can this be done?

• Apache Mod-wsgi (another mod-wsgi seems not worth it)
• Pure Python web server e.g. paste, cherry, spawning, Twisted.web
• like 2, but with reverse proxies from nginx, apache2, etc., with good static file handling.
• Convert to another protocol, such as FCGI with a bridge (for example, Flup) and run on a regular web server.

Further

I want to know how you do it and why this is the best way to do it. I would totally love to tell me about the details of what and what, about specific applications, etc. I will pick up any crazy answer.

Answer 1

As always: it depends; -)

When I do not need any apache functions, I am going to use a pure python web server like insert, etc. Which question depends on your application, I think, and it can be solved by doing some tests. I always wanted to do something, but never came. I suggest that Spawning may have some advantages in using a non-blocking IO out of the box, but I had problems with it due to its fix.

You can always put a varnish in front, and also, of course.

If Apache is required, I usually go with solution 3 so that I can support the processes separately. You can also easily move processes to other servers, etc. I just like to keep things separate.

For static files, I now use a separate server for the project, which simply serves for static images / css / js. I use lighttpd as a web server, which has great performance (in this case, I no longer have varnish).

Another useful tool is supervisord to control and monitor these services.

I also use buildout to manage my deployments and sandboxed programs (along with virtualenv ).

Answer 2

Absolutely easiest to deploy CherryPy. Your web application can also become a standalone web server. CherryPy is also a fairly fast server, given that it is written in pure Python. With that said, this is not Apache. Therefore, I believe that CherryPy is a good choice for lower volume web applications.

Other than that, I don't think there is a right or wrong answer to this question. A lot of sites of large volume were built on the technologies you are talking about, and I do not think that you can be mistaken in any of these ways (although I will say that I agree with mod-wsgi, which does not reach the tobacco on each server non-apache).

Also, I used isapi_wsgi to deploy python applications in IIS. This is a less ideal setting, but it works, and you can’t always choose when to live in a window-oriented world.

Answer 3

I would really like you to tell me with details about Whats and Whys, specific applications, etc.

Ho. Well, you asked for it!

Like Daniel, I personally use Apache with mod_wsgi. It’s still new enough that deploying it in some environments can be a struggle, but if you do build everything yourself, it’s pretty easy. I found it very reliable, even in earlier versions. Graham Dumpleton’s reinforcements for controlling him by himself.

However, it is important for me that WSGI applications run on all possible servers. There is a bit of a hole in this area right now: you have the WSGI standard telling you what the WSGI (application) does, but there is no deployment standardization; There is no single way to tell the web server where to find the application. There is also no standardized way to restart the server when it is updated.

The approach I took is to put:

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

• all customizable settings for the website are done by subclassing the main application and redefining the elements

• all deployment parameters for the server (for example, connecting to the factory database, mail relay settings) as parameters of the __init __ () class

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

• an auxiliary module that takes care of deployment problems and allows you to restart the application when the modules on which the application uses changes

So what application.py looks like at the end, it's something like:

#!/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) 

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

(You can also use command line tools such as

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

to run any configuration hooks and background tasks provided by the called application is a bit like distutils. It also responds to start / stop / restart like init script.)

Another trick I use is setting deployment parameters for several servers (development / testing / production) in the same application.py script and sniff 'socket.gethostname () application to decide which set of parameters for a particular server to use.

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

Answer 4

Nginx reverse proxy and static file sharing + XSendfile + uploadprogress_module. Nothing beats that goal.

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

Reasoning:

I have done tests with various tools for various popular solutions.

I have more experience with lower-level TCP / IP than with web development, especially with HTTP implementations. I am sure that I can recognize a good http server, than I can recognize a good web infrastructure.

I know that Twisted is much more than Django or Pylons. Twisted's HTTP stack still doesn't match this, but it will be there.

Answer 5

I am using the Google App Engine for the application that I am developing. It runs WSGI applications. Here are a few bits of information about this.

This is the first web application I've ever worked on, so I don’t have a basis for comparison, but if you’re a fan of Google, you may need to study it. I was very fun to use it as a basis for training.

Answer 6

TurboGears (2.0)

TurboGears 2.0 leaves the beta for the next month (there was enough time in it). 2.0 improves on the 1.0 series and tries to give you the best-in-class WSGI stack, so you can choose the default for you if you need the smallest problem.

it has tg* tools for testing and deployment in the 1.x series, but now they are converted to paster equivalents in the 2.0 series, which seem to be familiar if you experimented with 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

You would like to be more flexible in your WSGI stack (ORM selection, template selection, shape selection), Pylons becomes a consolidated choice. This would be my recommended choice as it offers excellent documentation and allows you to experiment with various components.

It is with pleasure to work as a result and work under Apache (production deployment) or autonomously (useful for testing and experimental stage).

so you can do both with Pylons:

• 2 for testing phase ( python standalone)

• 4 for scalable production goals ( FastCGI , assuming that your chosen database may keep up)

The Pylons admin interface is very similar to TurboGears. Here's a toy stand-alone example:

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

to deploy a production class, you can refer to the Apache + FastCGI + mod_rewrite configuration guide, which is available here . It will fit most needs.

Answer 7

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

It works like a charm.

Answer 8

We use clean paste for some of our web services. It’s easy to deploy (with our internal deployment mechanism, we don’t use Paste Deploy or something like that), and it’s nice to minimize the difference between production systems and what works on developer workstations. Caution: we do not expect low latency from the Paste itself due to the heavy nature of our requests. In some crude benchmarking, we did not get fantastic results; it just ended up being controversial due to the expense of our typical request handler. So far, it has worked fine.

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

Answer 9

Apache + mod_wsgi,

Simple, clean. (only four lines of web server configuration), it is easy for other sysadimns to get them around.