DJANGO установка на сервере

Первое что нужно это установить python и pip. 

Далее устанавливаем систему виртуального окружения: 

Создаем виртуальное окружение, где будет работать наше приложение (при этом у данного приложения будет собственная копия питона и всех необходимых ему библиотек).

Активация виртуального окружения, из которого потом и будут выполнятся все команды по запуску или установки библиотек используют команду:

Для выхода из виртуального окружения используют команду:

Если для приложения необходима БД, то создаем базу дынных и пользователя, которому предоставляем доступ:

Далее устанавливаем 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

Примечание: когда приложение прослушивает входящие соединения на 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.

и прописываем static_root

сохраняем и выходим

из папки проекта запускаем

в папке проекта появится папка с именем static

13) Настроим nginx

перейдем по следующему пути

открываем файлик default

Удаляем оттуда все и пишем

Сохраняем, выходим.

Supervisor.

Чтобы наше приложение стратовало после любого непредвиденного ребута или сбоя, нам нужно обзавестись supervisor-ом.

Установим supervisor

Создадим конфиг файл для gunicorn

Открываем на редактирование

Вносим

создадим конфиг файл для супервизора

Откроем

Внутрь внесем

Команды для supervisor

Добавление в системные службы:
wget supervisord.service -O /usr/lib/systemd/system/supervisord.service

  1. start service systemctl start supervisord
  2. view service status: systemctl status supervisord
  3. auto start service on system startup: systemctl enable supervisord

После старта проверяем свой сайт в браузере. Должен работать.

http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/

Однако в моем случае с такой настройкой supervisord возникла проблема приложение никак не хотело стартовать:

Создал скрипт:

Назовем его 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

ее решение в модификации команда запуска на следующею:

Добавил sh в начало команды.

Еще один вариант настройки:

https://proft.me/2011/08/16/nastrojka-gunicorn-i-uwsgi-sravnenie-proizvoditeln/

 

Обсуждение закрыто.