Первое что нужно это установить python и pip.
Далее устанавливаем систему виртуального окружения:
1 |
pip install virtualenv |
Создаем виртуальное окружение, где будет работать наше приложение (при этом у данного приложения будет собственная копия питона и всех необходимых ему библиотек).
1 |
virtualenv mypython |
Активация виртуального окружения, из которого потом и будут выполнятся все команды по запуску или установки библиотек используют команду:
1 |
<span class="nb">source </span>mypython/bin/activate |
Для выхода из виртуального окружения используют команду:
1 |
deactivate |
Если для приложения необходима БД, то создаем базу дынных и пользователя, которому предоставляем доступ:
1 2 |
<span class="kwd">CREATE DATABASE 'appdb';<br />CREATE</span> <span class="kwd">USER</span> <span class="str">'username'</span><span class="pun">@</span><span class="str">'localhost'</span><span class="pln"> IDENTIFIED </span><span class="kwd">BY</span> <span class="str">'password'</span><span class="pun">;</span> <span class="kwd">GRANT</span> <span class="kwd">ALL</span><span class="pln"> PRIVILEGES </span><span class="kwd">ON</span> <span class="kwd">appdb</span><span class="pun">.*</span> <span class="kwd">TO</span> <span class="str">'username'</span><span class="pun">@</span><span class="str">'localhost'</span><span class="pln"> IDENTIFIED </span><span class="kwd">BY</span> <span class="str">'password'</span><span class="pun">;</span> |
Далее устанавливаем Gunicorn.
Gunicorn — автономный веб-сервер с обширной функциональностью, предоставленной в удобном виде. Он изначально поддерживает различные фреймворки и адаптеры, что делает его чрезвычайно простой в использовании прямой заменой для многих серверов разработки.
pip install gunicorn
Проверка работоспособности:
gunicorn [опция] [опция2] .. [файл wsgi]
gunicorn helloworld.wsgi:application
Как уже было сказано, сервер Gunicorn очень гибок, его очень просто подстроить согласно требованиям пользователя или проекта.
[!] Важно: Все перечисленные ниже настройки и параметры конфигураций необходимо «сцепить» (внести один за другим), чтобы запустить gunicorn и обслуживать приложение. После запуска сервера изменять настройки нельзя. Любая использованная опция должна сопровождаться файлом WSGI, содержащим точку входа в приложение.
Пример:
# Чтобы просто запустить сервер (как показано выше):
gunicorn -b 0.0.0.0:8080 wsgi
# Запустить сервер и 5 процессов:
gunicorn -b 0.0.0.0:8080 --workers=5 wsgi
Подсчет процессов
В целом, считается, что приложения зависят скорее от I/O, чем от CPU. Это значит, что узкое место вызвано не вычислительной мощностью виртуального сервера, а диском. Идея такова: пока один процесс занят дисковыми операциями, другой все еще использует CPU для обработки запросов.
Потому рекомендуемое количество процессов, как правило, вычисляется по следующей формуле:
# (2 Workers * CPU Cores) + 1
# ---------------------------
# For 1 core -> (2*1)+1 = 3
# For 2 cores -> (2*2)+1 = 5
# For 4 cores -> (2*4)+1 = 9
Указать количество процессов можно с помощью аргумента —workers=[n].
# Синтаксис: gunicorn --workers=[количество_процессов]# Пример: gunicorn --workers=5
Примечание: такой сценарий не сработает с неблокируемыми процессами.
Настройки сокетов
Связывание сокетов выполняется следующим образом:
# Синтаксис: gunicorn -b [адрес:порт]# Пример: gunicorn -b 127.0.0.1:8080
1 |
gunicorn myproject.wsgi:application --bind 111.222.333.44:8000 #пишете ваш ip |
Примечание: когда приложение прослушивает входящие соединения на 127.0.0.1, доступ к нему можно получить только локально. При использовании 0.0.0.0, оно также будет принимать соединения извне.
Выбор типа процесса
Как уже было сказано, Gunicorn предоставляет возможность использовать разные типы процессов.
В большинстве случаев используется sync – стандартный процесс, установленный по умолчанию и, следовательно, не требующий подробной настройки.
Что касается других процессов – имейте в виду, их необходимо установить как зависимости.
# Синтаксис: gunicorn -k [процесс]# Пример: gunicorn -k sync
# или: gunicorn -k gevent
Доступные типы процессов:
- sync
- eventlet
- gevent
- tornado
Количество одновременных подключений для процессов Eventlet / Gevent
Чтобы изменить количество одновременных подключений для процессов Eventlet и Gevent:
# Синтаксис: gunicorn -k [процесс] --worker-connections [количество]# Пример: gunicorn -k gevent --worker-connections 1001
Журналы доступа
Чтобы явно определить файл для ведения журнала доступа:
# Синтаксис: gunicorn --log-file [файл]# Пример: gunicorn --log-file error_logs.log
По умолчанию данная опция имеет значение None.
Журналы ошибок
Чтобы указать файл для ведения журнала ошибок, используйте:
# Синтаксис: gunicorn --access-logfile [файл]# Пример: gunicorn --access-logfile acclogs
Уровни журналов
Это необходимо для повышения степени детализации результата, выведенного журналами ошибок. Доступные уровни:
- debug
- info
- warning
- error
- critical
# Синтаксис: gunicorn --log-level [уровень]# Пример: gunicorn --log-level error
Наименование процессов
При использовании утилит отслеживания процессов (например, top) данная настройка может быть очень полезной, так как позволяет дать процессу более содержательное имя.
# Синтаксис: gunicorn --name [имя]# Пример: gunicorn --name my_application
Настройка Nginx
Настроив и запустив Gunicorn, нужно настроить Nginx, чтобы он мог взаимодействовать с сервером Gunicorn при запуске приложения. Для этого нужно отредактировать nginx.conf, конфигурационный файл Nginx.
Чтобы открыть данный файл в редакторе nano, запустите:
sudo nano /etc/nginx/nginx.conf
Затем замените содержимое файла приведеными ниже конфигурациями, чтобы Nginx был запущен как инвертированный прокси и взаимодействовал с приложением.
Примечание: чтобы активировать поддрежку SSL, пожалуйста, прочтите статью «Создание SSL-сертификата на Nginx».
Пример конфигураций для веб-приложения:
worker_processes 1;
events {
worker_connections 1024;
}
http {
sendfile on;
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/xml text/css
text/comma-separated-values
text/javascript
application/x-javascript
application/atom+xml;
# Configuration containing list of application servers
upstream app_servers {
server 127.0.0.1:8080;
# server 127.0.0.1:8081;
# ..
# .
}
# Configuration for Nginx
server {
# Running port
listen 80;
# Settings to serve static files
location ^~ /static/ {
# Example:
# root /full/path/to/application/static/file/dir;
root /app/static/;
}
# Serve a static file (ex. favico)
# outside /static directory
location = /favico.ico {
root /app/favico.ico;
}
# Proxy connections to the application servers
# app_servers
location / {
proxy_pass http://app_servers;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
}
}
}
Завершив редактирование конфигураций, нажмите CTRL+X, чтобы сохранить изменения и выйти, а затем Y для подтверждения.
Чтобы перезапустить Nginx:
sudo service nginx stop
sudo service nginx start
Статика
К сожалению, статика к нашему проекту еще не подключена. И вы можете в этом убедиться, сделав python manage.py syncdb
, затем перезапустить gunicorn и зайти в админку (ваш_ip:8000/admin). Будет все без стилей.
Разместим статику в папке проекта.
Открываем settings.py либо в вашем любимом редакторе, либо через nano.
1 2 |
nano settings.py |
и прописываем static_root
1 2 |
STATIC_ROOT = '/opt/myenv/myproject/static/' |
сохраняем и выходим
из папки проекта запускаем
1 2 |
python manage.py collectstatic |
в папке проекта появится папка с именем static
13) Настроим nginx
перейдем по следующему пути
1 2 |
cd /etc/nginx/sites-available/ |
открываем файлик default
1 2 |
nano default |
Удаляем оттуда все и пишем
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
server { listen 80; server_name 111.222.333.44; #либо ip, либо доменное имя access_log /var/log/nginx/example.log; location /static/ { root /opt/myenv/myproject/; expires 30d; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $server_name; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } |
Сохраняем, выходим.
Supervisor.
Чтобы наше приложение стратовало после любого непредвиденного ребута или сбоя, нам нужно обзавестись supervisor-ом.
Установим supervisor
1 2 |
apt-get install supervisor |
Создадим конфиг файл для gunicorn
1 2 3 |
cd /opt/myenv/myproject/myproject #лучше делать именно в каталоге с settings.py touch gunicorn.conf.py |
Открываем на редактирование
1 2 |
nano gunicorn.conf.py |
Вносим
1 2 3 4 |
bind = '127.0.0.1:8000' workers = 3 user = "nobody" |
создадим конфиг файл для супервизора
1 2 3 |
cd /etc/supervisor/conf.d/ touch myproject.conf |
Откроем
1 2 |
nano myproject.conf |
Внутрь внесем
1 2 3 4 5 6 7 |
[program:myproject] command=/opt/myenv/bin/gunicorn myproject.wsgi:application -c /opt/myenv/myproject/myproject/gunicorn.conf.py directory=/opt/myenv/myproject user=nobody autorestart=true redirect_stderr=true |
Команды для supervisor
Добавление в системные службы:
wget supervisord.service -O /usr/lib/systemd/system/supervisord.service
- start service
systemctl start supervisord
- view service status:
systemctl status supervisord
- auto start service on system startup:
systemctl enable supervisord
1 2 3 4 5 |
supervisorctl reread supervisorctl update supervisorctl status myproject supervisor restart myproject |
После старта проверяем свой сайт в браузере. Должен работать.
http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/
Однако в моем случае с такой настройкой supervisord возникла проблема приложение никак не хотело стартовать:
Создал скрипт:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
#!/bin/bash NAME="hello_app" # Name of the application DJANGODIR=/webapps/hello_django/hello # Django project directory SOCKFILE=/webapps/hello_django/run/gunicorn.sock # we will communicte using this unix socket USER=hello # the user to run as GROUP=webapps # the group to run as NUM_WORKERS=3 # how many worker processes should Gunicorn spawn DJANGO_SETTINGS_MODULE=hello.settings # which settings file should Django use DJANGO_WSGI_MODULE=hello.wsgi # WSGI module name echo "Starting $NAME as `whoami`" # Activate the virtual environment cd $DJANGODIR source ../bin/activate export DJANGO_SETTINGS_MODULE=$DJANGO_SETTINGS_MODULE export PYTHONPATH=$DJANGODIR:$PYTHONPATH # Create the run directory if it doesn't exist RUNDIR=$(dirname $SOCKFILE) test -d $RUNDIR || mkdir -p $RUNDIR # Start your Django Unicorn # Programs meant to be run under supervisor should not daemonize themselves (do not use --daemon) exec ../bin/gunicorn ${DJANGO_WSGI_MODULE}:application \ --name $NAME \ --workers $NUM_WORKERS \ --user=$USER --group=$GROUP \ --bind=unix:$SOCKFILE \ --log-level=debug \ --log-file=- view rawgunicorn_start.bash hosted with ❤ by GitHub |
Назовем его gunicorn_start
После чего проверяем запуск приложения.
Для запуска из supervisor создаем конфигурационный файл такого содержания:
[program:hello] | |
command = /webapps/hello_django/bin/gunicorn_start ; Command to start app | |
user = hello ; User to run as | |
stdout_logfile = /webapps/hello_django/logs/gunicorn_supervisor.log ; Where to write log messages | |
redirect_stderr = true ; Save stderr in the same log | |
environment=LANG=en_US.UTF-8,LC_ALL=en_US.UTF-8 ; Set UTF-8 as default encoding |
Однако в этом случае у меня возникла ошибка: couldn’t exec gunicorn_start EACCES
ее решение в модификации команда запуска на следующею:
1 |
<span class="pln">command </span><span class="pun">=</span><span class="pln">sh </span><span class="pun">/</span><span class="pln">webapps</span><span class="pun">/</span><span class="pln">trueguild_django</span><span class="pun">/</span><span class="pln">bin</span><span class="pun">/</span><span class="pln">gunicorn_start</span> |
Добавил sh в начало команды.
Еще один вариант настройки:
https://proft.me/2011/08/16/nastrojka-gunicorn-i-uwsgi-sravnenie-proizvoditeln/