Как обслуживать приложения Django с помощью uWSGI и Nginx в Ubuntu 16.04

Вступление

Django - это мощный веб-фреймворк, который может помочь вам запустить приложение или веб-сайт на Python. Django включает в себя упрощенный сервер разработки для локального тестирования кода, но для всего, что связано с производством, требуется более безопасный и мощный веб-сервер.

В этом руководстве мы покажем, как установить и настроить некоторые компоненты в Ubuntu 16.04 для поддержки и обслуживания приложений Django. Мы настроим сервер-контейнер приложений uWSGI для взаимодействия с нашими приложениями. Затем мы настроим Nginx для обращения прокси к uWSGI, предоставляя нам доступ к его функциям безопасности и производительности для обслуживания наших приложений.

Предпосылки и цели

Чтобы выполнить это руководство, у вас должен быть новый экземпляр сервера Ubuntu 16.04 с пользователем без полномочий root с настроенными привилегиями + sudo +. Вы можете узнать, как настроить это, запустив наше https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04 руководство по настройке начального сервера].

Мы будем устанавливать Django в двух разных виртуальных средах. Это позволит обрабатывать ваши проекты и их требования отдельно. Мы будем создавать два примера проектов, чтобы можно было выполнить все этапы в многопроектной среде.

Как только у нас появятся наши приложения, мы установим и настроим сервер приложений uWSGI. Это будет служить интерфейсом для наших приложений, которые будут транслировать клиентские запросы, используя HTTP-запросы на Python, которые наше приложение может обрабатывать. Затем мы настроим Nginx перед uWSGI, чтобы воспользоваться его высокопроизводительными механизмами обработки соединений и простыми в реализации функциями безопасности.

Давайте начнем.

Установите и настройте VirtualEnv и VirtualEnvWrapper

Мы будем устанавливать наши проекты Django в их собственных виртуальных средах, чтобы изолировать требования для каждого из них. Для этого мы будем устанавливать + virtualenv +, который может создавать виртуальные среды Python, и + virtualenvwrapper +, который добавляет некоторые улучшения удобства использования в рабочий процесс + virtualenv +.

Мы будем устанавливать оба этих компонента, используя + pip +, менеджер пакетов Python. Мы можем установить эту утилиту из репозиториев Ubuntu.

Если вы создаете свои проекты Django с помощью * Python 2 *, введите:

sudo apt-get update
sudo apt-get install python-pip

Если вы используете * Python 3 *, введите:

sudo apt-get update
sudo apt-get install python3-pip

Теперь, когда у вас установлен + pip, мы можем установить` + virtualenv` и + virtualenvwrapper глобально. Мы также обновим + pip до последней версии, используя сам` + pip`.

Если вы используете * Python 2 *, введите:

sudo -H pip install --upgrade pip
sudo -H pip install virtualenv virtualenvwrapper

Если вы используете * Python 3 *, введите:

sudo -H pip3 install --upgrade pip
sudo -H pip3 install virtualenv virtualenvwrapper

Установив эти компоненты, мы теперь можем сконфигурировать нашу оболочку, используя информацию, необходимую для работы со скриптом + virtualenvwrapper +. Все наши виртуальные среды будут помещены в каталог в нашей домашней папке с именем + Env + для легкого доступа. Это настраивается с помощью переменной среды + WORKON_HOME +. Мы можем добавить это к нашему сценарию инициализации оболочки и можем создать сценарий оболочки виртуальной среды.

Если вы используете * Python 3 * и команду + pip3 +, вам также необходимо добавить дополнительную строку в ваш скрипт инициализации оболочки:

echo "export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3" >> ~/.bashrc

Независимо от того, какую версию Python вы используете, вам нужно выполнить следующие команды:

echo "export WORKON_HOME=~/Env" >> ~/.bashrc
echo "source /usr/local/bin/virtualenvwrapper.sh" >> ~/.bashrc

Теперь создайте сценарий инициализации оболочки, чтобы использовать эту функцию в текущем сеансе:

source ~/.bashrc

Теперь у вас должен быть каталог с именем + Env + в вашей домашней папке, в котором будет храниться информация о виртуальной среде.

Создание проектов Django

Теперь, когда у нас есть инструменты для виртуальной среды, мы создадим две виртуальные среды, установим Django в каждой и запустим два проекта.

Создать первый проект

Мы можем легко создать виртуальную среду, используя некоторые команды, которые нам предоставляет скрипт + virtualenvwrapper +.

Создайте свою первую виртуальную среду с именем вашего первого сайта или проекта, набрав:

mkvirtualenv

Это создаст виртуальную среду, установит Python и + pip + внутри нее, и активирует среду. Ваше приглашение изменится, чтобы указать, что вы сейчас работаете в новой виртуальной среде. Это будет выглядеть примерно так: + () @: ~ $ +. Значение в скобках - это имя вашей виртуальной среды. Любое программное обеспечение, установленное через + pip +, теперь будет установлено в виртуальной среде, а не в глобальной системе. Это позволяет нам изолировать наши пакеты для каждого проекта.

Нашим первым шагом будет установка самого Django. Мы можем использовать + pip для этого без` + sudo`, так как мы устанавливаем это локально в нашей виртуальной среде:

pip install django

С установленным Django мы можем создать наш первый пример проекта, набрав:

cd ~
django-admin.py startproject

Это создаст каталог с именем ++ в вашем домашнем каталоге. Внутри этого находится сценарий управления, используемый для обработки различных аспектов проекта, и другой каталог с тем же именем, используемый для размещения фактического кода проекта.

Перейдите в каталог первого уровня, чтобы мы могли начать устанавливать минимальные требования для нашего примера проекта.

cd ~/

Начните с миграции базы данных, чтобы инициализировать базу данных SQLite, которую будет использовать наш проект. Вы можете настроить альтернативную базу данных для своего приложения, если хотите, но это выходит за рамки данного руководства:

~//manage.py migrate

Теперь у вас должен быть файл базы данных с именем + db.sqlite3 + в каталоге вашего проекта. Теперь мы можем создать административного пользователя, набрав:

~//manage.py createsuperuser

На этом этапе каталог вашего проекта (в нашем случае + ~ / +) должен иметь следующее содержимое:

+ ~ / firstsite / manage.py +: скрипт управления проектом Django.
+ ~ / firstsite / firstsite / +: пакет проекта Django. Он должен содержать файлы + init . Py +, + settings.py +, + urls.py + и + wsgi.py +.
+ ~ / firstsite / db.sqlite3 +: файл базы данных SQLite, используемый для хранения информации о вашем сайте.

Затем откройте файл настроек проекта в текстовом редакторе:

nano ~///settings.py

Начните с поиска директивы + ALLOWED_HOSTS +. Это определяет список адресов сервера или доменных имен, которые могут использоваться для подключения к экземпляру Django. Любые входящие запросы с заголовком * Host *, которого нет в этом списке, вызовут исключение. Django требует, чтобы вы установили это, чтобы предотвратить определенный класс уязвимости безопасности.

В квадратных скобках укажите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в цитатах с записями, разделенными запятой. Если вы хотите запросить весь домен и любые дочерние домены, добавьте точку к началу записи. В приведенном ниже фрагменте есть несколько закомментированных примеров, используемых для демонстрации:

~ / Порто-Ново / Порто-Ново / settings.py

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['', '', ]

Поскольку мы будем настраивать Nginx для обслуживания нашего сайта, нам необходимо настроить каталог, в котором будут храниться статические ресурсы нашего сайта. Это позволит Nginx обслуживать их напрямую, что положительно скажется на производительности. Мы скажем Django поместить их в каталог с именем + static + в базовом каталоге нашего проекта. Добавьте эту строку в конец файла, чтобы настроить это поведение:

~ / Порто-Ново / Порто-Ново / settings.py

. . .
STATIC_URL = '/static/'

Сохраните и закройте файл, когда вы закончите. Теперь соберите статические элементы нашего сайта и поместите их в этот каталог, набрав:

~//manage.py collectstatic

Вас могут попросить ввести «да», чтобы подтвердить действие и собрать статический контент. В вашем проекте появится новый каталог с именем + static +.

Затем мы можем открыть порт, чтобы получить доступ к серверу разработки Django. Если вы следовали руководству по первоначальной настройке сервера, у вас должен быть включен брандмауэр UFW. Разрешите соединения с портом 8080, набрав:

sudo ufw allow 8080

Со всем этим мы можем протестировать наш проект, временно запустив сервер разработки. Тип:

~//manage.py runserver 0.0.0.0:8080

Это запустит сервер разработки на порт + 8080 +. Посетите доменное имя или IP-адрес вашего сервера, а затем в браузере + 8080 +:

http://:8080

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

изображение: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/sample_site.png [пример сайта Django]

Добавьте + / admin + в конец URL-адреса в адресной строке браузера, и вы попадете на страницу входа администратора:

изображение: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/admin_login.png [логин администратора Django]

Используя учетные данные администратора, которые вы выбрали с помощью команды + createuperuser +, войдите на сервер. После этого вы получите доступ к интерфейсу администрирования:

изображение: https: //assets.digitalocean.com/articles/django_uwsgi_nginx_1404/admin_interface.png [интерфейс администратора Django]

После тестирования этой функции остановите сервер разработки, набрав * CTRL-C * в своем терминале. Теперь мы можем перейти к нашему второму проекту.

Создать второй проект

Второй проект будет создан точно так же, как и первый. Мы сократим объяснение в этом разделе, увидев, как вы уже завершили это один раз.

Вернитесь в свой домашний каталог и создайте вторую виртуальную среду для вашего нового проекта. Установите Django внутри этой новой среды после ее активации:

cd ~
mkvirtualenv
pip install django

Новая среда будет создана и изменена на, оставив предыдущую виртуальную среду. Этот экземпляр Django полностью отделен от другого, который вы настроили. Это позволяет вам управлять ими независимо и настраивать по мере необходимости.

Создайте второй проект и перейдите в каталог проекта:

cd ~
django-admin.py startproject
cd ~/

Инициализируйте базу данных и создайте пользователя с правами администратора:

~//manage.py migrate
~//manage.py createsuperuser

Откройте файл настроек:

nano ~///settings.py

Установите + ALLOWED_HOSTS + для домена вашего второго проекта, IP-адреса сервера или обоих, как вы делали с первым проектом:

ALLOWED_HOSTS = ['', '', ]

Добавьте местоположение для статических файлов, как вы делали в предыдущем проекте:

~ / Secondsite / secondsite / settings.py

. . .
STATIC_URL = '/static/'

Сохраните и закройте файл. Теперь соберите статические элементы в этот каталог, набрав:

~//manage.py collectstatic

Наконец, запустите сервер разработки, чтобы протестировать сайт:

~//manage.py runserver 0.0.0.0:8080

Вы должны проверить обычный сайт по адресу:

http://:8080

Также войдите на сайт администратора:

http://:8080/admin

Когда вы подтвердите, что все работает должным образом, введите * CTRL-C * в своем терминале, чтобы остановить сервер разработки.

Отказ от виртуальной среды

Поскольку теперь мы закончили с частью руководства по Django, мы можем деактивировать нашу вторую виртуальную среду:

deactivate

Если вам снова понадобится работать на любом из ваших сайтов Django, вам следует активировать соответствующие среды. Вы можете сделать это используя команду + workon +:

workon

Or:

workon

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

deactivate

Теперь мы можем перейти к настройке сервера приложений.

Настройка сервера приложений uWSGI

Теперь, когда у нас есть два готовых к работе проекта Django, мы можем настроить uWSGI. uWSGI - это сервер приложений, который может взаимодействовать с приложениями через стандартный интерфейс WSGI. Чтобы узнать больше об этом, прочитайте https://www.digitalocean.com/community/tutorials/how-to-set-up-uwsgi-and-nginx-to-serve-python-apps-on-ubuntu-14-04 # определения и понятия [этот раздел] нашего руководства по настройке uWSGI и Nginx в Ubuntu 14.04.

Установка uWSGI

В отличие от руководства, указанного выше, в этом руководстве мы будем устанавливать uWSGI по всему миру. Это создаст меньше трения при работе с несколькими проектами Django. Прежде чем мы сможем установить uWSGI, нам нужны файлы разработки Python, на которые опирается программное обеспечение. Мы можем установить это прямо из репозиториев Ubuntu.

Если вы используете Django с * Python 2 *, введите:

sudo apt-get install python-dev

Если вы используете * Python 3 *, введите:

sudo apt-get install python3-dev

Теперь, когда файлы разработки доступны, мы можем установить uWSGI глобально через + pip +.

Если вы используете * Python 2 *, введите:

sudo -H pip install uwsgi

Если вы используете * Python 3 *, введите:

sudo -H pip3 install uwsgi

Мы можем быстро протестировать этот сервер приложений, передав ему информацию для одного из наших сайтов. Например, мы можем сказать ему, чтобы он обслуживал наш первый проект, набрав:

uwsgi --http :8080 --home /home//Env/ --chdir /home// -w .wsgi

Здесь мы сказали uWSGI использовать нашу виртуальную среду, расположенную в каталоге + ~ / Env +, перейти в каталог нашего проекта и использовать файл + wsgi.py +, хранящийся в нашем внутреннем каталоге ++ для обслуживания файла (используя синтаксис модуля Python + firstsite.wsgi +). Для демонстрации мы сказали, чтобы он служил HTTP на порту + 8080 +.

Если вы перейдете к доменному имени или IP-адресу сервера в своем браузере, а затем +: 8080 +, вы снова увидите свой сайт (статические элементы в интерфейсе + / admin +, такие как CSS, пока не будут работать ). Когда вы закончите тестирование этой функции, введите CTRL-C в терминале.

Создание файлов конфигурации

Запуск uWSGI из командной строки полезен для тестирования, но не особенно полезен для реального развертывания. Вместо этого мы будем запускать uWSGI в «режиме Emperor», который позволяет главному процессу автоматически управлять отдельными приложениями с помощью набора файлов конфигурации.

Создайте каталог, в котором будут храниться ваши файлы конфигурации. Поскольку это глобальный процесс, мы создадим каталог с именем + / etc / uwsgi / sites для хранения ваших файлов конфигурации:

sudo mkdir -p /etc/uwsgi/sites

В этом каталоге мы разместим наши файлы конфигурации. Нам нужен файл конфигурации для каждого из проектов, которые мы обслуживаем. Процесс uWSGI может принимать файлы конфигурации в различных форматах, но мы будем использовать файлы + .ini + из-за их простоты.

Создайте файл для вашего первого проекта и откройте его в текстовом редакторе:

sudo nano /etc/uwsgi/sites/.ini

Внутри мы должны начать с заголовка раздела + [uwsgi] +. Вся наша информация будет идти под этим заголовком. Мы также собираемся использовать переменные, чтобы сделать наш файл конфигурации более пригодным для повторного использования. После заголовка установите переменную с именем + project + с именем вашего первого проекта. Добавьте переменную с именем + uid +, которая содержит ваше имя пользователя + sudo +.

Мы также добавим переменную с именем + base + и путь к домашнему каталогу вашего пользователя. Это будет сделано из имени пользователя, которое мы установили, используя синтаксис +% (variable_name) +. Это будет заменено значением переменной при чтении конфигурации:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

Далее нам нужно настроить uWSGI, чтобы он правильно обрабатывал наш проект. Нам нужно перейти в корневую директорию проекта, установив опцию + chdir +. Мы можем объединить домашний каталог и имя проекта, используя один и тот же синтаксис переменной.

Аналогичным образом мы укажем виртуальную среду для нашего проекта. Установив модуль, мы можем точно указать, как взаимодействовать с нашим проектом (импортируя вызываемое «приложение» из файла + wsgi.py + в нашем внутреннем каталоге проекта). Конфигурация этих элементов будет выглядеть так:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

Мы хотим создать мастер-процесс с 5 работниками. Мы можем сделать это, добавив это:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

Далее нам нужно указать, как uWSGI должен прослушивать соединения. В нашем тесте uWSGI мы использовали HTTP и сетевой порт. Однако, поскольку мы собираемся использовать Nginx в качестве обратного прокси-сервера, у нас есть лучшие варианты.

Вместо использования сетевого порта, поскольку все компоненты работают на одном сервере, мы можем использовать сокет Unix. Это более безопасно и обеспечивает лучшую производительность. Этот сокет не будет использовать HTTP, но вместо этого будет реализован протокол uWSGI + uwsgi +, который является быстрым двоичным протоколом, предназначенным для связи с другими серверами. Nginx может прокси-сервер, используя протокол + uwsgi +, так что это наш лучший выбор.

Мы также изменим владельца и разрешения сокета, потому что мы будем предоставлять веб-серверу доступ для записи. Мы установим опцию + вакуум +, чтобы файл сокета автоматически очищался при остановке службы:

/etc/uwsgi/sites/firstsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

На этом настройка нашего первого проекта uWSGI завершена. Сохраните и закройте файл.

Преимущество настройки файла с использованием переменных состоит в том, что он делает его невероятно простым для повторного использования. Скопируйте файл конфигурации вашего первого проекта, чтобы использовать его в качестве основы для вашего второго файла конфигурации:

sudo cp /etc/uwsgi/sites/.ini /etc/uwsgi/sites/.ini

Откройте второй файл конфигурации в текстовом редакторе:

sudo nano /etc/uwsgi/sites/.ini

Нам нужно всего лишь изменить одно значение в этом файле, чтобы оно работало для нашего второго проекта. Измените переменную + project + именем, которое вы использовали для второго проекта:

/etc/uwsgi/sites/secondsite.ini

[uwsgi]
project =
uid =
base = /home/%(uid)

chdir = %(base)/%(project)
home = %(base)/Env/%(project)
module = %(project).wsgi:application

master = true
processes = 5

socket = /run/uwsgi/%(project).sock
chown-socket = %(uid):www-data
chmod-socket = 660
vacuum = true

Сохраните и закройте файл, когда вы закончите. Ваш второй проект должен быть готов к работе сейчас.

Создать системный файл модуля для uWSGI

Теперь у нас есть файлы конфигурации, которые нам нужны для обслуживания наших проектов Django, но мы до сих пор не автоматизировали процесс. Далее мы создадим системный файл systemd для управления процессом uWSGI emperor и автоматически запустим uWSGI при загрузке.

Мы создадим файл модуля в каталоге + / etc / systemd / system, где хранятся созданные пользователем файлы модуля. Мы назовем наш файл + uwsgi.service +:

sudo nano /etc/systemd/system/uwsgi.service

Начните с раздела + [Unit] +, который используется для указания метаданных и информации об упорядочении. Мы просто разместим описание нашего сервиса здесь:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

Далее мы откроем раздел + [Service] +. Мы будем использовать директиву + ExecStartPre +, чтобы настроить части, которые нам нужны для запуска нашего сервера. Это гарантирует, что каталог + / run / uwsgi + создан и что наш обычный пользователь владеет им с группой + www-data + в качестве владельца группы. Оба + mkdir + с флагом + -p + и команда + chown + успешно возвращаются, даже если их операция не нужна. Это то, что мы хотим.

Для фактической команды запуска, указанной директивой + ExecStart +, мы укажем на исполняемый файл + uwsgi +. Мы скажем ему, чтобы он работал в «режиме Emperor», позволяя ему управлять несколькими приложениями, используя файлы, которые он находит в + / etc / uwsgi / sites +. Мы также добавим кусочки, необходимые для правильного управления процессом systemd. Они взяты из документации uWSGI here.

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

Теперь все, что нам нужно сделать, это добавить раздел + [Install] +. Это позволяет нам указать, когда служба должна запускаться автоматически. Мы свяжем наш сервис с состоянием многопользовательской системы. Всякий раз, когда система настроена для нескольких пользователей (нормальное рабочее состояние), наша служба будет активирована:

/etc/systemd/system/uwsgi.service

[Unit]
Description=uWSGI Emperor service

[Service]
ExecStartPre=/bin/bash -c 'mkdir -p /run/uwsgi; chown :www-data /run/uwsgi'
ExecStart=/usr/local/bin/uwsgi --emperor /etc/uwsgi/sites
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target

Когда вы закончите, сохраните и закройте файл.

На этом этапе мы не сможем успешно запустить службу, поскольку она зависит от доступности пользователя + www-data +. Нам нужно будет подождать, чтобы запустить сервис uWSGI, пока не будет установлен Nginx.

Установите и настройте Nginx в качестве обратного прокси

Теперь, когда uWSGI настроен и готов к работе, мы можем установить и настроить Nginx в качестве нашего обратного прокси-сервера. Это можно скачать из стандартных репозиториев Ubuntu:

sudo apt-get install nginx

После установки Nginx мы можем создать файл конфигурации блока сервера для каждого из наших проектов. Начните с первого проекта, создав файл конфигурации блока сервера:

sudo nano /etc/nginx/sites-available/

Внутри мы можем запустить наш блок сервера, указав номер порта и имя домена, где должен быть доступен наш первый проект. Блок + server_name + must соответствует одному из доменных имен сервера или его IP-адресу, иначе можно использовать страницу по умолчанию Nginx. Мы предполагаем, что у вас есть доменное имя для каждого:

/ И т.д. / Nginx / сайты-доступные / Порто-Ново

server {
   listen 80;
   server_name .com www..com;
}

Далее, мы можем сказать Nginx, чтобы он не беспокоился, если он не сможет найти значок. Мы также укажем на местоположение нашего каталога статических файлов, где мы собрали статические элементы нашего сайта:

/ И т.д. / Nginx / сайты-доступные / Порто-Ново

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }
}

Затем мы можем создать универсальный блок местоположения, который будет передавать все дополнительные запросы прямо в наше приложение. Мы включим параметры + uwsgi +, найденные в + / etc / nginx / uwsgi_params +, и передадим трафик в сокет, настроенный сервером uWSGI:

/ И т.д. / Nginx / сайты-доступные / Порто-Ново

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

На этом наш первый серверный блок завершен.

Мы будем использовать это в качестве основы для файла конфигурации Nginx нашего второго проекта. Скопируйте это сейчас:

sudo cp /etc/nginx/sites-available/ /etc/nginx/sites-available/

Откройте новый файл в вашем текстовом редакторе:

sudo nano /etc/nginx/sites-available/

Здесь вам придется изменить любую ссылку на ` со ссылкой на `. Вам также нужно изменить + server_name +, чтобы ваш второй проект отвечал на другое доменное имя или изменил порт, если у вас нет более одного доменного имени или IP-адреса. Когда вы закончите, это будет выглядеть примерно так:

/ И т.д. / Nginx / сайты-доступные / secondsite

server {
   listen 80;
   server_name .com www..com;

   location = /favicon.ico { access_log off; log_not_found off; }
   location /static/ {
       root /home//;
   }

   location / {
       include         uwsgi_params;
       uwsgi_pass      unix:/run/uwsgi/.sock;
   }
}

Сохраните и закройте файл, когда вы закончите.

Затем свяжите оба ваших новых файла конфигурации с каталогом + sites-enabled + в Nginx, чтобы включить их:

sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled
sudo ln -s /etc/nginx/sites-available/ /etc/nginx/sites-enabled

Проверьте синтаксис конфигурации, набрав:

sudo nginx -t

Если синтаксические ошибки не обнаружены, вы можете перезапустить службу Nginx для загрузки новой конфигурации:

sudo systemctl restart nginx

Если вы помните, мы никогда не запускали сервер uWSGI. Сделайте это сейчас, набрав:

sudo systemctl start uwsgi

Давайте удалим правило UFW для порта + 8080 + и вместо этого разрешим доступ к нашему серверу Nginx:

sudo ufw delete allow 8080
sudo ufw allow 'Nginx Full'

Теперь вы сможете получить доступ к своим двум проектам, перейдя по соответствующим доменным именам. И публичные, и административные интерфейсы должны работать как положено.

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

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

Устранение неполадок в Nginx и uWSGI

Если вы не можете получить доступ к своему приложению, вам необходимо устранить неполадки при установке.

Nginx показывает страницу по умолчанию вместо приложения Django

Если Nginx отображает страницу по умолчанию вместо прокси для вашего приложения, это обычно означает, что вам нужно настроить + server_name + в файле + / etc / nginx / sites-available / + так, чтобы он указывал на IP-адрес вашего сервера или доменное имя.

Nginx использует + server_name +, чтобы определить, какой блок сервера использовать для ответа на запросы. Если вы видите страницу Nginx по умолчанию, это признак того, что Nginx не смог явно сопоставить запрос с блоком сервера, поэтому он возвращается к блоку по умолчанию, определенному в `+ / etc / nginx / sites-available / по умолчанию + `.

+ Имя_сервера + в блоке сервера вашего проекта должно быть более конкретным, чем значение в блоке сервера по умолчанию для выбора.

Nginx отображает ошибку 502 Bad Gateway вместо приложения Django

Ошибка 502 указывает, что Nginx не может успешно прокси-запрос. Широкий спектр проблем конфигурации выражается в ошибке 502, поэтому для правильного устранения неполадок требуется больше информации.

Основное место для поиска дополнительной информации - в журналах ошибок Nginx. Как правило, это скажет вам, какие условия вызвали проблемы во время события прокси. Следуйте журналам ошибок Nginx, набрав:

sudo tail -F /var/log/nginx/error.log

Теперь сделайте еще один запрос в вашем браузере, чтобы сгенерировать новую ошибку (попробуйте обновить страницу). Вы должны увидеть новое сообщение об ошибке, записанное в журнал. Если вы посмотрите на сообщение, оно должно помочь вам сузить проблему.

Вы можете увидеть некоторые из следующих сообщений:

connect () для unix: /run/uwsgi/firstsite.sock не удалось (2: нет такого файла или каталога) *

Это указывает на то, что Nginx не смог найти файл сокета в указанном месте. Вы должны сравнить расположение + uwsgi_pass +, определенное в файлах + firstsite + и + secondsite + в файле + / etc / nginx / sites-available +, с фактическим местоположением + firstsite.sock + и + Секунды файла секунд.sock + `в каталоге + / run / uwsgi + `.

Проверьте наличие файлов сокетов в каталоге + / run / uwsgi +, введя:

sudo ls /run/uwsgi

Если в + / run / uwsgi + нет файлов сокетов, это обычно означает, что процесс + uwsgi + не смог его создать. Проверьте состояние процесса + uwsgi +, чтобы узнать, удалось ли запустить его:

sudo systemctl status uwsgi

Если команда + systemctl status + указала, что произошла ошибка, или если вы не нашли файлы сокетов в каталоге, это означает, что uWSGI не удалось запустить правильно. Проверьте журналы процесса uWSGI, набрав:

sudo journalctl -u uwsgi

Посмотрите на сообщения в журналах, чтобы узнать, где uWSGI столкнулся с проблемами. Есть много причин, по которым вы можете столкнуться с проблемами, но часто, если uWSGI не удалось создать файл сокета, это происходит по одной из следующих причин:

Файлы проекта принадлежат пользователю + root + вместо пользователя + sudo +
Строка + ExecStartPre + в файле + / etc / systemd / system / uwsgi.service + не содержит правильной команды для создания каталога и назначения владельца.
Путь + uwsgi_pass + в файлах конфигурации сайта в каталоге + / etc / nginx / sites-available + не предназначен для правильного расположения сокета
Конфигурация uWSGI, определенная в файлах + .ini + в каталоге + / etc / uwsgi / sites +, неверна. Проверьте следующие пункты:
Директива + chdir + после интерполяции указывает на главный каталог проекта.
Директива + home + после интерполяции указывает на каталог виртуальной среды.
Директива + module + использует синтаксис импорта модуля Python для загрузки файла + wsgi.py + из внутренней директории проекта.
Директива + socket + указывает на файл в файле + / run / uwsgi + (который должен быть создан строкой + ExecStartPre + в служебном файле, упомянутом выше).

Если вы внесете изменения в файл + / etc / systemd / system / uwsgi.service +, перезагрузите демон, чтобы перечитать определение сервиса и перезапустите процесс uWSGI, набрав:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

Исправление этих проблем должно позволить Nginx правильно найти файл сокета.

connect () для unix: /run/uwsgi/firstsite.sock не удалось (13: разрешение отклонено) *

Это указывает на то, что Nginx не смог подключиться к сокету uWSGI из-за проблем с разрешениями. Обычно это происходит, когда сокет создается в ограниченной среде или если разрешения были неправильными. Хотя процесс uWSGI может создать файл сокета, Nginx не может получить к нему доступ.

Это может произойти, если в любой точке между корневым каталогом (+ / +) файла сокета имеются ограниченные разрешения. Мы можем увидеть разрешения и значения владельца файла сокета и каждого из его родительских каталогов, передав абсолютный путь к нашему файлу сокета команде + namei +:

namei -nom /run/uwsgi/firstsite.sock

Outputf: /run/uwsgi/firstsite.sock
drwxr-xr-x root  root     /
drwxr-xr-x root  root     run
drwxr-xr-x sammy www-data uwsgi
srw-rw---- sammy www-data firstsite.sock

Выходные данные отображают разрешения каждого из компонентов каталога. Изучив разрешения (первый столбец), владельца (второй столбец) и владельца группы (третий столбец), мы можем выяснить, какой тип доступа разрешен к файлу сокета.

В приведенном выше примере каждый из каталогов, ведущих к файлу сокета, имеет разрешения на чтение и выполнение в мире (столбец полномочий для каталогов оканчивается на + r-x + вместо + --- +). Группа + www-data владеет группой над самим сокетом. С этими настройками процесс Nginx должен иметь возможность успешного доступа к сокету.

Если какой-либо из каталогов, ведущих к сокету, не принадлежит группе + www-data + или не имеет разрешения на чтение и выполнение для всего мира, Nginx не сможет получить доступ к сокету. Обычно это означает, что файлы конфигурации имеют ошибку.

Если пути к каталогам имеют слишком ограниченные права доступа или права собственности, посмотрите файл + / etc / systemd / system / uwsgi.service +. Директива + ExecStartPre + отвечает за создание каталога + / run / uwsgi + и назначение владения группой группе + www-data +. Если команды здесь не верны, пути к каталогам могут быть слишком ограничительными.

Если сам файл сокета недоступен для процесса Nginx, настройки, определенные в файлах + .ini + в + / etc / uwsgi / sites +, могут быть неверными. Проверьте значения + chown-socket + и + chmod-socket +, чтобы убедиться, что веб-процессу дано разрешение на доступ к файлам.

Дальнейшее устранение неисправностей

Для дополнительного устранения неполадок журналы могут помочь сузить основные причины. Проверяйте каждый из них по очереди и ищите сообщения, указывающие на проблемные области.

Следующие журналы могут быть полезны:

Проверьте журналы процесса Nginx, набрав: + sudo journalctl -u nginx +
Проверьте журналы доступа Nginx, набрав: + sudo less / var / log / nginx / access.log +
Проверьте журналы ошибок Nginx, набрав: + sudo less / var / log / nginx / error.log +
Проверьте журналы приложения uWSGI, набрав: + sudo journalctl -u uwsgi +

При обновлении конфигурации или приложения вам, вероятно, потребуется перезапустить процессы, чтобы приспособиться к вашим изменениям.

Если вы обновите приложение Django, вы можете перезапустить процесс uWSGI, чтобы получить изменения, набрав:

sudo systemctl restart uwsgi

Если вы измените + uwsgi + файл службы systemd, перезагрузите демон и перезапустите процесс, набрав:

sudo systemctl daemon-reload
sudo systemctl restart uwsgi

Если вы измените конфигурацию блока сервера Nginx, протестируйте конфигурацию, а затем Nginx, набрав:

sudo nginx -t && sudo systemctl restart nginx

Эти команды полезны для получения изменений при настройке конфигурации.

Заключение

В этом руководстве мы создали два проекта Django, каждый в своей виртуальной среде. Мы настроили uWSGI для обслуживания каждого проекта независимо, используя виртуальную среду, настроенную для каждого. После этого мы настроили Nginx в качестве обратного прокси-сервера для обработки клиентских подключений и предоставления правильного проекта в зависимости от запроса клиента.

Django упрощает создание проектов и приложений, предоставляя множество общих частей, позволяя вам сосредоточиться на уникальных элементах. Используя общую цепочку инструментов, описанную в этой статье, вы можете легко обслуживать созданные вами приложения с одного сервера.

TOC

Как обслуживать приложения Django с помощью uWSGI и Nginx в Ubuntu 16.04

Вступление

Предпосылки и цели

Установите и настройте VirtualEnv и VirtualEnvWrapper

Создание проектов Django

Создать первый проект

Создать второй проект

Отказ от виртуальной среды

Настройка сервера приложений uWSGI

Установка uWSGI

Создание файлов конфигурации

Создать системный файл модуля для uWSGI

Установите и настройте Nginx в качестве обратного прокси

Устранение неполадок в Nginx и uWSGI

Nginx показывает страницу по умолчанию вместо приложения Django

Nginx отображает ошибку 502 Bad Gateway вместо приложения Django

Дальнейшее устранение неисправностей

Заключение

Related