WSGI using uWSGI and nginx on Arch Linux

The uWSGI server provides a non-FastCGI method for deploying Python applications with the nginx web server. In coordination with nginx, uWSGI offers great stability, flexibility, and performance. However, to deploy applications with uWSGI and nginx, you must compile nginx manually with the included uwsgi module.

Before you begin installing and configuring the components described in this guide, please make sure you’ve followed our instructions for setting your hostname. Issue the following commands to make sure it is set properly:

hostname
hostname -f

The first command should show your short hostname, and the second should show your fully qualified domain name (FQDN).

Begin by issuing the following command to update your system’s package repositories and install nginx:

pacman -Sy
pacman -S pacman
pacman -S nginx

Issue the following sequence of commands to download and compile all prerequisites and uWSGI:

pacman -S base-devel openssl pcre zlib libxml2 python2
cd /opt
wget http://aur.archlinux.org/packages/uwsgi/uwsgi.tar.gz
tar -zxvf uwsgi.tar.gz
cd /opt/uwsgi
makepkg --asroot
pacman -U uwsgi*.pkg.*

Because you have built these packages from source, you will want to monitor their pages in the Arch User Repository (AUR) so that you’ll be able to recompile the uwsgi package when updates are available.

Issue the following command to download an init script to manage the uWSGI process, located at /etc/rc.d/uwsgi:

cd /opt/
wget -O init-arch.sh http://www.linode.com/docs/assets/700-init-arch.sh
mv /opt/init-arch.sh /etc/rc.d/uwsgi

Create an /etc/conf.d/uwsgi file to specify specific settings for your Python application. The MODULE specifies the name of the Python module that contains your wsgi specification. Consider the following example:

File: /etc/conf.d/uwsgi

1 2	PYTHONPATH=/srv/www/example.com/application MODULE=wsgi_configuration_module

Issue the following sequence of commands to prepare the new init script and log files:

chmod +x /etc/rc.d/uwsgi
touch /var/log/uwsgi.log
chown http /var/log/uwsgi.log

Start uWSGI for the first time by issuing the following command:

/etc/rc.d/uwsgi start

You will want to add the uwsgi daemon to the DAEMONS=() array at the end of the /etc/rc.conf file to ensure that the uWSGI daemon starts following the next reboot cycle.

Create an nginx server configuration that resembles the following for the site where the uWSGI app will be accessible:

File: nginx virtual host configuration

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

server { listen 80; server_name www.example.com example.com; access_log /srv/www/example.com/logs/access.log; error_log /srv/www/example.com/logs/error.log; location / { include uwsgi_params; uwsgi_pass 127.0.0.1:9001; } location /static { root /srv/www/example.com/public_html/static/; index index.html index.htm; } }

All requests to URLs ending in /static will be served directly from the /srv/www/example.com/public_html/static directory. Restart the web server by issuing the following command:

/etc/rc.d/nginx restart

If the Python application you’ve deployed requires more application resources than a single Linode instance can provide, all of the methods for deploying a uWSGI application server are easily scaled to rely on multiple uSWGI instances that run on additional Linodes with the request load balanced using nginx’s upstream capability. Consider our documentation of proxy and software load balancing with nginx for more information. For a basic example configuration, consider the following example:

File: nginx configuration

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

upstream uwsgicluster { server 127.0.0.1:9001; server 192.168.100.101:9001; server 192.168.100.102:9001; server 192.168.100.103:9001; server 192.168.100.104:9001; } server { listen 80; server_name www.example.com example.com; access_log /srv/www/example.com/logs/access.log; error_log /srv/www/example.com/logs/error.log; location / { include uwsgi_params; uwsgi_pass uwsgicluster; } location /static { root /srv/www/example.com/public_html/static/; index index.html index.htm; } }

In this example we create the uwsgicluster upstream, which has five components. One runs locally on the local interface, and four run on the local network interface of distinct Linodes (e.g. the 192.168. addresses or the private “back end” network). The application servers that run on those dedicated application servers are identical to the application servers described above. However, the application server process must be configured to bind to the appropriate network interface to be capable of responding to requests.

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

• Deploy a LEMP Server on Arch Linux
• Configure nginx Proxy Servers