Skipole WSGI generator.
Skipole WSGI generator.
skipole is used to create a project which results in a wsgi application. Once you have produced such an application you will want to serve it via a web server. The instructions here describe how nginx and uwsgi can be used to serve your application whenever your debian-based server is powered up.
These instructions assume you have no other web server running (so port 80 is free), and you are familiar with shell commands, changing directories, creating text files and setting permissions. You should also have used skipole to create an application (best start with something simple!).
In this example nginx acts as the web server, and proxies calls to the uwsgi application server which is running your wsgi python application. The settings here use default values provided by the operating system to keep the setup simple.
skipole must be installed and available on the Python path.
Using apt-get (you may have to use 'sudo' an awful lot with every command), install the package nginx which includes nginx-common and ngix-full, (ngix-core on Linux Mint) and then install the packages uwsgi and uwsgi-plugin-python3
Use your browser to connect to 'localhost' and you should see the nginx web service running:
Welcome to nginx!
If you see this page, the nginx web server is successfully installed and working. Further configuration is required.
For online documentation and support please refer to nginx.org.
Commercial support is available at nginx.com.
Thank you for using nginx.
So nginx is running and serving a default web page.
Assuming you have created an application and have the 'projectfiles' directory. For the purpose of these instructions we will use the project 'skitest', so wherever skitest appears in the text below, substitute the name of your own project.
Edit skitest.py to remove skilift, skiadmin and the development web service.
You will need to use sudo or to be superuser to use most of these commands. Please only continue if you are confident of your capability, as superuser you can damage your system.
Copy projectfiles into the /opt directory.
uwsgi will be running your project with user www-data, therefore to allow uwsgi to have access to these files, give them user and group of www-data. So from within /opt
chown -R www-data:www-data projectfiles
The debian installation of uwsgi very conveniently creates two directories:
/etc/uwsgi/apps-available
and
/etc/uwsgi/apps-enabled
The first apps-available directory acts as a storage area, and can contain a uwsgi ini file, if however the ini file appears in the second apps-enabled directory, then on server boot up uwsgi is started using that ini file.
Rather than place the ini file under apps-enabled you should create it in apps-available, and then make a link from apps-enabled to the ini file in apps-available, so the service can be enabled, or deleted by removing the link, without losing the ini file.
So create the following skitest.ini file under /etc/uwsgi/apps-available
[uwsgi]
plugin = python3
wsgi-file = /opt/projectfiles/skitest.py
chdir = /opt/projectfiles/
This may seem to be a very short ini file, however it actually extends the default ini file provided by the operating system. If you are interested, the defaults can be found at /etc/default/uwsgi and /usr/share/uwsgi/conf/default.ini
The ini file above contains three instructions:
plugin = python3, enables uwsgi to call skitest.py with python3
wsgi-file informs uwsgi of the location of skitest.py
chdir changes the working directory, so any local packages imported by skitest.py can be found.
Then once this file is created, make a link from the apps-enabled directory:
ln -s /etc/uwsgi/apps-available/skitest.ini /etc/uwsgi/apps-enabled/
Now, when the server is rebooted wsgi will run and open a unix socket at:
/run/uwsgi/app/skitest/socket
If you reboot, (or restart the service with command "service uwsgi restart") and list the above directory you should see 'socket' listed.
As default nginx is serving a simple html page, we now need it to proxy requests to the above socket. In a similar manner to the uwsgi setup, the debian system has two directories:
/etc/nginx/sites-available
/etc/nginx/sites-enabled
You will see under sites-available a default configuration file, and under sites-enabled a link to that file, which is the current enabled default site.
Under /etc/nginx/sites-available create another configuration file skitest.conf:
upstream skitest {
server unix:///run/uwsgi/app/skitest/socket;
}
server {
server_name _;
location / {
include uwsgi_params;
uwsgi_pass skitest;
}
}
The server_name _; directive above is a none-match with any valid name, in the case of a none-match nginx will use the first server block, and since there is only one, this catches everything without having to put in a name, domain name or ip address.
Then, within directory /etc/nginx/sites-enabled delete the default link, and create a new link to skitest.conf:
rm default
ln -s /etc/nginx/sites-available/skitest.conf /etc/nginx/sites-enabled/
Now reboot the server or restart nginx with command "service nginx restart", keep your fingers crossed, open a browser, and call the ip address of your web server. If you are very lucky you will see your application served in all its glory!
An alternative nginx configuration could be used if static CSS files and images are held under css and images directories beneath the project static folder:
upstream skitest {
server unix:///run/uwsgi/app/skitest/socket;
}
server {
server_name _;
root /opt/projectfiles/skitest/static;
location / {
include uwsgi_params;
uwsgi_pass skitest;
}
location /css/ {
try_files $uri $uri/ =404;
}
location /images/ {
try_files $uri $uri/ =404;
}
}
This causes nginx to serve the static files directly, without using uwsgi or the Python application.