Step 6 – do some cleanup
We are going to do some cleanup and set up autostart for Nginx, uWSGI and Php-fpm.
mkdir /var/uwsgi; chown nginx.nginx /var/uwsgi; chmod 770 /var/uwsgi; chown -R root.nginx /var/lib/php; chown -R nginx:nginx /var/lib/php/session; chown -R nginx.nginx /etc/nginx /etc/uwsgi.d /etc/uwsgi.ini; chown -R nginx:nginx /home/webhosting; find /home/webhosting/ -type d -print0 | xargs -0 chmod 0770; # for directories find /home/webhosting/ -type f -print0 | xargs -0 chmod 0660; # for files systemctl enable nginx.service; systemctl restart nginx.service; # autostart enable systemctl enable uwsgi.service; systemctl restart uwsgi.service; # autostart enable systemctl enable php-fpm.service; systemctl restart php-fpm.service; # autostart enable
Install and Configure Nginx as a Reverse Proxy
With uWSGI configured and ready to go, we can now install and configure Nginx as our reverse proxy. This can be downloaded and installed using :
Once Nginx is installed, we can go ahead and edit the main configuration file:
Within this file, next to the existing server block, we will create an additional server block for each of our sites:
The blocks we created will hold the configuration for our uWSGI sites. We’ll cover the directives that we need in the first server block now.
First, we need to tell the server block which port number and domain name that it should respond to. We’ll assume that you have a domain name for each of your sites:
Next, we’ll tell Nginx that we don’t need to worry about a missing favicon. We will then specify the directory where our first site’s static assets were collected for when these files are requested. Nginx can hand them straight to the client from that directory:
Next, we create a catch-all location block that will pass all additional queries straight to uWSGI. We will include the parameters found in the file and pass the traffic to the socket that the uWSGI server sets up:
With that, our first server block is complete.
The second server block for our other site will be almost the same. You can copy and paste the server block we just created to get started. You will need to modify the domain name that the site should respond to, the location of the site’s static files, and the site’s socket file:
When you are finished with this step, save and close the file.
Check the syntax of the Nginx file to make sure you don’t have any mistakes:
If no errors are reported, our file is in good condition.
We have one additional task we have to complete to make our sites work correctly. Since Nginx is handling the static files directly, it needs access to the appropriate directories. We need to give it executable permissions for our home directory, which is the only permission bit it is lacking.
The safest way to do this is to add the Nginx user to our own user group. We can then add the executable permission to the group owners of our home directory, giving just enough access for Nginx to serve the files:
Now, we can start the Nginx server and the uWSGI process:
You should now be able to reach your two projects by going to their respective domain names. Both the public and administrative interfaces should work as expected.
If this goes well, you can enable both of the services to start automatically at boot by typing:
Шаг 5 — Создание файла элементов systemd
Далее мы созадим файл служебных элементов systemd. Создание файла элементов systemd позволит системе инициализации Ubuntu автоматически запускать uWSGI и обслуживать приложение Flask при загрузке сервера.
Для начала создайте файл элементов с расширением в каталоге :
Мы начнем с раздела этого файла, где указываются метаданные и зависимости. Здесь мы разместим описание службы и предпишем системе инициализации запускать ее только после достижения сетевой цели:
/etc/systemd/system/myproject.service
Теперь откроем раздел . Здесь указывается пользователь и группа, от имени которых мы хотим запустить данный процесс. Сделаем владельем процесса учетную запись обычного пользователя, поскольку этот пользователь является владельцем всех соответствующих файлов. Также назначим владельцем группу , чтобы упростить коммуникацию Nginx с процессами uWSGI. Не забудьте заменить приведенное имя пользователя своим именем пользователя:
/etc/systemd/system/myproject.service
Теперь составим карту рабочего каталога и зададим переменную среды , чтобы система инициализации знала, что исполняемые файлы этого процесса находятся в нашей виртуальной среде. Также укажем команду для запуска службы. Systemd требует, чтобы мы указывали полный путь исполняемого файла uWSGI, установленного в нашей виртуальной среде. Мы передадим имя файла конфигурации , который создали в каталоге нашего проекта.
Не забудьте заменить имя пользователя и пути проекта собственными данными:
/etc/systemd/system/myproject.service
/etc/systemd/system/myproject.service
Теперь служебный файл systemd готов. Сохраните и закройте его.
Теперь проверим состояние:
Результат должен выглядеть следующим образом:
Если вы увидите какие-либо ошибки, устраните их, прежде чем продолжить выполнение этого обучающего модуля.
Развертывание сервера uWSGI
Прежде чем вводить развертывание сервера uWSGI, сначала разберитесь в различиях между uwsgi, uWSGI и WSGI:
WSGI(Интерфейс шлюза веб-сервера) — это простой и универсальный протокол интерфейса между веб-сервером и веб-приложением или платформой, определенной для языка Python. Пока веб-сервер и веб-приложение соответствуют протоколу WSGI, они могут быть случайная комбинация.uwsgiЭто проводной протокол на основе двоичного кода, который выполняет ту же функцию, что и протокол WSGI, но принадлежит собственному протоколу сервера uWSGI.uWSGIВеб-сервер, реализующий протокол WSGI, uwsgi, http и другие протоколы.
Установить uWSGI. Здесь устанавливается через pip, либо вы можете скачать исходный код для установки.
Приложение для записи Python server.pyЧтобы отобразить «Hello World» на веб-странице, используйте следующий код:
Запустить сервер uWSGI. Вы можете запустить uWSGI с помощью команды, или вы можете записать параметры в файл конфигурации (inixmljsonyaml) и указать файл конфигурации для запуска uWSGI (команда «uwsgi myapp.ini»).
sudo uwsgi —http-socket :8001 —plugin python —wsgi-file server.py —master —processes 4 —threads 2 —stats 127.0.0.1:9191Параметр —http-socket указывает адрес и порт прослушивания HTTP,Параметр —wsgi-file указывает запись приложения WSGI, uWSGI автоматически найдет объект приложения с именем «application» и вызовет его.Параметр —plugin python указывает uWSGI использовать подключаемый модуль python для анализа файла.Параметр —master настраивает главный процесс—processes параметр для настройки нескольких процессов—threads параметр для настройки многопоточностиПараметр —stats настроен для доступа к информации о состоянии по указанному адресу, как показано на рисунке ниже, для получения текущей информации в формате JSON по адресу «127.0.0.1:9191»
Ввод URL-адреса браузера «http://localhost:8001″, Вы можете получить доступ к результату выполнения server.py «Hello World!»
nginx и uWSGI и test.py
Давайте еще раз запустим приложение «hello world» test.py.
uwsgi --socket :8001 --wsgi-file test.py
Это почти так же, как и раньше, за исключением того, что один из вариантов отличается:
socket :8001: использует протокол uwsgi, порт 8001
В то же время nginx настроен на связь с uWSGI через этот порт и с внешним миром через порт 8000. Посетите:
Теперь наш стек будет следующим:
the web client <-> the web server <-> the socket <-> uWSGI <-> Python
Между тем, вы можете попытаться взглянуть на вывод uswgi по адресу http://example.com:8001 — но вполне вероятно, что он не будет работать, потому что ваш браузер работает по протоколу http, а не через протокол uWSGI, хотя вы должны увидеть вывод uWSGI в терминале.
Set Up a Flask Application
Now that you are in your virtual environment, we can install Flask and uWSGI and get started on designing our application:
Create a Sample App
Now that we have Flask available, we can create a simple application. Flask is a micro-framework. It does not include many of the tools that more full-featured frameworks might, and exists mainly as a module that you can import into your projects to assist you in initializing a web application.
While your application might be more complex, we’ll create our Flask app in a single file, which we will call :
Within this file, we’ll place our application code. Basically, we need to import flask and instantiate a Flask object. We can use this to define the functions that should be run when a specific route is requested. We’ll call our Flask application in the code to replicate the examples you’d find in the WSGI specification:
This basically defines what content to present when the root domain is accessed. Save and close the file when you’re finished.
You can test your Flask app by typing:
Visit your server’s domain name or IP address followed by the port number specified in the terminal output (most likely ) in your web browser. You should see something like this:
When you are finished, hit CTRL-C in your terminal window a few times to stop the Flask development server.
Create the WSGI Entry Point
Next, we’ll create a file that will serve as the entry point for our application. This will tell our uWSGI server how to interact with the application.
We will call the file :
The file is incredibly simple, we can simply import the Flask instance from our application and then run it:
Save and close the file when you are finished.
Step 1 – prepare CentOS, install necessary repos including support for PHP 7.4
First at all, we need to add repos and install current Nginx, uWSGI and PHP packages.
# add needed a repo Epel because of other dependencies yum -y install epel-release # remove Nginx shipped with CentOS7 if was installed yum -y remove nginx # add oficial Nginx repo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm # install latest Nginx, Let's encrypt, uWSGI and other necessary packages yum -y install nginx uwsgi uwsgi-devel uwsgi-plugin-common uuid-devel libcap-devel letsencrypt # install a repo Remi because of PHP packages rpm -Uvh http://rpms.remirepo.net/enterprise/remi-release-7.rpm # install PHP core packages yum -y --enablerepo=remi,remi-php74 install php-fpm php-common # install popular PHP extension package that are suitable for running e.g. an instance of WordPress website yum -y --enablerepo=remi,remi-php74 install php-opcache php-pecl-apcu php-cli php-pear php-pdo php-mysqlnd php-pgsql php-pecl-mongodb \ php-pecl-memcache php-pecl-memcached php-gd php-mbstring php-mcrypt php-xml php-zip php-php-pecl-geoip
We are going to prepare folders for additional Nginx config files and Let’s encrypt web directory shared by all virtual hosts that is used like a webroot for SSL certificate confirmation.
# run these bash commands for creating necessary directories and proper permission settings mkdir /etc/nginx/domains /etc/nginx/snippets; chown -R nginx.nginx /etc/nginx /etc/uwsgi.d /etc/uwsgi.ini; mkdir -p /var/www/letsencrypt/.well-known/acme-challenge; chown -R nginx.nginx /var/www/letsencrypt; chmod -R 770 /var/www/letsencrypt/; mkdir /var/uwsgi; chown nginx.nginx /var/uwsgi; chmod 770 /var/uwsgi; chown -R root.nginx /var/lib/php; chown -R nginx:nginx /var/lib/php/session;
Conclusion
In this guide, we’ve created a simple Flask application within a Python virtual environment. We create a WSGI entry point so that any WSGI-capable application server can interface with it, and then configured the uWSGI app server to provide this function. Afterwards, we created Systemd service unit file to automatically launch the application server on boot. We created an Nginx server block that passes web client traffic to the application server, relaying external requests.
Flask is a very simple, but extremely flexible framework meant to provide your applications with functionality without being too restrictive about structure and design. You can use the general stack described in this guide to serve the flask applications that you design.
Step 6 — Configuring Nginx to Proxy Requests
Your uWSGI application server should now be up and running, waiting for requests on the socket file in the project directory. Now you can configure Nginx to pass web requests to that socket using the protocol.
Begin by creating a new server block configuration file in Nginx’s directory. Name it to stay consistent with the rest of the guide:
Open up a server block and tell Nginx to listen on the default port . Also tell it to use this block for requests for your server’s domain name:
/etc/nginx/sites-available/myproject
Next, add a location block that matches every request. Within this block, you’ll include the file that specifies some general uWSGI parameters that need to be set. Then you’ll pass the requests to the socket you defined using the directive:
/etc/nginx/sites-available/myproject
Save and close the file when you’re finished.
To enable the Nginx server block configuration you’ve just created, link the file to the directory:
With the file in that directory, you can test for syntax errors by running the following:
If this returns without indicating any issues, restart the Nginx process to read the new configuration:
Now adjust the firewall again. You no longer need access through port , so you can remove that rule:
After, you’ll allow access to the Nginx server:
You should now be able to navigate to your server’s domain name in your web browser:
You should see your application output:
If you encounter any errors, try checking the following:
- : checks the Nginx error logs.
- : checks the Nginx access logs.
- : checks the Nginx process logs.
- : checks your Flask app’s uWSGI logs.
Дальнейшая конфигурация
Хорошей практикой так же будет, если вы создадите например рядом с файлом manage.py отдельный bash файл для запуска/перезапуска приложения Django. Например можно создать server.sh со следующим содержимым:
#!/bin/bash
ROOT=`pwd`
name=app_django
prefix=prefix_name
socket=/tmp/$prefix-$name.sock
pidfile=$ROOT/logs/run/$name.pid
errlog=$ROOT/logs/$name.error.log
python=$WORKON_HOME/$prefix/bin/python
cd $ROOT
case "$1" in
"start")
uwsgi --chdir=$ROOT --module=root.wsgi \
--env DJANGO_SETTINGS_MODULE=root.settings \
--master --pidfile=$pidfile \
--socket=$socket --processes=2 --harakiri=120 --post-buffering=1 \
--max-requests=4000 --vacuum --home=$WORKON_HOME/$prefix \
--daemonize=$errlog
chmod o+w $socket
;;
"stop")
kill -9 `cat $pidfile`
;;
"restart")
./server.sh stop
./server.sh start
;;
*)
echo "Usage: ./server.sh {start|stop|restart}"
;;
esac
Так же необходимо будет изменить права доступа к файлу chmod +x server.sh. Теперь для запуска приложения Django можно использовать команду
./server.sh start
А для перезапуска
./server.sh restart
Spread the love
Step 3 — Setting Up a Flask Application
Now that you are in your virtual environment, you can install Flask and uWSGI and get started on designing your application.
First, install with the local instance of to ensure that your packages will install even if they are missing wheel archives:
Note: Regardless of which version of Python you are using, when the virtual environment is activated, you should use the command (not ).
Next, install Flask and uWSGI:
After installation is complete, you can begin using Flask.
Creating a Sample App
Now that you have Flask available, you can create a simple application. As you may recall, Flask is a microframework and doesn’t include many of the tools that more full-featured frameworks might. Flask exists primarily as a module that you can import into your projects to assist you in initializing a web application.
While your application might be more complex, you’ll create your Flask app in a single file. You can create the file using your favorite text editor. For this example, we will use and name it :
The application code will live in this file. It will import Flask and instantiate a Flask object. You can use this to define the functions that should be run when a specific route is requested:
~/myproject/myproject.py
This defines what content to present when the root domain is accessed. Save and close the file when you’re finished. If you’re using you can do this by pressing then and .
If you followed the initial server setup guide, you should have a UFW firewall enabled. To test the application, you need to allow access to port :
Now test your Flask app:
You will receive output like the following, including a helpful warning reminding you not to use this server setup in production:
Visit your server’s IP address followed by in your web browser:
You should see something like the following:
When you are finished, hit in your terminal window to stop the Flask development server.
Creating the WSGI Entry Point
Next, you’ll create a file that will serve as the entry point for your application. This will tell your uWSGI server how to interact with it.
First create and name the file :
In this file, import the Flask instance from your application and then run it:
~/myproject/wsgi.py
Save and close the file when you are finished.
Step 3 – compile uWSGI Python 3.8 plugin
We want to serve Python files using uWSGI application server and therefore we need to compile the appropriate uwsgi-python plugin. We are going to prepare plugin for python 3.8. Python 3.8 is needed to compile into the folder /opt/python38 because Python 2.7 is shipped with CentOS 7.
Howto compile and install the latest Python 3.8 check out my another post.
For a compilation of python38_plugin.so I used an ugly hack with symlinks because there is no option for a setting of path to Python 3.8. (e.g. /opt/python38/bin/python3.8). Does anyone know?
# Python 3.8 has to be presented in the directory /opt/python38 and we are going to create uWSGI plugin cd /tmp # first at all we are going to make the ugly hack. We set temporary python 3.8 as a general Python interpret of CentOS 7. rm -f /usr/bin/python; ln -s /opt/python38/bin/python3 /usr/bin/python PYTHON=python3.8; /usr/sbin/uwsgi --build-plugin "/usr/src/uwsgi/2.0.17.1/plugins/python/ python38" chmod 644 ./python38_plugin.so ; mv -f ./python38_plugin.so /usr/lib64/uwsgi/ # we are going to get back shipped Python 2.7 rm -f /usr/bin/python; ln -s /usr/bin/python2 /usr/bin/python # test a Python version within an ugwsi plugin file strings /usr/lib64/uwsgi/python38_plugin.so|grep '3.8'
Создание проекта Django
Теперь нужно создать два виртуальных окружения и запустить два проекта.
Создание первого проекта Django
Создайте виртуальное окружение с помощью команд, доступных благодаря инструменту virtualenvwrapper.
Чтобы создать первое виртуальное окружение, введите:
Эта команда создаст виртуальное окружение по имени firstsite, а также установит локальную версию Python и pip, которые можно использовать для создания изолированной среды разработки проекта. Командная строка изменится, указывая, что текущей средой является виртуальная среда Python
В скобках указано имя текущего виртуального окружения. Теперь всё программное обеспечение, загруженное с помощью pip, будет установлено в индивидуальное окружение первого проекта и никак не повлияет на общее состояние системы.
Сначала нужно установить Django:
Теперь создайте первый тестовый проект:
Эта команда создаст в домашнем каталоге каталог firstsite. В нём хранится сценарий для управления новым проектом и ещё один одноимённый каталог, в котором будет находиться код проекта.
Откройте каталог первого уровня:
Для начала нужно переместить БД, чтобы инициализировать базу данных SQLite для проекта.
Примечание: При желании можно создать базу данных для приложения самостоятельно, но это выходит за рамки данного руководства.
Теперь в домашнем каталоге есть файл БД по имени db.sqlite3. Создайте администратора.
Выберите имя пользователя, укажите контактный адрес электронной почты, а затем выберите и подтвердите пароль.
Затем откройте файл настроек проекта:
Теперь нужно создать отдельный каталог для хранения статических файлов сайта. Так Nginx сможет обслуживать их напрямую, а это улучшит производительность. Поместите каталог static в корневом каталоге проекта. Добавьте в конец конфигурационного файла следующую строку:
Сохраните и закройте файл. Соберите статические файлы в этом каталоге:
В каталоге проекта появится новый каталог static.
Теперь протестируйте проект, временно запустив сервер разработки.
Это запустит сервер разработки на порт 8080. В браузере посетите свой домен или IP:
На экране должна появиться такая страница:
Добавьте в ссылку сегмент /admin, чтобы получить доступ к форме аутентификации администратора. Введите учётные данные администратора, и на экране появится панель управления.
После этого можно остановить сервер разработки. Нажмите CTRL-C в терминале. Теперь можно приступать к разработке второго проекта.
Разработка второго проекта
Второй проект создаётся точно так же, как первый.
Вернитесь в домашний каталог и создайте второе виртуальное окружение. Установите Django.
После этого откроется окружение нового проекта.
Создайте второй проект и откройте его каталог:
Инициализируйте базу данных и создайте пользователя с правами администратора:
Откройте файл settings:
Добавьте каталог статических файлов строку:
Сохраните и закройте файл. Соберите статические файлы в этот каталог.
Запустите сервер разработки:
Ссылка на интерфейс администратора:
Чтобы остановить сервер, нажмите CTRL-C.
Отключение виртуального окружения
Теперь нужно отключить виртуальное окружение, поскольку разработка проектов завершена:
Чтобы вернуться в виртуальное окружение любого из проектов, введите:
В дальнейшей работе виртуальное окружение не нужно, потому отключите его:
Установка php-fpm на CentOS 7
Устанавливаем php-fpm и некоторые модули, которые скорее всего пригодятся в дальнейшей работе:
# yum install -y php-fpm php-cli php-mysql php-gd php-ldap php-odbc php-pdo php-pecl-memcache php-pear php-xml php-xmlrpc php-mbstring php-snmp php-soap
Так же я предлагаю установить APC — бесплатный и открытый кэшер кода PHP, который кэширует и оптимизирует промежуточный код PHP, ускоряя его исполнение. Установим APC из хранилища PHPpecl. Для того, чтобы скомпилировать пакет APC нужно установить Centos Development tools.
# yum install -y php-devel # yum groupinstall 'Development Tools'
Компилируем APC:
# pecl install apc
На все вопросы просто жмем enter, выбирая параметры по-умолчанию.
Теперь отредактируем /etc/php.ini как нам рекомендует инсталлятор:
# mcedit /etc/php.ini
Задаем параметр cgi.fix_pathinfo=0 и добавляем в конце строку extension=apc.so
Заодно установим сразу же часовой пояс: date.timezone = «Europe/Moscow»
Создадим файл настроек APC:
# mcedit /etc/php.d/apc.ini extension = apc.so apc.enabled = 1 apc.cache_by_default = 1 apc.ttl = 7200 apc.shm_size = 64M apc.max_file_size = 4M apc.stat = 1
Добавляем php-fpm в автозагрузку:
# systemctl enable php-fpm.service ln -s '/usr/lib/systemd/system/php-fpm.service' '/etc/systemd/system/multi-user.target.wants/php-fpm.service'
И запускаем:
# systemctl start php-fpm.service
Проверяем:
# netstat -tulpn | grep php-fpm tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 2907/php-fpm: maste
Install the Components from the CentOS and EPEL Repositories
Our first step will be to install all of the pieces that we need from the repositories. We will need to add the EPEL repository, which contains some extra packages, in order to install some of the components we need.
You can enable the EPEL repo by typing:
Once access to the EPEL repository is configured on our system, we can begin installing the packages we need. We will install , the Python package manager, in order to install and manage our Python components. We will also get a compiler and the Python development files needed to build uWSGI. We’ll install Nginx now as well.
You can install all of these components by typing:
Definitions and Concepts
Clarifying Some Terms
Before we jump in, we should address some confusing terminology associated with the interrelated concepts we will be dealing with. These three separate terms that appear interchangeable, but actually have distinct meanings:
- WSGI: A Python spec that defines a standard interface for communication between an application or framework and an application/web server. This was created in order to simplify and standardize communication between these components for consistency and interchangeability. This basically defines an API interface that can be used over other protocols.
- uWSGI: An application server container that aims to provide a full stack for developing and deploying web applications and services. The main component is an application server that can handle apps of different languages. It communicates with the application using the methods defined by the WSGI spec, and with other web servers over a variety of other protocols. This is the piece that translates requests from a conventional web server into a format that the application can process.
- uwsgi: A fast, binary protocol implemented by the uWSGI server to communicate with a more full-featured web server. This is a wire protocol, not a transport protocol. It is the preferred way to speak to web servers that are proxying requests to uWSGI.
WSGI Application Requirements
The WSGI spec defines the interface between the web server and application portions of the stack. In this context, “web server” refers to the uWSGI server, which is responsible for translating client requests to the application using the WSGI spec. This simplifies communication and creates loosely coupled components so that you can easily swap out either side without much trouble.
The web server (uWSGI) must have the ability to send requests to the application by triggering a defined “callable”. The callable is simply an entry point into the application where the web server can call a function with some parameters. The expected parameters are a dictionary of environmental variables and a callable provided by the web server (uWSGI) component.
In response, the application returns an iterable that will be used to generate the body of the client response. It will also call the web server component callable that it received as a parameter. The first parameter when triggering the web server callable will be the HTTP status code and the second will be a list of tuples, each of which define a response header and value to send back to the client.
With the “web server” component of this interaction provided by uWSGI in this instance, we will only need to make sure our applications have the qualities described above. We will also set up Nginx to handle actual client requests and proxy them to the uWSGI server.
Create a WSGI Application
Next, we will create an incredibly simple WSGI application using the WSGI specification requirements we discussed earlier. To reiterate, the application component that we must provide should have the following properties:
- It must provide an interface through a callable (a function or other language construct that can be called)
- The callable must take as parameters a dictionary containing environmental variable-like key-value pairs and a callable that is accessible on the server (uWSGI).
- The application’s callable should return an iterable that will produce the body to send the client.
- The application should call the web server’s callable with the HTTP status and request headers.
We will write our application in a file called in our application directory:
Inside of this file, we will create the simplest WSGI compliant application we can. As with all Python code, be sure to pay attention to the indentation:
The above code constitutes a complete WSGI application. By default, uWSGI will look for a callable called , which is why we called our function . As you can see, it takes two parameters.
The first we called because it will be an environmental variable-like key-value dictionary. The second is called and is the name the app will use internally to refer to the web server (uWSGI) callable that is sent in. Both of these parameter names were simply selected because of their use in the examples in the PEP 333 spec that defines WSGI interactions.
Our application must take this information and do two things. First, it must call the callable it received with an HTTP status code and any headers it wants to send back. In this case, we are sending a “200 OK” response and setting the header to .
Secondly, it needs to return with an iterable to use as the response body. Here, we’ve just used a list containing a single string of HTML. Strings are iterable as well, but inside of a list, uWSGI will be able to process the entire string with one iteration.
In a real world scenario, this file would likely be used as a link to the rest of your application code. For instance, Django projects include a file by default that translates requests from the web server (uWSGI) to the application (Django). The simplified WSGI interface stays the same regardless of how complex the actual application code is. This is one of the strengths of the interface.
Save and close the file when you are finished.
To test out the code, we can start up uWSGI. We will tell it to use HTTP for the time being and to listen on port . We will pass it the name of the script (suffix removed):
Now, if you visit your server’s IP address or domain name in your web browser followed by , you should see the first level header text we passed as the body in our file:
Stop the server with CTRL-C when you have verified that this works.
We’re done with designing our actual application at this point. You can deactivate our virtual environment if you desire:
Create an Upstart File to Manage the App
We can launch a uWSGI instance at boot so that our application is always available. We will place this in the directory that Upstart checks. We’ll be calling this :
First, we can start out with a description of the service and pick out the system runlevels where it should automatically run. The standard user runlevels are 2 through 5. We will tell Upstart to stop the service when it’s on any runlevel outside of this group (such as when the system is rebooting or in single user mode):
Next, will tell Upstart about which user and group to run the process as. We want to run the application under our own account (we’re using in this guide, but you should substitute your own user). We want to set the group to the user that Nginx uses however. This is necessary because the web server needs to be able to read and write to the socket that our file will create:
Next, we’ll run the actual commands to start uWSGI. Since we installed uWSGI into a virtual environment, we have some extra work to do. We could just provide the entire path to the uWSGI executable, but instead, we will activate the virtual environment. This would make it easier if we were relying on additional software installed in the environment.
To do this, we’ll use a block. Inside, we’ll change to our application directory, activate the virtual environment (we must use in scripts instead of ), and start the uWSGI instance pointing at our file:
With that, our Upstart script is complete. Save and close the file when you are finished.
Now, we can start the service by typing:
We can verify that that it was started by typing:
This will start automatically on boot. You can stop the service at any time by typing:
