Serving TileStache (or another app) using uWSGI against a web sub-directory

// under application python serving uwsgi web wsgi

uWSGI is extremely promising as an application server given its huge range of options and supported platforms.  For me, however, just getting something seemingly simple up and running successfully was relatively confusing. I’d like to contribute to the documentation when I can, but thought a dedicated page about TileStache as a specific application (and associated configuration) was warranted. It does make more sense now, thankfully.

I want to serve my TileStache application at http://mydomain.com/tiles (taking careful note of the sub-directory present). I’ve chosen an INI-style configuration for my instance and here’s what the final result looks like (loads using uwsgi --ini my_uwsgi.ini):

[uwsgi]
processes = 8
vacuum = true
master = true
socket = %(home)/var/uwsgi.sock
home = /opt/tilestache
mount = /tiles=app.py
need-app = true

The available options for uWSGI are extremely comprehensive and fairly bewildering for someone just starting off. The main issue I faced was the fact the —module option doesn’t support argument passing. This was a big one because documentation like this shows empty rounded brackets and the programmer in me instinctively thought of this as an Python object call. Not so. In order to pass arguments, you either need —eval or to do what I did and create a separate file and mount that. Where I have app.py specified above, this is the definition for said file:

import TileStache
application = TileStache.WSGITileServer('tilestache.cfg')

So that’s uWSGI serving TileStache. The final issue to solve is that of serving against a sub-directory. Once you have your application mounted against the relevant mount point (in my case /tiles), then it’s just a case of telling uWSGI to use this as its SCRIPT_NAME environment variable.

For me, this was telling our webserver (Cherokee) to provide the UWSGI_SCRIPT_NAME, ensuring the UWSGI_ is prepended, as a custom environment variable against the relevant Directory behaviour. Once Cherokee was pointed at the relevant socket and restarted, everything ‘just worked’. In the case of other web servers like Nginx, it would be a case of configuring a location with:

uwsgi_param SCRIPT_NAME /tiles;

And there you have it.

Go Top