Deploying Python Web Applications with nginx and uWSGI Emperor

uWSGI configuration

Start with this, but read the notes below and change the values accordingly:

[uwsgi]
socket = /srv/myapp/uwsgi.sock
chmod-socket = 775
chdir = /srv/myapp/appdata
master = true
binary-path = /srv/myapp/bin/uwsgi
virtualenv = /srv/myapp
module = flaskapp:app
uid = www-data
gid = www-data
processes = 1
threads = 1
plugins = python3,logfile
logger = file:/srv/myapp/uwsgi.log

Save this file as:

• Ubuntu: /etc/uwsgi-emperor/vassals/myapp.ini
• Fedora: /etc/uwsgi.d/myapp.ini
• Arch Linux: /etc/uwsgi/vassals/myapp.ini (create the directory first and chown it to http: mkdir -p /etc/uwsgi/vassals; chown -R http:http /etc/uwsgi/vassals)

The options are:

• socket — the socket file that will be used by your application. It’s usually a file path (Unix domain socket). You could use a local TCP socket, but it’s not recommended.
• chdir — the app directory.
• binary-path — the uWSGI executable to use. Remove if you didn’t install the (optional) uwsgi package in your virtualenv.
• virtualenv — the virtualenv for your application.
• module — the name of the module that houses your application, and the object that speaks the WSGI interface, separated by colons. This depends on your web framework:
  • For Flask: module = filename:app, where filename is the name of your Python file (without the .py part) and app is the Flask object
  • For Django: module = project.wsgi:application, where project is the name of your project (directory with settings.py). You should also add an environment variable: env = DJANGO_SETTINGS_MODULE=project.settings
  • For Bottle: module = filename:app, where app = bottle.default_app()
  • For Pyramid: module = filename:app, where app = config.make_wsgi_app() (make sure it’s not in a if __name__ == '__main__': block — the demo app does that!)
• uid and gid — the names of the user account to use for your server. Use the same values as in the chown command above.
• processes and threads — control the resources devoted to this application. Because this is a simple hello app, I used one process with one thread, but for a real app, you will probably need more (you need to see what works the best; there is no algorithm to decide). Also, remember that if you use multiple processes, they don’t share data, so you need an out-of-process database if you want that.
• plugins — the list of uWSGI plugins to use. For Arch Linux, use plugins = python (the logfile plugin is always active).
• logger — the path to your app-specific logfile. (Other logging facilities are available, but this one is the easiest, especially for multiple applications on the same server)

You can test your configuration by running uwsgi --ini /path/to/myapp.ini (disable the logger for stderr output or run tail -f /srv/myapp/uwsgi.log in another window).

If you’re using Fedora, there are two configuration changes you need to make globally: in /etc/uwsgi.ini, disable the emperor-tyrant option (which seems to be buggy) and set gid = nginx. We’ll need this so that nginx can talk to your socket.

nginx configuration

We need to configure our web server. Here’s a basic configuration that will get us started:

Save this file as:

• Ubuntu: /etc/nginx/sites-enabled/myapp.conf
• Fedora: /etc/nginx/conf.d/myapp.conf
• Arch Linux: add include /etc/nginx/conf.d/*.conf; to your http directive in /etc/nginx/nginx.conf and use /etc/nginx/conf.d/myapp.conf

server {
    listen 8080;
    server_name localhost myapp.local;

    location / {
        include uwsgi_params;
        uwsgi_pass unix:/srv/myapp/uwsgi.sock;
    }

    location /static {
        alias /srv/myapp/appdata/static;
    }

    location /favicon.ico {
        alias /srv/myapp/appdata/static/favicon.ico;
    }
}

Note that this file is a very basic and rudimentary configuration. This configuration is fine for local testing, but for a real deployment, you will need to adjust it:

• set listen to 443 ssl and create a http→https redirect on port 80 (you can get a free SSL certificate from Let’s Encrypt; make sure to configure SSL properly).
• set server_name to your real domain name
• you might also want to add custom error pages, or change anything else that relates to your web server — consult other nginx guides for details
• nginx might have some server already enabled by default — edit /etc/nginx/nginx.conf to disable it

For Arch Linux

All you need is:

systemctl enable nginx emperor.uwsgi
systemctl start nginx emperor.uwsgi

Verify the service is running with systemctl status emperor.uwsgi

For Fedora

Make sure you followed the extra note about editing /etc/uwsgi.ini and run:

systemctl enable nginx uwsgi
systemctl start nginx uwsgi

Verify the service is running with systemctl status uwsgi

This is enough to get an app working, if you disabled SELinux (if you want to do it, edit /etc/selinux/config and reboot), but if you want to keep SELinux happy, you need to do the following:

setenforce 0
chcon -R system_u:system_r:httpd_t:s0 /srv/myapp/appdata/static
setenforce 1

We now need to install a SELinux policy (that I created for this project). If it doesn’t work, look into audit2allow.

semodule -i nginx-uwsgi.pp

Hopefully, this is enough. In case it isn’t, please read SELinux documentation, and check audit logs.

Also if you’re on Fedora, to make your website accessible from the outside Internet, you need to configure the built-in firewall accordingly — for ports 80/443, use:

firewall-cmd --add-service http
firewall-cmd --add-service https

For Ubuntu

Ubuntu does not ship the uWSGI Emperor service by default. However, you can easily create it. Copy the .service file from the uWSGI systemd documentation to /etc/systemd/system/emperor.uwsgi.service. Change the ExecStart line to:

ExecStart=/usr/bin/uwsgi --ini /etc/uwsgi-emperor/emperor.ini

You can now reload systemd daemons and enable the services:

systemctl daemon-reload
systemctl enable nginx emperor.uwsgi
systemctl start nginx emperor.uwsgi

Verify the service is running with systemctl status emperor.uwsgi