TOC

Как настроить Django с помощью Postgres, Nginx и Gunicorn в Debian 9

Вступление

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

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

Предпосылки

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

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

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

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

Шаг 1 - Установка пакетов из репозитариев Debian

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

Нам нужно обновить локальный индекс пакетов + apt +, а затем загрузить и установить пакеты. Пакеты, которые мы устанавливаем, зависят от того, какую версию Python будет использовать ваш проект.

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

sudo apt update
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 update
sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

Это установит + pip +, файлы для разработки на Python, необходимые для сборки Gunicorn, систему баз данных Postgres и библиотеки, необходимые для взаимодействия с ней, а также веб-сервер Nginx.

Шаг 2 - Создание базы данных PostgreSQL и пользователя

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

По умолчанию Postgres использует схему аутентификации, называемую «равноправная аутентификация» для локальных соединений. По сути, это означает, что если имя пользователя операционной системы пользователя совпадает с действительным именем пользователя Postgres, этот пользователь может войти в систему без дальнейшей аутентификации.

Во время установки Postgres был создан пользователь операционной системы с именем + postgres +, соответствующий администратору + postgres + PostgreSQL. Нам нужно использовать этого пользователя для выполнения административных задач. Мы можем использовать sudo и передать имя пользователя с опцией + -u +.

Войдите в интерактивную сессию Postgres, набрав:

sudo -u postgres psql

Вам будет выдан запрос PostgreSQL, где мы сможем настроить наши требования.

Сначала создайте базу данных для вашего проекта:

CREATE DATABASE ;

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

CREATE USER  WITH PASSWORD '';

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

Мы устанавливаем кодировку по умолчанию на + UTF-8 +, что ожидает Django. Мы также устанавливаем схему изоляции транзакции по умолчанию «read commit», которая блокирует чтение из незафиксированных транзакций. Наконец, мы устанавливаем часовой пояс. По умолчанию наши проекты Django будут настроены на использование + UTC. Это все рекомендации из the самого проекта Django:

ALTER ROLE  SET client_encoding TO 'utf8';
ALTER ROLE  SET default_transaction_isolation TO 'read committed';
ALTER ROLE  SET timezone TO 'UTC';

Теперь мы можем предоставить нашему новому пользователю доступ для управления нашей новой базой данных:

GRANT ALL PRIVILEGES ON DATABASE  TO ;

Когда вы закончите, выйдите из приглашения PostgreSQL, набрав:

\q

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

Шаг 3 - Создание виртуальной среды Python для вашего проекта

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

Для этого нам сначала нужен доступ к команде + 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 + мы можем приступить к формированию нашего проекта. Создайте и перейдите в каталог, где мы можем хранить файлы нашего проекта:

mkdir ~/
cd ~/

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

virtualenv

Это создаст каталог с именем ` в вашем каталоге `. Внутри он установит локальную версию Python и локальную версию + pip +. Мы можем использовать это для установки и настройки изолированной среды Python для нашего проекта.

Перед установкой требований Python для нашего проекта нам необходимо активировать виртуальную среду. Вы можете сделать это, набрав:

source /bin/activate

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

Когда ваша виртуальная среда активна, установите Django, Gunicorn и адаптер + psycopg2 + PostgreSQL с локальным экземпляром + pip +:

pip install django gunicorn psycopg2-binary

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

Шаг 4 - Создание и настройка нового проекта Django

С нашими установленными компонентами Python мы можем создавать фактические файлы проекта Django.

Создание проекта Джанго

Поскольку у нас уже есть каталог проекта, мы скажем Django установить файлы здесь. Он создаст каталог второго уровня с реальным кодом, который является нормальным, и поместит сценарий управления в этот каталог. Ключом к этому является то, что мы определяем каталог явно, а не позволяем Django принимать решения относительно нашего текущего каталога:

django-admin.py startproject  ~/

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

  • + ~ / myprojectdir / manage.py +: сценарий управления проектом Django.

  • + ~ / myprojectdir / myproject / +: пакет проекта Django. Он должен содержать файлы + init . Py +, + settings.py +, + urls.py + и + wsgi.py +.

  • + ~ / myprojectdir / myprojectenv / +: каталог виртуальной среды, который мы создали ранее.

Настройка параметров проекта

Первое, что мы должны сделать с нашими недавно созданными файлами проекта, это настроить параметры. Откройте файл настроек в вашем текстовом редакторе:

nano ~///settings.py

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

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

~ / Myprojectdir / 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 = ['', '', , 'localhost']

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

Измените настройки с помощью вашей базы данных PostgreSQL. Мы говорим Django использовать адаптер + psycopg2 +, который мы установили с помощью + pip +. Нам нужно дать имя базы данных, имя пользователя базы данных, пароль пользователя базы данных, а затем указать, что база данных находится на локальном компьютере. Вы можете оставить настройку + PORT + пустой строкой:

~ / Myprojectdir / MyProject / settings.py

. . .

DATABASES = {
   'default': {
       'ENGINE': 'django.db.backends.',
       'NAME': '',
       'USER': '',
       'PASSWORD': '',
       'HOST': 'localhost',
       'PORT': '',
   }
}

. . .

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

~ / Myprojectdir / MyProject / settings.py

. . .

STATIC_URL = '/static/'

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

Завершение начальной настройки проекта

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

~//manage.py makemigrations
~//manage.py migrate

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

~//manage.py createsuperuser

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

Мы можем собрать весь статический контент в каталог, который мы настроили, набрав:

~//manage.py collectstatic

Вам нужно будет подтвердить операцию. Затем статические файлы будут помещены в каталог с именем + static + в каталоге вашего проекта.

Если вы следовали руководству по первоначальной настройке сервера, у вас должен быть брандмауэр UFW, защищающий ваш сервер. Чтобы протестировать сервер разработки, нам нужно разрешить доступ к порту, который мы будем использовать.

Создайте исключение для порта 8000, набрав:

sudo ufw allow 8000

Наконец, вы можете протестировать наш проект, запустив сервер разработки Django с помощью этой команды:

~//manage.py runserver 0.0.0.0:8000

В веб-браузере перейдите к доменному имени или IP-адресу вашего сервера, за которым следует +: 8000 +:

http://:8000

Вы должны увидеть страницу индекса по умолчанию Django:

изображение: https: //assets.digitalocean.com/articles/django_gunicorn_nginx_1804/django_index.png [страница индекса Django]

Если вы добавите + / admin + в конец URL-адреса в адресной строке, вам будет предложено ввести имя пользователя и пароль администратора, которые вы создали с помощью команды + createuperuser:

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

После аутентификации вы можете получить доступ к стандартному интерфейсу администратора Django:

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

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

Тестирование способности Gunicorn служить проекту

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

cd ~/
gunicorn --bind 0.0.0.0:8000 .wsgi

Это запустит Gunicorn на том же интерфейсе, на котором работал сервер разработки Django. Вы можете вернуться и снова протестировать приложение.

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

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

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

deactivate

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

Шаг 5 - Создание системных сокетов и служебных файлов для Gunicorn

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

Сокет Gunicorn будет создан при загрузке и будет прослушивать соединения. Когда происходит соединение, systemd автоматически запускает процесс Gunicorn для обработки соединения.

Начните с создания и открытия файла сокета systemd для Gunicorn с привилегиями + sudo +:

sudo nano /etc/systemd/system/gunicorn.socket

Внутри мы создадим раздел + [Unit] + для описания сокета, раздел + [Socket] + для определения местоположения сокета и раздел + [Install] +, чтобы убедиться, что сокет создано в нужное время:

/etc/systemd/system/gunicorn.socket

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

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

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

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

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

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

Далее мы откроем раздел + [Service] +. Мы определим пользователя и группу, под которой мы хотим работать. Мы дадим право нашей учетной записи обычного пользователя на процесс, поскольку он владеет всеми соответствующими файлами. Мы передадим групповое владение группе + www-data, чтобы Nginx мог легко общаться с Gunicorn.

Затем мы наметим рабочий каталог и укажем команду для запуска сервиса. В этом случае нам нужно будет указать полный путь к исполняемому файлу Gunicorn, который устанавливается в нашей виртуальной среде. Мы свяжем процесс с сокетом Unix, который мы создали в каталоге + / run +, чтобы процесс мог взаимодействовать с Nginx. Мы записываем все данные в стандартный вывод, чтобы процесс + journald + мог собирать журналы Gunicorn. Мы также можем указать любые дополнительные настройки Gunicorn здесь. Например, мы указали 3 рабочих процесса в этом случае:

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=
Group=www-data
WorkingDirectory=/home//
ExecStart=/home////bin/gunicorn \
         --access-logfile - \
         --workers 3 \
         --bind unix:/run/gunicorn.sock \
         .wsgi:application

Наконец, мы добавим раздел + [Install] +. Это скажет systemd, с чем связать этот сервис, если мы включим его при загрузке. Мы хотим, чтобы эта служба запускалась, когда обычная многопользовательская система запущена и работает:

/etc/systemd/system/gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=
Group=www-data
WorkingDirectory=/home//
ExecStart=/home////bin/gunicorn \
         --access-logfile - \
         --workers 3 \
         --bind unix:/run/gunicorn.sock \
         .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

Мы можем подтвердить, что операция прошла успешно, проверив наличие файла сокета.

Шаг 6 - Проверка файла сокета Gunicorn

Проверьте состояние процесса, чтобы узнать, удалось ли запустить его:

sudo systemctl status 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 +.

Шаг 7 - Проверка активации сокета

В настоящее время, если вы только запустили модуль + gunicorn.socket, то` + gunicorn.service ie` еще не будет активен, поскольку сокет еще не получил никаких подключений. Вы можете проверить это, набрав:

sudo systemctl status gunicorn
Output● gunicorn.service - gunicorn daemon
  Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)

Чтобы проверить механизм активации сокета, мы можем отправить соединение к сокету через + 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)
   since Mon 2018-07-09 20:00:40 UTC; 4s ago
Main PID: 1157 (gunicorn)
   Tasks: 4 (limit: 1153)
  CGroup: /system.slice/gunicorn.service
          ├─1157 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
          ├─1178 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
          ├─1180 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application
          └─1181 /home/sammy/myprojectdir/myprojectenv/bin/python3 /home/sammy/myprojectdir/myprojectenv/bin/gunicorn --access-logfile - --workers 3 --bind unix:/run/gunicorn.sock myproject.wsgi:application

Jul 09 20:00:40 django1 systemd[1]: Started gunicorn daemon.
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Starting gunicorn 19.9.0
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Listening at: unix:/run/gunicorn.sock (1157)
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1157] [INFO] Using worker: sync
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1178] [INFO] Booting worker with pid: 1178
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1180] [INFO] Booting worker with pid: 1180
Jul 09 20:00:40 django1 gunicorn[1157]: [2018-07-09 20:00:40 +0000] [1181] [INFO] Booting worker with pid: 1181
Jul 09 20:00:41 django1 gunicorn[1157]:  - - [09/Jul/2018:20:00:41 +0000] "GET / HTTP/1.1" 200 16348 "-" "curl/7.58.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

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

Шаг 8 - Настройте Nginx на Proxy Pass для Gunicorn

Теперь, когда Gunicorn настроен, нам нужно настроить Nginx для передачи трафика процессу.

Начните с создания и открытия нового блока сервера в каталоге + sites-available + в Nginx:

sudo nano /etc/nginx/sites-available/

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

/ И т.д. / Nginx / сайты Недоступные / MyProject

server {
   listen 80;
   server_name ;
}

Далее мы скажем Nginx игнорировать любые проблемы с поиском значка. Мы также сообщим ему, где найти статические ресурсы, которые мы собрали в нашем каталоге + ~ // static +. Все эти файлы имеют стандартный префикс URI «/ static», поэтому мы можем создать блок местоположения, соответствующий этим запросам:

/ И т.д. / Nginx / сайты Недоступные / MyProject

server {
   listen 80;
   server_name ;

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

Наконец, мы создадим блок + location / {} + для соответствия всем остальным запросам. Внутри этого места мы включим стандартный файл + proxy_params +, включенный в установку Nginx, а затем передадим трафик непосредственно в сокет Gunicorn:

/ И т.д. / Nginx / сайты Недоступные / MyProject

server {
   listen 80;
   server_name ;

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

   location / {
       include proxy_params;
       proxy_pass http://unix:/run/gunicorn.sock;
   }
}

Сохраните и закройте файл, когда вы закончите. Теперь мы можем включить файл, связав его с каталогом + sites-enabled +:

sudo ln -s /etc/nginx/sites-available/ /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 и Gunicorn

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

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/gunicorn.sock не удалось (2: нет такого файла или каталога) *

Это указывает на то, что Nginx не смог найти файл + gunicorn.sock + в указанном месте. Вы должны сравнить расположение + proxy_pass +, определенное в файле + / etc / nginx / sites-available / myproject +, с фактическим местоположением файла + gunicorn.sock +, сгенерированного модулем + gunicorn.socket + systemd.

Если вы не можете найти файл + gunicorn.sock + в каталоге + / run +, это обычно означает, что файл сокета systemd не смог его создать. Вернитесь по ссылке: # checking for the gunicorn-socket-file [раздел о проверке файла сокета 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 Is Displaying: «Не удалось подключиться к серверу: соединение отказано»

Одно сообщение, которое вы можете увидеть от 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 упрощает создание проектов и приложений, предоставляя множество общих частей, позволяя вам сосредоточиться на уникальных элементах. Используя общую цепочку инструментов, описанную в этой статье, вы можете легко обслуживать созданные вами приложения с одного сервера.

Related