TOC

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

Вступление

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

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

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

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

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

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

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

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

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

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

Если вы создаете свои проекты 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 глобально.

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

sudo pip install virtualenv virtualenvwrapper

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

sudo 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

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

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

nano ~///settings.py

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

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

~ / MyProject / MyProject / 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, который мы будем использовать через порт 8080.

Если вы используете брандмауэр + ufw +, вы можете разрешить трафик на порт 8080, набрав:

sudo ufw allow 8080

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

sudo iptables -I INPUT -p tcp --dport 8080 -j ACCEPT

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

./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 полностью отделен от другого, который вы настроили. Это позволяет вам управлять ими независимо и настраивать по мере необходимости.

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

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, на которые опирается программное обеспечение. Мы можем установить это прямо из репозиториев Debian.

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

sudo apt-get install python-dev

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

sudo apt-get install python3-dev

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

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

sudo pip install uwsgi

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

sudo pip3 install uwsgi

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

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

Здесь мы сказали uWSGI использовать нашу виртуальную среду, расположенную в каталоге + ~ / Env +, перейти в каталог нашего проекта и использовать файл + wsgi.py +, хранящийся в нашем внутреннем каталоге ++ обслуживать файл. Для демонстрации мы сказали, чтобы он служил HTTP на порту + 8080 +. Если вы перейдете к доменному имени или IP-адресу сервера в своем браузере, а затем +: 8080 +, вы снова увидите свой сайт (статические элементы в интерфейсе + / admin +, такие как CSS, пока не будут работать ). Когда вы закончите тестирование этой функции, введите CTRL-C в терминале.

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

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

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

sudo mkdir -p /etc/uwsgi/sites
cd /etc/uwsgi/sites

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

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

sudo nano .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 при загрузке.

Мы создадим файл модуля в каталоге + / 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 в качестве нашего обратного прокси-сервера. Это можно скачать из стандартных репозиториев Debian:

sudo apt-get install nginx

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

sudo nano /etc/nginx/sites-available/

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

/ И т.д. / 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 +, чтобы ваш второй проект отвечал на другое доменное имя. Когда вы закончите, это будет выглядеть примерно так:

/ И т.д. / 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: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

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

sudo systemctl restart nginx

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

sudo systemctl start uwsgi

Нам нужно снова настроить наш брандмауэр. Нам больше не нужен открытый порт 8080, так как мы используем прокси через Nginx, поэтому мы можем удалить это правило. Затем мы можем добавить исключение, чтобы разрешить трафик процессу Nginx.

Если вы используете + ufw +, вы можете сделать это, набрав:

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

Если вы используете + iptables +, соответствующие команды будут выглядеть примерно так:

sudo iptables -D INPUT -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT

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

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

sudo systemctl enable nginx
sudo systemctl enable uwsgi

Note

Заключение

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

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

Related