Как настроить Django с Postgres, Nginx и Gunicorn в Debian 11
Введение
Django — это мощная веб-инфраструктура, которая может помочь вам запустить ваше приложение Python или веб-сайт. Django включает в себя сервер разработки для локального тестирования вашего кода, но для всего, что хоть немного связано с производством, требуется более безопасный и мощный веб-сервер.
В этом руководстве вы установите и настроите некоторые компоненты в Debian 11 для поддержки и обслуживания приложений Django. Вы будете настраивать базу данных PostgreSQL вместо использования базы данных SQLite по умолчанию. Вы настроите сервер приложений Gunicorn для взаимодействия с вашими приложениями. Затем вы настроите Nginx для обратного прокси-сервера к Gunicorn, что даст вам доступ к его функциям безопасности и производительности для обслуживания ваших приложений.
Предпосылки и цели
Чтобы выполнить это руководство, у вас должен быть свежий экземпляр сервера Debian 11 с базовым брандмауэром и пользователем без полномочий root с настроенными привилегиями sudo. Вы можете узнать, как это настроить, изучив наше руководство по начальной настройке сервера.
Вы будете устанавливать Django в виртуальной среде. Установка Django в среду, специфичную для вашего проекта, позволит обрабатывать ваши проекты и их требования отдельно.
После того, как ваша база данных и приложение будут запущены и запущены, вы установите и настроите сервер приложений Gunicorn. Это будет служить интерфейсом для нашего приложения, переводя клиентские запросы из HTTP в вызовы Python, которые может обрабатывать наше приложение. Затем вы настроите Nginx перед Gunicorn, чтобы воспользоваться его высокопроизводительными механизмами обработки соединений и функциями безопасности.
Давайте начнем.
Установка пакетов из репозиториев Debian
Чтобы начать процесс, вы загрузите и установите все необходимые элементы из репозиториев Debian. Позже вы будете использовать диспетчер пакетов Python pip для установки дополнительных компонентов.
Сначала вам нужно обновить локальный индекс пакетов apt, а затем загрузить и установить пакеты.
- sudo apt update
- sudo apt install python3-venv python3-dev libpq-dev postgresql postgresql-contrib nginx curl
Эта команда установит инструмент для создания виртуальных сред для ваших проектов Python, файлы разработки Python, необходимые для последующей сборки Gunicorn, систему базы данных Postgres и библиотеки, необходимые для взаимодействия с ней, а также веб-сервер Nginx.
Создание базы данных PostgreSQL и пользователя
Теперь вы можете сразу приступить к созданию базы данных и пользователя базы данных для нашего приложения Django.
По умолчанию Postgres использует схему аутентификации, называемую «одноранговой аутентификацией» для локальных подключений. По сути, это означает, что если имя пользователя операционной системы совпадает с действительным именем пользователя Postgres, этот пользователь может войти в систему без дополнительной аутентификации.
Во время установки Postgres был создан пользователь операционной системы с именем postgres, соответствующий пользователю-администратору postgres PostgreSQL. Вам необходимо использовать этого пользователя для выполнения административных задач. Вы можете использовать sudo и передать имя пользователя с опцией -u.
Войдите в интерактивный сеанс Postgres, набрав:
- sudo -u postgres psql
Вам будет предоставлено приглашение PostgreSQL, в котором вы можете настроить наши требования.
Сначала создайте базу данных для вашего проекта:
- CREATE DATABASE myproject;
Примечание. Каждый оператор Postgres должен заканчиваться точкой с запятой, поэтому убедитесь, что ваша команда заканчивается на единицу, если у вас возникли проблемы.
Далее создадим пользователя базы данных для нашего проекта. Обязательно выберите безопасный пароль:
- CREATE USER myprojectuser WITH PASSWORD 'password';
После этого вы измените несколько параметров подключения для только что созданного пользователя. Это ускорит операции с базой данных, так что правильные значения не нужно запрашивать и устанавливать каждый раз при установлении соединения.
Вы установите кодировку символов по умолчанию на UTF-8, которую ожидает Django. Вы также устанавливаете схему изоляции транзакций по умолчанию на «чтение зафиксированных», которая блокирует чтение из незафиксированных транзакций. Наконец, вы устанавливаете часовой пояс. По умолчанию проекты Django будут настроены на использование UTC. Это все рекомендации самого проекта Django:
- ALTER ROLE myprojectuser SET client_encoding TO 'utf8';
- ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';
- ALTER ROLE myprojectuser SET timezone TO 'UTC';
Теперь вы можете предоставить новому пользователю доступ для администрирования новой базы данных:
- GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;
Когда вы закончите, выйдите из командной строки PostgreSQL, набрав:
- \q
Теперь Postgres настроен так, что Django может подключаться к своей базе данных и управлять ею.
Создание виртуальной среды Python для вашего проекта
Теперь, когда у вас есть готовая база данных, вы можете приступить к выполнению остальных требований вашего проекта. Вы установите требования Python в виртуальной среде.
Сначала создайте и перейдите в каталог, в котором вы можете хранить файлы проекта:
- mkdir ~/myprojectdir
- cd ~/myprojectdir
В каталоге проекта создайте виртуальную среду Python, набрав:
- python3 -m venv 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.
Создание и настройка нового проекта Django
Теперь, когда ваши компоненты Python установлены, вы можете создавать настоящие файлы проекта Django.
Создание проекта Джанго
Поскольку у вас уже есть каталог проекта, вы скажете Django установить файлы здесь. Он создаст каталог второго уровня с фактическим кодом, что является нормальным, и поместит сценарий управления в этот каталог. Ключом к этому является то, что вы определяете каталог явно, вместо того, чтобы позволить Django принимать решения относительно нашего текущего каталога:
- django-admin startproject myproject ~/myprojectdir
На этом этапе каталог вашего проекта (~/myprojectdir в данном примере) должен иметь следующее содержимое:
~/myprojectdir/manage.py: сценарий управления проектом Django.~/myprojectdir/myproject/: пакет проекта Django. Он должен содержать файлы__init__.py,settings.py,urls.py,asgi.pyифайлы wsgi.py.~/myprojectdir/myprojectenv/: созданный ранее каталог виртуальной среды.
Настройка параметров проекта
Первое, что вы должны сделать с вашими вновь созданными файлами проекта, это настроить параметры. Откройте файл настроек с помощью nano или вашего любимого текстового редактора:
- nano ~/myprojectdir/myproject/settings.py
Начните с поиска директивы ALLOWED_HOSTS. Это определяет список адресов серверов или доменных имен, которые могут использоваться для подключения к экземпляру Django. Любые входящие запросы с заголовком Host, которого нет в этом списке, вызовут исключение. Django требует, чтобы вы установили это, чтобы предотвратить определенный класс уязвимостей безопасности.
В квадратных скобках укажите IP-адреса или доменные имена, связанные с вашим сервером Django. Каждый элемент должен быть указан в цитатах с элементами, разделенными запятой. Если вы хотите запрашивать весь домен и любые поддомены, поставьте точку в начале записи. В приведенном ниже фрагменте есть несколько закомментированных примеров, используемых для демонстрации:
Примечание. Обязательно укажите localhost в качестве одного из параметров, поскольку вы будете проксировать соединения через локальный экземпляр Nginx.
. . .
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/'
# Default primary key field type
# https://docs.djangoproject.com/en/4.0/ref/settings/#default-auto-field
DEFAULT_AUTO_FIELD = 'django.db.models.BigAutoField'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')
Сохраните и закройте файл, когда закончите. Если вы используете nano, нажмите Ctrl+X, затем, когда будет предложено, Y, а затем Enter.
Завершение первоначальной настройки проекта
Теперь вы можете перенести исходную схему базы данных в нашу базу данных 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 в окне терминала, чтобы выключить сервер разработки.
Тестирование способности Gunicorn обслуживать проект
Последнее, что вам нужно сделать, прежде чем покинуть виртуальную среду, — это протестировать Gunicorn, чтобы убедиться, что он может обслуживать приложение. Вы можете сделать это, войдя в каталог проекта и используя gunicorn для загрузки модуля WSGI проекта:
- cd ~/myprojectdir
- gunicorn --bind 0.0.0.0:8000 myproject.wsgi
Это запустит Gunicorn на том же интерфейсе, на котором работал сервер разработки Django. Вы можете вернуться и снова протестировать приложение в своем браузере.
Примечание. К интерфейсу администратора не будут применены стили, поскольку Gunicorn не знает, как найти статический контент CSS, ответственный за это.
Вы передали Gunicorn модуль, указав относительный путь к файлу Django wsgi.py, который является точкой входа в ваше приложение, используя синтаксис модуля Python. Внутри этого файла определена функция с именем application, которая используется для связи с приложением. Чтобы узнать больше о спецификации WSGI, нажмите здесь.
Когда вы закончите тестирование, нажмите CTRL-C в окне терминала, чтобы остановить Gunicorn.
Вы закончили настройку приложения Django. Вы можете выйти из нашей виртуальной среды, набрав:
- deactivate
Индикатор виртуальной среды в вашем приглашении будет удален.
Создание системных сокетов и служебных файлов для 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 сейчас и при загрузке. Когда к этому сокету будет установлено соединение, systemd автоматически запустит gunicorn.service для его обработки:
- sudo systemctl start gunicorn.socket
- sudo systemctl enable gunicorn.socket
Вы можете подтвердить, что операция прошла успешно, проверив файл сокета.
Проверка файла сокета Gunicorn
Проверьте статус процесса, чтобы узнать, удалось ли ему запуститься:
- sudo systemctl status gunicorn.socket
Вы должны получить такой вывод:
Output● gunicorn.socket - gunicorn socket
Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor preset: enabled)
Active: active (listening) since Thu 2022-08-04 19:02:54 UTC; 5s ago
Triggers: ● gunicorn.service
Listen: /run/gunicorn.sock (Stream)
CGroup: /system.slice/gunicorn.socket
Apr 18 17:53:25 django 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, чтобы исправить все проблемы, прежде чем продолжить.
Тестирование активации сокета
В настоящее время, если вы только запустили модуль 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)
TriggeredBy: ● gunicorn.socket
Чтобы протестировать механизм активации сокета, вы можете отправить соединение с сокетом через 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: enabled)
Active: active (running) since Thu 2022-08-04 19:03:51 UTC; 5s ago
TriggeredBy: ● gunicorn.socket
Main PID: 102674 (gunicorn)
Tasks: 4 (limit: 4665)
Memory: 94.2M
CPU: 885ms
CGroup: /system.slice/gunicorn.service
├─102674 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
├─102675 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
├─102676 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
└─102677 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
Apr 18 17:54:49 django systemd[1]: Started gunicorn daemon.
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Starting gunicorn 20.1.0
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Listening at: unix:/run/gunicorn.sock (102674)
Apr 18 17:54:49 django gunicorn[102674]: [2022-04-18 17:54:49 +0000] [102674] [INFO] Using worker: sync
Apr 18 17:54:49 django gunicorn[102675]: [2022-04-18 17:54:49 +0000] [102675] [INFO] Booting worker with pid: 102675
Apr 18 17:54:49 django gunicorn[102676]: [2022-04-18 17:54:49 +0000] [102676] [INFO] Booting worker with pid: 102676
Apr 18 17:54:50 django gunicorn[102677]: [2022-04-18 17:54:50 +0000] [102677] [INFO] Booting worker with pid: 102677
Apr 18 17:54:50 django gunicorn[102675]: - - [18/Apr/2022:17:54:50 +0000] "GET / HTTP/1.1" 200 10697 "-" "curl/7.81.0"
Если выходные данные curl или выходные данные systemctl status указывают на то, что возникла проблема, проверьте дополнительные сведения в журналах:
- sudo journalctl -u gunicorn
Проверьте файл /etc/systemd/system/gunicorn.service на наличие проблем. Если вы вносите изменения в файл /etc/systemd/system/gunicorn.service, перезагрузите демон, чтобы перечитать определение службы, и перезапустите процесс Gunicorn, набрав:
- sudo systemctl daemon-reload
- sudo systemctl restart gunicorn
Прежде чем продолжить, убедитесь, что вы устранили указанные выше проблемы.
Настройте 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
Наконец, вам нужно открыть брандмауэр для обычного трафика через порт 80. Поскольку вам больше не нужен доступ к серверу разработки, вы также можете удалить правило для открытия порта 8000:
- sudo ufw delete allow 8000
- sudo ufw allow 'Nginx Full'
Теперь вы сможете перейти на домен или IP-адрес вашего сервера, чтобы просмотреть свое приложение.
Примечание. После настройки Nginx следующим шагом должна быть защита трафика на сервер с помощью SSL/TLS. Это важно, потому что без него вся информация, включая пароли, пересылается по сети в виде обычного текста.
Если у вас есть доменное имя, самый простой способ получить SSL-сертификат для защиты вашего трафика — использовать Let’s Encrypt. Следуйте этому руководству, чтобы настроить Let’s Encrypt с помощью Nginx в Debian 11. Следуйте процедуре, используя блок сервера Nginx, который вы создали в этом руководстве.
Устранение неполадок 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 systemd.
Если вы не можете найти файл 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 помогает создавать проекты и приложения, предоставляя множество общих частей, позволяя вам сосредоточиться на уникальных элементах. Используя общую цепочку инструментов, описанную в этой статье, вы можете обслуживать создаваемые вами приложения с одного сервера.