Как настроить Django с Postgres, Nginx и Gunicorn в Ubuntu 18.04
Введение
Django — это мощная веб-инфраструктура, которая поможет запустить ваше приложение или веб-сайт Python. Django включает в себя упрощенный сервер разработки для локального тестирования вашего кода. Если вы предпочитаете что-либо, даже слегка связанное с производством, рекомендуется более безопасный и мощный веб-сервер.
В этом руководстве вы установите и настроите некоторые компоненты в Ubuntu 18.04 для поддержки и обслуживания приложений Django, настроите базу данных PostgreSQL вместо использования базы данных SQLite по умолчанию, а затем настроите сервер приложений Gunicorn для взаимодействия с вашими приложениями. Наконец, вы настроите Nginx для обратного прокси-сервера к Gunicorn, что даст вам доступ к его функциям безопасности и производительности для обслуживания ваших приложений.
Предпосылки
Для выполнения этого руководства вам потребуется настроенный сервер Ubuntu 18.04, пользователь без полномочий root с настроенными привилегиями sudo и включенный брандмауэр. Следуйте нашему руководству по начальной настройке сервера Ubuntu 18.04, чтобы начать работу.
Шаг 1 — Установка пакетов из репозиториев Ubuntu
Начните с загрузки и установки всех необходимых элементов из репозиториев Ubuntu. Используйте диспетчер пакетов Python pip для установки дополнительных компонентов позже.
Сначала обновите локальный индекс пакетов apt, а затем загрузите и установите пакеты:
- sudo apt update
Затем установите свои пакеты. Это зависит от того, какую версию Python будет использовать ваш проект.
Если вы используете Django с Python 3, выполните следующее:
- sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl
Django 1.11 — это последний выпуск Django, поддерживающий Python 2. Если вы начинаете новые проекты, настоятельно рекомендуется выбрать Python 3. Если вам все еще нужно использовать Python 2, выполните следующее:
- sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl
Это установит pip, файлы разработки Python, необходимые для последующей сборки Gunicorn, систему базы данных Postgres и библиотеки, необходимые для взаимодействия с ней, а также веб-сервер Nginx.
Шаг 2 — Создание базы данных PostgreSQL и пользователя
На этом шаге вы создадите базу данных и пользователя базы данных для своего приложения Django с PostgreSQL, также известного как «Postgres».
По умолчанию Postgres использует схему аутентификации, называемую одноранговой аутентификацией для локальных подключений. Это означает, что если имя пользователя операционной системы совпадает с действительным именем пользователя Postgres, этот пользователь может войти в систему без дополнительной аутентификации.
Во время установки Postgres был создан пользователь операционной системы с именем postgres, соответствующий пользователю-администратору postgres PostgreSQL. Вам необходимо использовать этого пользователя для выполнения административных задач. Войдите в интерактивный сеанс Postgres с помощью sudo и передайте имя пользователя с параметром -u:
- sudo -u postgres psql
Вы получите приглашение PostgreSQL, где вы можете настроить свои требования. Сначала создайте базу данных для вашего проекта:
- CREATE DATABASE myproject;
Примечание. Каждый оператор Postgres должен заканчиваться точкой с запятой. Убедитесь, что ваша команда заканчивается единицей, если у вас возникли проблемы.
Затем создайте пользователя базы данных для вашего проекта и выберите безопасный пароль:
- CREATE USER myprojectuser WITH PASSWORD 'password';
OutputCREATE ROLE
После этого измените несколько параметров подключения для созданного вами пользователя. Это ускорит операции с базой данных, так что правильные значения не нужно запрашивать и устанавливать каждый раз при установлении соединения.
Установите кодировку по умолчанию на UTF-8, которую ожидает Django:
- ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
OutputALTER ROLE
Затем установите схему изоляции транзакций по умолчанию на read commit, чтобы заблокировать чтение незафиксированных транзакций:
- ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
OutputALTER ROLE
Поскольку ваши проекты Django будут настроены на использование UTC по умолчанию, установите соответствующий часовой пояс:
- ALTER ROLE myprojectuser SET timezone TO 'UTC';
OutputALTER ROLE
Это все рекомендации из проекта Django.
Теперь предоставьте вашему новому пользователю доступ для администрирования вашей новой базы данных:
- GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;
OutputGRANT
Когда вы закончите, выйдите из приглашения PostgreSQL, выполнив следующее:
- \q
Теперь Postgres успешно настроен, так что Django может подключаться к своей базе данных и управлять ею.
Шаг 3 — Создание виртуальной среды Python для вашего проекта
Теперь, когда у вас есть база данных, вы можете приступить к подготовке остальных требований вашего проекта. Это влечет за собой установку требований Python в виртуальной среде для более эффективного управления. Установка Django в виртуальную среду, специфичную для вашего проекта, позволит обрабатывать ваши проекты и их требования отдельно.
Для этого вам потребуется доступ к команде virtualenv. Начните с установки с помощью pip.
Если вы используете Python 3, обновите pip:
- sudo -H pip3 install --upgrade pip
Затем установите пакет:
- sudo -H pip3 install virtualenv
Если вы используете Python 2, обновите pip:
- sudo -H pip install --upgrade pip
Затем установите пакет:
- sudo -H pip install virtualenv
Установив virtualenv, вы можете начать формирование своего проекта. Сначала создайте каталог, в котором вы можете хранить файлы проекта. Здесь мы назовем его myprojectdir, не стесняйтесь называть его по своему усмотрению:
- mkdir ~/myprojectdir
Затем перейдите в этот каталог:
- cd ~/myprojectdir
В каталоге проекта создайте виртуальную среду Python:
- virtualenv myprojectenv
Это создаст каталог с именем myprojectenv в вашем каталоге myprojectdir. Внутри он установит локальную версию Python и локальную версию pip. Вы можете использовать это для установки и настройки изолированной среды Python для вашего проекта.
Но перед установкой требований Python для вашего проекта вам необходимо активировать виртуальную среду:
- source myprojectenv/bin/activate
Ваше приглашение должно измениться, чтобы указать, что вы сейчас работаете в виртуальной среде Python. Это будет выглядеть примерно так: (myprojectenv)пользователь@хост:~/myprojectdir$.
При активной виртуальной среде установите Django, Gunicorn и адаптер PostgreSQL psycopg2 с локальным экземпляром pip:
Примечание. Когда виртуальная среда активирована (когда перед приглашением стоит (myprojectenv)), используйте pip вместо pip3, даже если вы используют Python 3. Копия инструмента в виртуальной среде всегда называется pip, независимо от версии Python.
- pip install django gunicorn psycopg2-binary
Теперь у вас есть все программное обеспечение, необходимое для запуска проекта Django.
Шаг 4 — Создание и настройка нового проекта Django
Теперь, когда ваши компоненты Python установлены, вы можете создавать настоящие файлы проекта Django. Поскольку у вас уже есть каталог проекта, скажите Django установить файлы здесь. Он создаст каталог второго уровня с фактическим кодом, что является нормальным, и поместит сценарий управления в этот каталог. Это важно, потому что вы определяете каталог явно, вместо того, чтобы позволить Django принимать решения относительно вашего текущего каталога:
- django-admin.py startproject myproject ~/myprojectdir
На этом этапе каталог вашего проекта (в данном случае ~/myprojectdir) будет иметь следующее содержимое:
~/myprojectdir/manage.py: сценарий управления проектом Django.~/myprojectdir/myproject/: пакет проекта Django. Он будет содержать файлы__init__.py,settings.py,urls.pyиwsgi.py.~/myprojectdir/myprojectenv/: созданный ранее каталог виртуальной среды.
Следующее, что нужно сделать с вашими недавно созданными файлами проекта, — это настроить параметры. Откройте файл настроек в предпочитаемом вами текстовом редакторе. Здесь мы будем использовать nano:
- nano ~/myprojectdir/myproject/settings.py
Начните с поиска директивы ALLOWED_HOSTS. Это определяет список адресов серверов или доменных имен, которые можно использовать для подключения к экземпляру Django. Любые входящие запросы с заголовком Host, которого нет в этом списке, вызовут исключение. Django требует, чтобы вы установили это, чтобы предотвратить определенный класс уязвимостей безопасности.
В квадратных скобках укажите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в цитатах с элементами, разделенными запятой. Если вы предпочитаете запросы для всего домена и любых поддоменов, поставьте точку в начале записи. В следующем фрагменте есть несколько закомментированных примеров, используемых для демонстрации:
Примечание. Обязательно укажите localhost в качестве одного из параметров, поскольку вы будете проксировать соединения через локальный экземпляр Nginx.
. . .
# 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 = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']
Далее найдите раздел, который настраивает доступ к базе данных. Он начнется с БАЗЫ ДАННЫХ. Конфигурация в файле предназначена для базы данных SQLite. Поскольку вы уже создали базу данных PostgreSQL для своего проекта, вам необходимо настроить эти параметры.
Обновите настройки, указав информацию о базе данных PostgreSQL. Затем скажите Django использовать адаптер psycopg2, который вы установили с помощью pip. Вам также необходимо указать имя базы данных, имя пользователя только что созданного пользователя базы данных, пароль пользователя базы данных и указать, что базу данных можно найти на локальном компьютере. Вы можете оставить настройку PORT пустой строкой:
. . .
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2',
'NAME': 'myproject',
'USER': 'myprojectuser',
'PASSWORD': 'password',
'HOST': 'localhost',
'PORT': '',
}
}
. . .
Затем перейдите к концу файла и добавьте параметр, указывающий, где следует размещать статические файлы. Это необходимо для того, чтобы Nginx мог обрабатывать запросы на эти элементы. Следующая строка указывает Django поместить их в каталог с именем static в базовом каталоге проекта:
. . .
STATIC_URL = '/static/'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
Сохраните и закройте файл, когда закончите. Если вы используете nano, вы можете сделать это, нажав CTRL + X, затем Y и ENTER.
Шаг 5 — Завершение начальной настройки проекта
Следующим шагом будет миграция исходной схемы базы данных в вашу базу данных PostgreSQL с использованием следующего сценария управления:
- ~/myprojectdir/manage.py makemigrations
- ~/myprojectdir/manage.py migrate
Создайте администратора для проекта:
- ~/myprojectdir/manage.py createsuperuser
Вам нужно будет выбрать имя пользователя, указать адрес электронной почты и выбрать, а затем подтвердить пароль.
Соберите все статическое содержимое в каталог, который вы настроили, выполнив следующее:
- ~/myprojectdir/manage.py collectstatic
Затем статические файлы будут помещены в каталог с именем static в каталоге вашего проекта.
Если вы следовали руководству по первоначальной настройке сервера, у вас должен быть брандмауэр UFW, защищающий ваш сервер. Чтобы протестировать сервер разработки, вам необходимо разрешить доступ к порту, который вы будете использовать. В этом случае создайте исключение для порта 8000:
- sudo ufw allow 8000
Наконец, проверьте свой проект, запустив сервер разработки Django с помощью следующей команды:
- ~/myprojectdir/manage.py runserver 0.0.0.0:8000
В веб-браузере перейдите на доменное имя или IP-адрес вашего сервера, а затем введите :8000:
http://server_domain_or_IP:8000
Вы должны получить следующую индексную страницу Django по умолчанию:
Если вы добавите /admin в конец URL-адреса в адресной строке, вам будет предложено ввести имя пользователя и пароль администратора, которые вы создали с помощью команды createsuperuser:
После аутентификации вы можете получить доступ к административному интерфейсу Django по умолчанию:
Когда вы закончите исследование, нажмите CTRL + C в окне терминала, чтобы закрыть сервер разработки.
Шаг 6 — Тестирование способности Gunicorn обслуживать проект
Прежде чем покинуть виртуальную среду, протестируйте Gunicorn, чтобы убедиться, что он может обслуживать приложение. Вы можете сделать это, сначала перейдя в каталог вашего проекта:
- cd ~/myprojectdir
Затем запустите gunicorn, чтобы загрузить модуль WSGI проекта:
- gunicorn --bind 0.0.0.0:8000 myproject.wsgi
Это запустит Gunicorn на том же интерфейсе, на котором работал сервер разработки Django. Вы можете вернуться и снова протестировать приложение.
Примечание. К административному интерфейсу не применяются никакие стили, поскольку Gunicorn не знает, как найти статический контент CSS, ответственный за это.
Напомним, что вы передали Gunicorn модуль, указав относительный путь к каталогу файла wsgi.py Django, который является точкой входа в ваше приложение, используя синтаксис модуля Python. Gunicorn служит интерфейсом для вашего приложения, переводя клиентские запросы из HTTP в вызовы Python, которые может обрабатывать ваше приложение. Внутри этого файла была определена функция с именем application, которая используется для связи с приложением. Если вам интересно, вы можете узнать больше о спецификации WSGI.
Когда вы закончите тестирование, нажмите CTRL + C в окне терминала, чтобы остановить Gunicorn.
Теперь вы закончили настройку приложения Django и можете деактивировать виртуальную среду:
- deactivate
Индикатор виртуальной среды в вашем приглашении будет удален.
Шаг 7 — Создание сокета systemd и служебных файлов для Gunicorn
Теперь, когда вы проверили, что Gunicorn может взаимодействовать с вашим приложением Django, вам следует реализовать более надежный способ запуска и остановки сервера приложений. Для этого вы создадите сервис systemd и файлы сокетов.
Сокет Gunicorn будет создан при загрузке и будет прослушивать подключения. Когда происходит соединение, systemd автоматически запускает процесс Gunicorn для обработки соединения.
Начните с создания и открытия файла сокета systemd для Gunicorn с правами sudo в предпочитаемом вами текстовом редакторе:
- sudo nano /etc/systemd/system/gunicorn.socket
Внутри создайте раздел [Unit] для описания сокета, раздел [Socket] для определения местоположения сокета и раздел [Install]. раздел, чтобы убедиться, что сокет создан в нужное время:
[Unit]
Description=gunicorn socket
[Socket]
ListenStream=/run/gunicorn.sock
[Install]
WantedBy=sockets.target
Сохраните и закройте файл, когда закончите.
Затем создайте и откройте служебный файл systemd для Gunicorn с правами sudo в предпочитаемом вами текстовом редакторе. Имя файла службы должно совпадать с именем файла сокета, за исключением расширения:
- sudo nano /etc/systemd/system/gunicorn.service
Начните с раздела [Unit], который используется для указания метаданных и зависимостей. Добавьте здесь описание вашей службы и сообщите системе инициализации, чтобы она запускала эту службу только после того, как будет достигнута цель сети. Поскольку ваша служба использует сокет из файла сокета, вам необходимо включить директиву Requires, чтобы указать эту связь:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
Затем добавьте раздел [Service] и укажите пользователя и группу, под которой вы хотите запустить процесс. Предоставьте право собственности на процесс своей обычной учетной записи пользователя, поскольку он владеет всеми соответствующими файлами. Затем передайте групповое владение группе www-data, чтобы Nginx мог взаимодействовать с Gunicorn.
После этого наметьте рабочий каталог и укажите команду для запуска службы. В этом случае укажите полный путь к исполняемому файлу Gunicorn, установленному в вашей виртуальной среде. Затем привяжите процесс к сокету Unix, который вы создали в каталоге /run, чтобы процесс мог взаимодействовать с Nginx. Записывайте все данные в стандартный вывод, чтобы процесс journald мог собирать журналы Gunicorn. Вы также можете указать здесь любые дополнительные настройки Gunicorn. Для нашего примера мы указали 3 рабочих процесса:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application
Наконец, добавьте раздел [Install]. Это сообщит systemd, с чем связать эту службу, если вы включите ее запуск при загрузке. Вы хотите, чтобы эта служба запускалась, когда обычная многопользовательская система запущена и работает:
[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target
[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
--access-logfile - \
--workers 3 \
--bind unix:/run/gunicorn.sock \
myproject.wsgi:application
[Install]
WantedBy=multi-user.target
На этом ваш служебный файл systemd готов. Сохраните и закройте файл сейчас.
Затем запустите сокет Gunicorn. Это создаст файл сокета в /run/gunicorn.sock сейчас и при загрузке:
- sudo systemctl start gunicorn.socket
Затем включите его, чтобы при подключении к этому сокету systemd автоматически запускал gunicorn.service для его обработки:
- sudo systemctl enable gunicorn.socket
Вы можете подтвердить, что операция прошла успешно, проверив файл сокета.
Шаг 8 — Проверка файла сокета Gunicorn
Проверьте статус процесса, чтобы узнать, удалось ли ему запуститься:
- sudo systemctl status gunicorn.socket
Output● gunicorn.socket - gunicorn socket
Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
Active: active (listening) since Thu 2021-12-02 19:58:48 UTC; 14s ago
Triggers: ● gunicorn.service
Listen: /run/gunicorn.sock (Stream)
Tasks: 0 (limit: 1136)
Memory: 0B
CGroup: /system.slice/gunicorn.socket
Dec 02 19:58:48 gunicorn systemd[1]: Listening on gunicorn socket.
Затем проверьте наличие файла gunicorn.sock в каталоге /run:
- file /run/gunicorn.sock
Output/run/gunicorn.sock: socket
Если команда systemctl status указывает, что произошла ошибка, или если вы не нашли файл gunicorn.sock в каталоге, это указывает на то, что сокет Gunicorn был создан неправильно. . Проверьте журналы сокета Gunicorn, выполнив следующее:
- sudo journalctl -u gunicorn.socket
Прежде чем продолжить, проверьте файл /etc/systemd/system/gunicorn.socket, чтобы исправить все проблемы.
Шаг 9 — Проверка активации сокета
Если вы только запустили модуль gunicorn.socket, gunicorn.service еще не будет активен, так как сокет не получил никаких подключений. Проверьте статус:
- sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
Active: inactive (dead)
Чтобы проверить механизм активации сокета, отправьте соединение с сокетом через curl:
- curl --unix-socket /run/gunicorn.sock localhost
Вы должны получить вывод HTML из вашего приложения в терминале. Это подтверждает, что Gunicorn запущен и может обслуживать ваше приложение Django. Вы можете убедиться, что служба Gunicorn запущена, еще раз проверив статус:
- sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset
Active: active (running) since Tue 2021-11-23 22:55:12 UTC; 11s ago
Main PID: 11002 (gunicorn)
Tasks: 4 (limit: 1151)
CGroup: /system.slice/gunicorn.service
├─11002 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
├─11018 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
├─11020 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
└─11022 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
. . .
Если выходные данные curl или выходные данные systemctl status указывают на то, что возникла проблема, проверьте дополнительные сведения в журналах:
- sudo journalctl -u gunicorn
Проверьте файл /etc/systemd/system/gunicorn.service на наличие проблем. Если вы вносите изменения в файл /etc/systemd/system/gunicorn.service, перезагрузите демон, чтобы заново прочитать определение службы:
- sudo systemctl daemon-reload
Затем перезапустите процесс Gunicorn:
- sudo systemctl restart gunicorn
Если возникнут подобные проблемы, устраните их, прежде чем продолжить.
Шаг 10 — Настройте Nginx для передачи прокси-сервера Gunicorn
Теперь, когда Gunicorn настроен, теперь вы настроите Nginx для передачи трафика процессу.
Начните с создания и открытия нового блока сервера в каталоге sites-available Nginx:
- sudo nano /etc/nginx/sites-available/myproject
Внутри откройте новый серверный блок. Начните с указания, что этот блок должен прослушивать обычный порт 80 и что он должен отвечать на доменное имя или IP-адрес вашего сервера:
server {
listen 80;
server_name server_domain_or_IP;
}
Затем укажите Nginx игнорировать любые проблемы с поиском фавикона. Кроме того, сообщите ему, где найти статические ресурсы, которые вы собрали в каталоге ~/myprojectdir/static. Все эти файлы имеют стандартный префикс URI /static, поэтому вы можете создать блок местоположения для соответствия этим запросам:
server {
listen 80;
server_name server_domain_or_IP;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/sammy/myprojectdir;
}
}
Наконец, создайте блок location/{} для соответствия всем остальным запросам. Внутри этого места включите стандартный файл proxy_params из установки Nginx, а затем передайте трафик непосредственно в сокет Gunicorn:
server {
listen 80;
server_name server_domain_or_IP;
location = /favicon.ico { access_log off; log_not_found off; }
location /static/ {
root /home/sammy/myprojectdir;
}
location / {
include proxy_params;
proxy_pass http://unix:/run/gunicorn.sock;
}
}
Сохраните и закройте файл, когда закончите. Теперь вы можете включить файл, связав его с каталогом sites-enabled:
- sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled
Проверьте конфигурацию Nginx на наличие синтаксических ошибок:
- sudo nginx -t
Если об ошибках не сообщается, продолжайте и перезапустите Nginx:
- sudo systemctl restart nginx
Поскольку вам больше не нужен доступ к серверу разработки, настройте параметры брандмауэра, удалив правило для открытия порта 8000:
- sudo ufw delete allow 8000
Затем разрешите нормальный трафик на портах 80 и 443 — тем самым разрешив соединения HTTP и HTTPS соответственно — с помощью следующей команды:
- sudo ufw allow 'Nginx Full'
Теперь вы сможете перейти на домен или IP-адрес вашего сервера, чтобы просмотреть свое приложение.
Примечание. После настройки Nginx следующим шагом должна быть защита трафика на сервер с помощью SSL/TLS. Это важно, потому что без него вся информация, включая пароли, пересылается по сети в виде обычного текста.
Если у вас есть доменное имя, самый быстрый способ получить SSL-сертификат для защиты вашего трафика — использовать Let’s Encrypt. Вы можете настроить его, следуя нашему руководству «Как защитить Let’s Encrypt с помощью Nginx в Ubuntu 18.04». Следуйте инструкциям, используя блок сервера Nginx, который вы создали в этом руководстве.
Если у вас нет доменного имени, вы все равно можете защитить свой сайт для тестирования и обучения с помощью самозаверяющего SSL-сертификата. Опять же, следуйте процессу, используя блок сервера Nginx, который вы создали в этом руководстве.
Шаг 11 — Устранение неполадок Nginx и Gunicorn
Если у вас возникли проблемы с приложением, в следующих разделах приведены рекомендации по устранению неполадок при установке.
Nginx показывает страницу по умолчанию вместо приложения Django
Если Nginx отображает страницу по умолчанию вместо прокси для вашего приложения, это обычно означает, что вам нужно настроить server_name в /etc/nginx/sites-available/myproject, чтобы он указывал на IP-адрес или доменное имя вашего сервера.
Nginx использует директиву server_name, чтобы определить, какой серверный блок использовать для ответа на запросы. Если вы получаете страницу Nginx по умолчанию, это признак того, что Nginx не смог явно сопоставить запрос с блоком сервера, поэтому он возвращается к блоку по умолчанию, определенному в /etc/nginx/sites-available. /по умолчанию.
server_name в блоке сервера вашего проекта должен быть более конкретным, чем в блоке сервера по умолчанию, который будет выбран.
Nginx отображает ошибку 502 Bad Gateway вместо приложения Django
Ошибка 502 указывает на то, что Nginx не может успешно проксировать запрос. Широкий спектр проблем с конфигурацией выражается в ошибке 502, поэтому для правильного устранения неполадок требуется дополнительная информация.
Основное место, где можно найти дополнительную информацию, — это журналы ошибок Nginx. Как правило, это скажет вам, какие условия вызвали проблемы во время проксирования. Проверьте журналы ошибок Nginx, выполнив следующее:
- sudo tail -F /var/log/nginx/error.log
Теперь сделайте еще один запрос в своем браузере, чтобы сгенерировать новую ошибку (попробуйте обновить страницу). Вы должны получить новое сообщение об ошибке, записанное в журнал. Если вы прочитаете сообщение, это должно помочь вам сузить круг проблемы.
Вы можете получить сообщение, подобное следующему:
connect() to unix:/run/gunicorn.sock не удалось (2: нет такого файла или каталога)
Это указывает на то, что Nginx не удалось найти файл gunicorn.sock в указанном месте. Вы должны сравнить местоположение proxy_pass, указанное в файле /etc/nginx/sites-available/myproject, с фактическим местоположением gunicorn.sock. файл, созданный системным модулем gunicorn.socket.
Если вы не можете найти файл gunicorn.sock в каталоге /run, это обычно означает, что файл сокета systemd не смог его создать. Вернитесь к разделу проверки файла сокета Gunicorn, чтобы выполнить шаги по устранению неполадок для Gunicorn.
Другое сообщение может выглядеть следующим образом:
connect() к unix:/run/gunicorn.sock не удалось (13: Отказано в доступе)
Это указывает на то, что Nginx не удалось подключиться к сокету Gunicorn из-за проблем с разрешениями. Это может произойти, если процедура выполняется с использованием пользователя root вместо пользователя sudo. Хотя systemd может создать файл сокета Gunicorn, Nginx не может получить к нему доступ.
Это может произойти, если в любой точке между корневым каталогом (/) и файлом gunicorn.sock имеются ограниченные разрешения. Вы можете просмотреть значения разрешений и владельцев файла сокета и каждого из его родительских каталогов, передав абсолютный путь к файлу сокета команде namei:
- namei -l /run/gunicorn.sock
Outputf: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock
В выходных данных отображаются разрешения для каждого из компонентов каталога. Просмотрев разрешения (первый столбец), владельца (второй столбец) и владельца группы (третий столбец), вы можете выяснить, какой тип доступа разрешен к файлу сокета.
В этом примере файл сокета и каждый из каталогов, ведущих к нему, имеют всемирные разрешения на чтение и выполнение (столбец разрешений для каталогов заканчивается r-x вместо ---). Процесс Nginx должен успешно получить доступ к сокету.
Если какой-либо из каталогов, ведущих к сокету, не имеет разрешения на чтение и выполнение для всего мира, Nginx не сможет получить доступ к сокету, не разрешив права на чтение и выполнение для всего мира или предоставив групповое владение группе, частью которой является Nginx. .
Django отображает: «не удалось подключиться к серверу: соединение отклонено»
Одно сообщение, которое вы можете получить от Django при попытке доступа к частям приложения в веб-браузере:
OperationalError at /admin/login/
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
Это указывает на то, что Django не может подключиться к базе данных Postgres. Убедитесь, что экземпляр Postgres запущен:
- sudo systemctl status postgresql
Если это не так, вы можете запустить его и включить автоматический запуск при загрузке (если он еще не настроен для этого):
- sudo systemctl start postgresql
- sudo systemctl enable postgresql
Если у вас по-прежнему возникают проблемы, убедитесь, что параметры базы данных, определенные в файле ~/myprojectdir/myproject/settings.py, верны.
Дальнейшее устранение неполадок
Для дополнительного устранения неполадок журналы могут помочь сузить основные причины. Проверьте каждый из них и обратите внимание на любые сообщения, указывающие на проблемные области.
Следующие журналы могут быть полезны:
- Проверьте журналы процессов Nginx:
sudo journalctl -u nginx - Проверьте журналы доступа Nginx:
sudo less /var/log/nginx/access.log - Проверьте журналы ошибок Nginx:
sudo less /var/log/nginx/error.log - Проверьте журналы приложения Gunicorn:
sudo journalctl -u gunicorn - Проверьте журналы сокета Gunicorn:
sudo journalctl -u gunicorn.socket
При обновлении конфигурации или приложения вам, вероятно, потребуется перезапустить процессы, чтобы приспособиться к вашим изменениям.
Если вы обновите свое приложение Django, вы можете перезапустить процесс Gunicorn, чтобы применить изменения, выполнив следующее:
- sudo systemctl restart gunicorn
Если вы меняете сокет Gunicorn или служебные файлы, перезагрузите демон и перезапустите процесс, выполнив следующее:
- sudo systemctl daemon-reload
- sudo systemctl restart gunicorn.socket gunicorn.service
Если вы измените конфигурацию блока сервера Nginx, протестируйте конфигурацию, а затем Nginx, выполнив следующее:
- sudo nginx -t && sudo systemctl restart nginx
Эти команды полезны для применения изменений при настройке конфигурации.
Заключение
В этом руководстве вы настроили проект Django в собственной виртуальной среде и настроили Gunicorn для перевода клиентских запросов, чтобы Django мог их обрабатывать. После этого вы настраиваете Nginx в качестве обратного прокси-сервера для обработки клиентских подключений и обслуживания правильного проекта в зависимости от запроса клиента.
Django делает создание проектов и приложений удобным, предоставляя множество общих частей, позволяя вам сосредоточиться на уникальных элементах. Используя общую цепочку инструментов, описанную в этом руководстве, вы можете обслуживать создаваемые вами приложения с одного сервера.