TOC

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

Вступление

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

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

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

Для выполнения этого руководства у вас должен быть свежий экземпляр сервера Ubuntu 18.04 с базовым брандмауэром и пользователем без полномочий root с настроенными привилегиямиsudo. Вы можете узнать, как это настроить, пройдя через нашinitial server setup guide.

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

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

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

Установка пакетов из репозиториев Ubuntu

Чтобы начать процесс, мы загрузим и установим все нужные нам элементы из репозиториев Ubuntu. Мы будем использовать менеджер пакетов Pythonpip для установки дополнительных компонентов чуть позже.

Нам нужно обновить локальный индекс пакета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.

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

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

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

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

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

sudo -u postgres psql

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

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

CREATE DATABASE myproject;

[.note] #Note: Каждый оператор Postgres должен заканчиваться точкой с запятой, поэтому убедитесь, что ваша команда заканчивается точкой, если у вас возникли проблемы.
#

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

CREATE USER myprojectuser WITH PASSWORD 'password';

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

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

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 в виртуальной среде для упрощения управления.

Для этого нам сначала нужен доступ к команде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 ~/myprojectdir
cd ~/myprojectdir

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

virtualenv myprojectenv

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

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

source myprojectenv/bin/activate

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

Активировав виртуальную среду, установите Django, Gunicorn и адаптер PostgreSQLpsycopg2 с локальным экземпляромpip:

[.note] #Note: Когда виртуальная среда активирована (когда перед приглашением стоит(myprojectenv)), используйтеpip вместоpip3, даже если вы используете Python 3. Копия инструмента в виртуальной среде всегда называетсяpip, независимо от версии Python.
# 

pip install django gunicorn psycopg2-binary

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

Создание и настройка нового проекта 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 ~/myprojectdir/myproject/settings.py

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

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

[.note] #Note: Не забудьте включитьlocalhost как одну из опций, так как мы будем проксировать соединения через локальный экземпляр Nginx.
#

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

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

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

~/myprojectdir/myproject/settings.py

. . .

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

. . .

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

~/myprojectdir/myproject/settings.py

. . .

STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

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

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

Теперь мы можем перенести исходную схему базы данных в нашу базу данных 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:

Django index page

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

Django admin login

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

Django admin interface

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

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

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

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

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

[.note] #Note: В интерфейсе администратора не будет применен какой-либо стиль, поскольку Gunicorn не знает, как найти статический CSS-контент, ответственный за это.
#

Мы передали Gunicorn модуль, указав относительный путь к каталогу файлаwsgi.py Django, который является точкой входа в наше приложение, используя синтаксис модуля Python. Внутри этого файла определена функцияapplication, которая используется для связи с приложением. Чтобы узнать больше о спецификации WSGI, щелкнитеhere.

Когда вы закончите тестирование, нажмите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], чтобы убедиться, что сокет создан в нужное время:

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

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

/etc/systemd/system/gunicorn.service

[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

Затем проверьте наличие файла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)

Чтобы протестировать механизм активации сокета, мы можем отправить соединение с сокетом через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 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

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

Настроить Nginx на Proxy Pass для Gunicorn

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

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

sudo nano /etc/nginx/sites-available/myproject

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

/etc/nginx/sites-available/myproject

server {
    listen 80;
    server_name server_domain_or_IP;
}

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

/etc/nginx/sites-available/myproject

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:

/etc/nginx/sites-available/myproject

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-адресу вашего сервера, чтобы просмотреть свое приложение.

[.Примечание]##

Note: После настройки Nginx следующим шагом должна быть защита трафика на сервер с помощью SSL / TLS. Это важно, потому что без него вся информация, включая пароли, отправляется по сети в виде простого текста.

Если у вас есть доменное имя, самый простой способ получить SSL-сертификат для защиты вашего трафика - это использовать Let Encrypt. Следуйтеthis guide, чтобы настроить Let's Encrypt с Nginx в Ubuntu 18.04. Выполните процедуру, используя блок сервера Nginx, который мы создали в этом руководстве.

Если у вас нет доменного имени, вы все равно можете защитить свой сайт для тестирования и обучения с помощьюself-signed SSL certificate. Опять же, следуйте процессу, используя серверный блок Nginx, который мы создали в этом руководстве.

Устранение неисправностей Nginx и Gunicorn

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

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

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

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

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

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, созданного модулем systemdgunicorn.socket.

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