1. Установите необходимые пакеты, используя apt
2. Создайте каталоги для ваших статических и медиа файлов
Прежде всего, вы должны создать каталоги. Здесь я предполагаю, что вы в настоящее время используете пользователя Ubuntu с домашним каталогом по умолчанию /home/ubuntu:
Вторая команда сделает пользователя с именем www-data владельцем каталога /home/ubuntu/media. www-data будет пользователем, выполняющим ваш процесс Python в uWSGI, и этот пользователь должен иметь возможность писать в каталог мультимедиа, чтобы правильно сохранять загруженные пользователем файлы.
3. Настройте свой проект Django и установите требования
Этот шаг действительно зависит от вашего конкретного приложения Django, для целей данного руководства я буду предполагать, что ваш проект Django установлен в каталоге / home/ubuntu/django_project/ со следующей структурой:
Также я предполагаю, что вы установили все свои зависимости Python, например, используя apt или pip.
Я всегда следую рекомендациям при запуске нового проекта Django, разбивая монолитный файл settings.py на разные файлы, по одному для каждой среды развертывания (local, test, production и т.д.).
В нашем случае Django будет использовать модуль project/settings/production.py для своих настроек. Здесь мы устанавливаем переменные STATIC_ROOT и MEDIA_ROOT для каталогов, которые мы создали на шаге 2:
4. Соберите статические файлы
Запустите следующую команду, чтобы собрать все статические файлы для вашего проекта Django:
5. Настройте uWSGI для размещения вашего проекта Django.
Создайте файл с именем django.ini в каталоге /etc/uwsgi/apps-enabled/. Содержимое файла должно быть примерно таким:
Перезапустите uWSGI с помощью:
Вы должны найти логи uWSGI в /var/log/uwsgi/apps/django.log. Поэтому вы можете проверить их, чтобы увидеть, правильно ли запущен процесс Python или есть проблемы.
6. Настройте NGINX для обслуживания вашего приложения
Создайте файл с именем django в каталоге /etc/nginx/sites-enabled/. Содержимое файла должно быть примерно таким:
Перезапустите NGINX с помощью:
7. Наслаждайтесь своим приложением Django
Направьте браузер на свой домен, и вы увидите приложение Django во всей его красе!
Развертывание Django-проекта под nginx
Преамбула
Из нескольких способов развертывания Django я сразу отмёл mod_python, потому что мне не хотелось поднимать тяжеловесный Apache. Решил развернуть на легком веб-сервере. На данный момент основных легковесных альтернатив Апачу две — lighttpd и nginx. Первоначально я выбрал первый, но столкнулся с проблемами, связанными с URL. Я подумал, что, может, nginx будет работать получше, и развернул приложение на нём. В этом деле мне очень сильно помог один скринкаст, уже не помню точно чьего авторства.
Всё было отлично, но когда я захотел использовать админку Django(удобная вещь, кстати), меня постигло разочарование — форма логина показывалась, но при попытке войти меня выбрасывало на admin. После получаса гугления, я нашёл топик на небезызвестном форуме Ивана Салагаева, в котором описывалось решение проблемы. После того, как я последовал описанным советам, все заработало на-ура. Представляю вашему вниманию необходимую конфигурацию сервера и Django.
Конфигурация nginx
Все пути указаны для моего дистрибутива(ArchLinux), у вас они могут отличаться:
fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx;
Насчёт последнего параметра в этом файле: необходим он или нет для Django, я не знаю, но исследований не проводил, работает и так.
user http;
worker_processes 1;
#error_log logs/error.log;
#error_log logs/error.log notice;
#error_log logs/error.log info;
events <
worker_connections 1024;
>
http <
include mime.types;
default_type application/octet-stream;
access_log logs/access.log main;
sendfile on;
#tcp_nopush on;
#keepalive_timeout 0;
keepalive_timeout 65;
server <
listen 80;
server_name some.cool.server;
location / <
fastcgi_pass 127.0.0.1:8881; # эти параметры мы укажем потом и при запуске Django-fastcgi
include fastcgi_params;
>
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html <
root html;
>
>
>
Всё, настройка nginx закончена.
Настройка django
Команда нужная для запуска сервера обычно выглядит примерно так:
./manage.py runfcgi method=prefork host=127.0.0.1 port=8881 pidfile=/tmp/server.pid
Примечание: если у вас manage.py не сделан исполняемым, как у меня, вместо «./manage.py» надо использовать «python manage.py»
method — prefork или threaded, рекомендуется prefork ввиду GIL, а также того, что в UNIX и POSIX-совместимых ОС создание процесса дешевле создания потока.
host, port — хост и порт, на которых будет висеть FastCGI-сервер, параметры должны совпадать с теми, что были прописаны в конфиге nginx. Как по мне, использовать связь через порт лучше, чем через сокет, но это уже на ваше усмотрение
pidfile — имя файла, куда будет записан PID сервера, для того, чтобы имели возможность потом его убить
Настройка Django с Postgres, Nginx и Gunicorn в Ubuntu 18.04
Published on January 7, 2020
Введение
Django — это мощная веб-система, помогающая создать приложение или сайт Python с нуля. Django включает упрощенный сервер разработки для локального тестирования кода, однако для серьезных производственных задач требуется более защищенный и мощный веб-сервер.
В этом руководстве мы покажем, как установить и настроить определенные компоненты Ubuntu 18.04 для поддержки и обслуживания приложений Django. Вначале мы создадим базу данных PostgreSQL вместо того, чтобы использовать базу данных по умолчанию SQLite. Мы настроим сервер приложений Gunicorn для взаимодействия с нашими приложениями. Затем мы настроим Nginx для работы в качестве обратного прокси-сервера Gunicorn, что даст нам доступ к функциям безопасности и повышения производительности для обслуживания наших приложений.
Предварительные требования и цели
Для прохождения этого обучающего модуля вам потребуется новый экземпляр сервера Ubuntu 18.04 с базовым брандмауэром и пользователем с привилегиями sudo и без привилегий root. Чтобы узнать, как настроить такой сервер, воспользуйтесь нашим модулем Руководство по начальной настройке сервера.
Мы будем устанавливать Django в виртуальной среде. Установка Django в отдельную среду проекта позволит отдельно обрабатывать проекты и их требования.
Когда база данных будет работать, мы выполним установку и настройку сервера приложений Gunicorn. Он послужит интерфейсом нашего приложения и будет обеспечивать преобразование запросов клиентов по протоколу HTTP в вызовы Python, которые наше приложение сможет обрабатывать. Затем мы настроим Nginx в качестве обратного прокси-сервера для Gunicorn, чтобы воспользоваться высокоэффективными механизмами обработки соединений и удобными функциями безопасности.
Установка пакетов из хранилищ Ubuntu
Если вы используете Django с Python 3, введите:
Версия Django 1.11 — последняя версия Django с поддержкой Python 2. Если вы создаете новый проект, мы настоятельно рекомендуем использовать Python 3. Если вам необходимо использовать Python 2, введите:
Создание базы данных и пользователя PostgreSQL
Вначале мы создадим базу данных и пользователя базы данных для нашего приложения Django.
По умолчанию Postgres использует для локальных соединений схему аутентификации «peer authentication». Это означает, что если имя пользователя операционной системы совпадает с действительным именем пользователя Postgres, этот пользователь может войти без дополнительной аутентификации.
Выполните вход в интерактивный сеанс Postgres, введя следующую команду:
Вы увидите диалог PostgreSQL, где можно будет задать наши требования.
Вначале создайте базу данных для своего проекта:
Примечание. Каждое выражение Postgres должно заканчиваться точкой с запятой. Если с вашей командой возникнут проблемы, проверьте это.
Затем создайте пользователя базы данных для нашего проекта. Обязательно выберите безопасный пароль:
Затем мы изменим несколько параметров подключения для только что созданного нами пользователя. Это ускорит работу базы данных, поскольку теперь при каждом подключении не нужно будет запрашивать и устанавливать корректные значения.
Теперь мы предоставим созданному пользователю доступ для администрирования новой базы данных:
Завершив настройку, закройте диалог PostgreSQL с помощью следующей команды:
Теперь настройка Postgres завершена, и Django может подключаться к базе данных и управлять своей информацией в базе данных.
Создание виртуальной среды Python для вашего проекта
Мы создали базу данных, и теперь можем перейти к остальным требованиям нашего проекта. Для удобства управления мы установим наши требования Python в виртуальной среде.
Если вы используете Python 3, обновите pip и установите пакет с помощью следующей команды:
Если вы используете Python 2, обновите pip и установите пакет с помощью следующей команды:
После установки virtualenv мы можем начать формирование нашего проекта. Создайте каталог для файлов нашего проекта и перейдите в этот каталог:
Создайте в каталоге проекта виртуальную среду Python с помощью следующей команды:
Прежде чем установить требования Python для нашего проекта, необходимо активировать виртуальную среду. Для этого можно использовать следующую команду:
Командная строка изменится, показывая, что теперь вы работаете в виртуальной среде Python. Она будет выглядеть примерно следующим образом: ( myprojectenv ) user @ host :
После запуска виртуальной среды установите Django, Gunicorn и адаптер psycopg2 PostgreSQL с помощью локального экземпляра pip :
Теперь у вас должно быть установлено все программное обеспечение, необходимое для запуска проекта Django.
Создание и настройка нового проекта Django
Установив компоненты Python, мы можем создать реальные файлы проекта Django.
Создание проекта Django
Поскольку у нас уже есть каталог проекта, мы укажем Django установить файлы в него. В этом каталоге будет создан каталог второго уровня с фактическим кодом (это нормально) и размещен скрипт управления. Здесь мы явно определяем каталог, а не даем Django принимать решения относительно текущего каталога:
Сейчас каталог вашего проекта (в нашем случае
/ myprojectdir ) должен содержать следующее:
/myprojectdir/manage.py : скрипт управления проектами Django.
/myprojectdir/myprojectenv/ : виртуальный каталог, которы мы создали до этого.
Изменение настроек проекта
Прежде всего, необходимо изменить настройки созданных файлов проекта. Откройте файл настроек в текстовом редакторе:
В квадратных скобках перечислите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в кавычках, отдельные записи должны быть разделены запятой. Если вы хотите включить в запрос весь домен и любые субдомены, добавьте точку перед началом записи. В следующем фрагменте кода для демонстрации в строках комментариев приведено несколько примеров:
Примечание. Обязательно используйте localhost как одну из опций, поскольку мы будем использовать локальный экземпляр Nginx как прокси-сервер.
Затем перейдите в конец файла и добавьте параметр, указывающий, где следует разместить статичные файлы. Это необходимо, чтобы Nginx мог обрабатывать запросы для этих элементов. Следующая строка указывает Django, что они помещаются в каталог static в базовом каталоге проекта:
Сохраните файл и закройте его после завершения.
Завершение начальной настройки проекта
Теперь мы можем перенести начальную схему базы данных для нашей базы данных PostgreSQL, используя скрипт управления:
Создайте административного пользователя проекта с помощью следующей команды:
Вам нужно будет выбрать имя пользователя, указать адрес электронной почты, а затем задать и подтвердить пароль.
Мы можем собрать весь статичный контент в заданном каталоге с помощью следующей команды:
Данную операцию нужно будет подтвердить. Статичные файлы будут помещены в каталог static в каталоге вашего проекта.
Если вы следовали указаниям модуля по начальной настройке сервера, ваш сервер должен защищать брандмауэр UFW. Чтобы протестировать сервер разработки, необходимо разрешить доступ к порту, который мы будем использовать.
Создайте исключение для порта 8000 с помощью следующей команды:
Теперь вы можете протестировать ваш проект, запустив сервер разработки Django с помощью следующей команды:
Откройте в браузере доменное имя или IP-адрес вашего сервера с суффиксом :8000 :
Вы увидите страницу индекса Django по умолчанию:
Если вы добавите /admin в конце URL в панели адреса, вам будет предложено ввести имя пользователя и пароль администратора, созданные с помощью команды createsuperuser :
После аутентификации вы получите доступ к интерфейсу администрирования Django по умолчанию:
Завершив изучение, нажмите CTRL+C в окне терминала, чтобы завершить работу сервера разработки.
Тестирование способности Gunicorn обслуживать проект
Перед выходом из виртуальной среды нужно протестировать способность Gunicorn обслуживать приложение. Для этого нам нужно войти в каталог нашего проекта и использовать gunicorn для загрузки модуля WSGI проекта:
Gunicorn будет запущен на том же интерфейсе, на котором работал сервер разработки Django. Теперь вы можете вернуться и снова протестировать приложение.
Примечание. В интерфейсе администратора не будут применяться в стили, поскольку Gunicorn неизвестно, как находить требуемый статичный контент CSS.
После завершения тестирования нажмите CTRL+C в окне терминала, чтобы остановить работу Gunicorn.
Мы завершили настройку нашего приложения Django. Теперь мы можем выйти из виртуальной среды с помощью следующей команды:
Индикатор виртуальной среды будет убран из командной строки.
Создание файлов сокета и служебных файлов systemd для Gunicorn
Мы убедились, что Gunicorn может взаимодействовать с нашим приложением Django, но теперь нам нужно реализовать более надежный способ запуска и остановки сервера приложений. Для этого мы создадим служебные файлы и файлы сокета systemd.
Сокет Gunicorn создается при загрузке и прослушивает подключения. При подключении systemd автоматически запускает процесс Gunicorn для обработки подключения.
Создайте и откройте файл сокета systemd для Gunicorn с привилегиями sudo :
Сохраните файл и закройте его после завершения.
Теперь служебный файл systemd готов. Сохраните и закройте его.
Теперь мы можем запустить и активировать сокет Gunicorn. Файл сокета /run/gunicorn.sock будет создан сейчас и будет создаваться при загрузке. При подключении к этому сокету systemd автоматически запустит gunicorn.service для его обработки:
Успешность операции можно подтвердить, проверив файл сокета.
Проверка файла сокета Gunicorn
Проверьте состояние процесса, чтобы узнать, удалось ли его запустить:
Затем проверьте наличие файла gunicorn.sock в каталоге /run :
Еще раз проверьте файл /etc/systemd/system/gunicorn.socket и устраните любые обнаруженные проблемы, прежде чем продолжить.
Тестирование активации сокета
Чтобы протестировать механизм активации сокета, установим соединение с сокетом через curl с помощью следующей команды:
Выводимые данные приложения должны отобразиться в терминале в формате HTML. Это показывает, что Gunicorn запущен и может обслуживать ваше приложение Django. Вы можете убедиться, что служба Gunicorn работает, с помощью следующей команды:
Если результат вывода curl или systemctl status указывают на наличие проблемы, поищите в журналах более подробные данные:
Обязательно устраните вышеперечисленные проблемы, прежде чем продолжить.
Настройка Nginx как прокси для Gunicorn
Мы настроили Gunicorn, и теперь нам нужно настроить Nginx для передачи трафика в процесс.
Для начала нужно создать и открыть новый серверный блок в каталоге Nginx sites-available :
Откройте внутри него новый серверный блок. Вначале мы укажем, что этот блок должен прослушивать обычный порт 80, и что он должен отвечать на доменное имя или IP-адрес нашего сервера:
Затем мы укажем Nginx игнорировать любые проблемы при поиске favicon. Также мы укажем, где можно найти статичные ресурсы, собранные нами в каталоге
Сохраните файл и закройте его после завершения. Теперь мы можем активировать файл, привязав его к каталогу sites-enabled :
Протестируйте конфигурацию Nginx на ошибки синтаксиса:
Если ошибок не будет найдено, перезапустите Nginx с помощью следующей команды:
Нам нужна возможность открыть брандмауэр для обычного трафика через порт 80. Поскольку нам больше не потребуется доступ к серверу разработки, мы можем удалить правило и открыть порт 8000:
Теперь у вас должна быть возможность перейти к домену или IP-адресу вашего сервера для просмотра вашего приложения.
Примечание. После настройки Nginx необходимо защитить трафик на сервер с помощью SSL/TLS. Это важно, поскольку в противном случае вся информация, включая пароли, будет отправляться через сеть в простом текстовом формате.
Если у вас имеется доменное имя, проще всего будет использовать Let’s Encrypt для получения сертификата SSL для защиты вашего трафика. Следуйте указаниям этого руководства, чтобы настроить Let’s Encrypt с Nginx в Ubuntu 18.04. Следуйте процедуре, используя серверный блок Nginx, созданный нами в этом обучающем модуле.
Если у вас нет доменного имени, вы можете защитить свой сайт для тестирования и обучения с помощью сертификата SSL с собственной подписью. Следуйте процедуре, используя серверный блок Nginx, созданный нами в этом обучающем модуле.
Диагностика и устранение неисправностей Nginx и Gunicorn
Если на последнем шаге не будет показано ваше приложение, вам нужно будет провести диагностику и устранение неисправностей установки.
Nginx показывает страницу по умолчанию, а не приложение Django
Параметр server_name в серверном блоке вашего проекта должен быть более конкретным, чем содержащийся в серверном блоке, выбираемом по умолчанию.
Nginx выводит ошибку 502 Bad Gateway вместо приложения Django
Ошибка 502 означает, что Nginx не может выступать в качестве прокси для запроса. Ошибка 502 может сигнализировать о разнообразных проблемах конфигурации, поэтому для диагностики и устранения неисправности потребуется больше информации.
В первую очередь эту информацию следует искать в журналах ошибок Nginx. Обычно это указывает, какие условия вызвали проблемы во время прокси-обработки. Изучите журналы ошибок Nginx с помощью следующей команды:
Теперь выполните в браузере еще один запрос, чтобы получить свежее сообщение об ошибке (попробуйте обновить страницу). В журнал будет записано свежее сообщение об ошибке. Если вы изучите его, это поможет идентифицировать проблему.
Возможно вы увидите сообщение следующего вида:
connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)
connect() to unix:/run/gunicorn.sock failed (13: Permission denied)
Команда выведет права доступа всех компонентов каталога. Изучив права доступа (первый столбец), владельца (второй столбец) и группового владельца (третий столбец), мы можем определить, какой тип доступа разрешен для файла сокета.
Если для любого из каталогов, ведущих к сокету, отсутствуют глобальные разрешения на чтение и исполнение, Nginx не сможет получить доступ к сокету без включения таких разрешений или без передачи группового владения группе, в которую входит Nginx.
Django выводит ошибку: «could not connect to server: Connection refused»
При попытке доступа к частям приложения через браузер Django может вывести сообщение следующего вида:
Это означает, что Django не может подключиться к базе данных Postgres. Убедиться в нормальной работе экземпляра Postgres с помощью следующей команды:
Если он работает некорректно, вы можете запустить его и включить автоматический запуск при загрузке (если эта настройка еще не задана) с помощью следующей команды:
Если проблемы не исчезнут, проверьте правильность настроек базы данных, заданных в файле
Дополнительная диагностика и устранение неисправностей
В случае обнаружения дополнительных проблем журналы могут помочь в поиске первопричин. Проверяйте их по очереди и ищите сообщения, указывающие на проблемные места.
Следующие журналы могут быть полезными:
При обновлении конфигурации или приложения вам может понадобиться перезапустить процессы для адаптации к изменениям.
Если вы обновите свое приложение Django, вы можете перезапустить процесс Gunicorn для адаптации к изменениям с помощью следующей команды:
Если вы измените файл сокета или служебные файлы Gunicorn, перезагрузите демона и перезапустите процесс с помощью следующей команды:
Если вы измените конфигурацию серверного блока Nginx, протестируйте конфигурацию и Nginx с помощью следующей команды:
Эти команды помогают адаптироваться к изменениям в случае изменения конфигурации.
Заключение
В этом руководстве мы создали и настроили проект Django в его собственной виртуальной среде. Мы настроили Gunicorn для трансляции запросов клиентов, чтобы Django мог их обрабатывать. Затем мы настроили Nginx в качестве обратного прокси-сервера для обработки клиентских соединений и вывода проектов, соответствующих запросам клиентов.
Django упрощает создание проектов и приложений, предоставляя множество стандартных элементов и позволяя сосредоточиться на уникальных. Используя описанную в этой статье процедуру, вы сможете легко обслуживать создаваемые приложения на одном сервере.
Django на production. uWSGI + nginx. Подробное руководство
Перед вами руководство по настройке production окружения для Django. Здесь будут описаны необходимые шаги по настройке Django, uWSGI и nginx. Руководство охватывает все три компонента — полный стек серверного ПО для веб-приложений.
Подразумевается, что вы используете Unix-подобную операционную систему и менеджер пакетов, эквивалентный aptitude. Найти эквивалент aptitude почти для любой операционной системы, в том числе и для Mac OS X, для вас не составит никакого труда.
Руководство написно для версий Django 1.4 или выше. Если вы используете более раннюю версию, то вам придется самостоятельно найти wsgi модуль для нее. Также вы заметите, что файловая структура проекта будет немного отличаться от представленной здесь.
Общая идея
Веб-сервер может по запросу отдавать пользователям файлы из своей файловой системы, однако он не может напрямую работать с Djangо приложениями. Веб-серверу нужен интерфейс, который будет запускать Django приложение, передавать ему запрос от пользователя и возвращать ответ.
Для выполнения этих задач был разработан Web Server Gateway Interface — WSGI — стандарт взаимодействия Python программ и веб-сервра.
uWSGI — одна из реализаций WSGI. В этом руководстве мы установим и настроим uWSGI для создания Unix сокета и взаимодействия с веб-сервером по протоколу WSGI.
Полный стек компонентов будет выглядеть следующим образом:
Перед установкой uWSGI
virtualenv
Создадаем и активируем виртуальное окружение для софта, который нам будет необходим (ниже я расскажу, как установить uwsgi глобально):
Django
Устонавливаем Django в наше виртуальное окружение:
Создаем новый проект и переходим в его корневую папку:
Домен и порт
В этом руководстве мы будем использовать для нашего учебного проекта домен yourserver.com. Вам нужно будет заменить его на собственное доменное имя или IP адрес вашего сервера.
Для получения запросов от пользователей мы будем использовать порт 8000. Вы можете использовать любой другой порт. Я выбрал именно 8000, потому что его использование не приведет к конфликтам с другими задачами, выполняемыми сервером.
Установка и базовая настройка uWSGI
Установка uWSGI в виртуальное окружение
Один из хороших способов установить uWSGI:
Нам понадобятся Python development пакеты. Если вы используете Debian или основнную на Debian операционную систему (например, Ubuntu или Mint), вам нужно установить пакет pythonX.Y-dev, где X.Y — нужная вам версия Python.
Проверка
Создаем файл test.py:
Проверка работы Django приложения
Теперь сделаем так, чтобы uWSGI работал с Django приложением, а не с файлом test.py.
Проверим, что только что созданный проект mysite запускается на сервере для разработки:
Если проект запустился, останавливаем сервер для разработки и запускаем uWSGI следующим образом:
Это нехорошо, что комьютер пользователя на прямую обращается к uWSGI. Между пользователем и uWSGI должен находиться веб-сервер.
Устновка и базовая настройка nginx
Установка и запуск nginx
Если у вас занят восьмидесятый порт, измените конфигурацию nginx так, чтобы он использовал какой-нибудь другой (в этом руководстве nginx будет использовать порт 8000).
Конфигурация nginx для работы с Django
Нам понадобится файл uwsgi_params, который можно взять здесь: github.com/nginx/nginx/blob/master/conf/uwsgi_params.
Скачиваем его в корневую папку нашего проекта.
Создаем файл mysite_nginx.conf:
Этот конфигурационный файл указывает nginx, что он должен отдавать пользователям медиа и статик файлы из файловой системы, а все остальные запросы перенаправлять в Django приложение. В больших проектах лучше использовать два сервера: один для обслуживания статик и медиа файлов, а другой для Django приложения. С небольшими, и тем более с учебными проектами, справится и один сервер.
Статика в одном месте
Перед запуском nginx поместим всю статику в папку static. Для этого добавляем в файл mysite/settings.py следующую строку:
И выполняем команду:
Проверка осблуживания статики и медиа
В браузере переходим по адресу yourserver.com:8000/media/media.png и, если видим наш файл, значит мы все сделали правильно.
nginx + uWSGI + test.py
Настраиваем взаимодействие nginx и test.py через uSWGI.
Unix сокеты вместо веб-портов
До этого мометна мы использовали сокет, привязанный к TCP порту (я называл его веб-порт), потому что так было проще, но на деле рекомендуется использовать Unix-сокет из-за преимущества в производительности.
Редактируем mysite_nginx.conf следующим образом:
И перезапускаем nginx:
На этот раз опция socket указывает на файл.
Открываем в браузере yourserver.com:8000/
Если не заработало
Проверьте лог ошибок nginx, скорее всего он находится в файле var/log/nginx/error.log
Если найдете там что-то похожее на
значит есть проблема с правами доступа к файлу mysite.sock. Необходимо сделать так, чтобы nginx имел разрешение на использование этого файла.
Попробуйте запустить uWSGI так:
Чтобы проблем с доступом в будущем не было, добавьте вашего пользователя в группу www-data.
Информация, которую uWSGI выводит в терминал, полезна при поиске и исправлении возможных ошибок или неисправностей.
nginx + uWSGI + Django
В браузере переходим на yourserver.com:8000/ и видим стартовую страницу Django.
Мы собрали всю цепочку, но настройка еще не закончена, идем дальше.
Конфигурация uWSGI через ini файл
Очень удобно все опции, с которыми мы запускаем uWSGI, указать в ini файле, а при запуске передавать только путь к этому файлу.
Создаем файл mysite_uwsgi.ini :
Проверяем. Все работает? Дальше.
Устанавливаем uWSGI глобально
До сих пор uWSGI был установлен в виртуальном окружении. Чтобы была возможность автоматически запускать uWSGI при старте операционной системы, мы установим его глобально.
Деактивируем виртуальное окружение:
На вики странице uWSGI описано несколько вариантов установки. Перед тем, как установить uWSGI глобально, вам не помешает определиться с выбором версии и методом установки.
Запусить uWSGI можно той же командой, что и раньше:
Режим Emperor
Если сервер обслуживает несколько проектов, каждый из которых использует uWSGI, то нужно исползовать режим Emperor. В этом режиме uWSGI просматривает папку с конфигурационными файлами и для каждого файла запускает отдельный процесс (вассал).
Если один из конфигурационных файлов будет изменен, uWSGI перезапустит соответствующего вассала.