Поиск по сайту:

Как настроить Django с Postgres, Nginx и Gunicorn в Ubuntu 16.04

Введение

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

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

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

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

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

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

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

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

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

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

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

  1. sudo apt-get update

  2. sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx

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

  1. sudo apt-get update

  2. sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx

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

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

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

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

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

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

  1. sudo -u postgres psql

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

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

  1. CREATE DATABASE myproject;

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

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

  1. CREATE USER myprojectuser WITH PASSWORD 'password';

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

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

  1. ALTER ROLE myprojectuser SET client_encoding TO 'utf8';

  2. ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';

  3. ALTER ROLE myprojectuser SET timezone TO 'UTC';

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

  1. GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

Когда вы закончите, выйдите из командной строки PostgreSQL, набрав:

  1. \q

Создайте виртуальную среду Python для своего проекта

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

Для этого нам сначала нужен доступ к команде virtualenv. Мы можем установить это с помощью pip.

Если вы используете Python 2, обновите pip и установите пакет, набрав:

  1. sudo -H pip install --upgrade pip

  2. sudo -H pip install virtualenv

Если вы используете Python 3, обновите pip и установите пакет, набрав:

  1. sudo -H pip3 install --upgrade pip

  2. sudo -H pip3 install virtualenv

Установив virtualenv, мы можем начать формировать наш проект. Создайте и переместите в каталог, где мы можем хранить файлы нашего проекта:

  1. mkdir ~/myproject

  2. cd ~/myproject

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

  1. virtualenv myprojectenv

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

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

  1. source myprojectenv/bin/activate

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

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

Независимо от того, какую версию Python вы используете, при активации виртуальной среды следует использовать команду pip (не pip3).

  1. pip install django gunicorn psycopg2

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

Создайте и настройте новый проект Django

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

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

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

  1. django-admin.py startproject myproject ~/myproject

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

  • ~/myproject/manage.py: сценарий управления проектом Django.
  • ~/myproject/myproject/: пакет проекта Django. Он должен содержать файлы __init__.py, settings.py, urls.py и wsgi.py.
  • ~/myproject/myprojectenv/: каталог виртуальной среды, который мы создали ранее.

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

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

  1. nano ~/myproject/myproject/settings.py

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

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

. . .
# 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', . . .]

Далее найдите раздел, который настраивает доступ к базе данных. Он начнется с БАЗЫ ДАННЫХ. Конфигурация в файле предназначена для базы данных 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/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

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

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

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

  1. ~/myproject/manage.py makemigrations

  2. ~/myproject/manage.py migrate

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

  1. ~/myproject/manage.py createsuperuser

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

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

  1. ~/myproject/manage.py collectstatic

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

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

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

  1. sudo ufw allow 8000

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

  1. ~/myproject/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 проекта:

  1. cd ~/myproject

  2. gunicorn --bind 0.0.0.0:8000 myproject.wsgi

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

Примечание. К интерфейсу администратора не будут применяться никакие стили, поскольку Gunicorn не знает о статическом содержимом CSS, ответственном за это.

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

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

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

  1. deactivate

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

Создайте служебный файл Gunicorn systemd

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

Создайте и откройте служебный файл systemd для Gunicorn с правами sudo в текстовом редакторе:

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

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

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

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

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

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

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

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

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

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

[Install]
WantedBy=multi-user.target

На этом наш служебный файл systemd завершен. Сохраните и закройте его сейчас.

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

  1. sudo systemctl start gunicorn

  2. sudo systemctl enable gunicorn

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

Проверьте файл сокета Gunicorn

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

  1. sudo systemctl status gunicorn

Затем проверьте наличие файла myproject.sock в каталоге вашего проекта:

  1. ls /home/sammy/myproject



Output
manage.py  myproject  myprojectenv  myproject.sock  static

Если команда systemctl status указала, что произошла ошибка, или если вы не нашли файл myproject.sock в каталоге, это означает, что Gunicorn не смог правильно запуститься. Проверьте журналы процесса Gunicorn, набрав:

  1. sudo journalctl -u gunicorn

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

  • Файлы проекта принадлежат пользователю root, а не пользователю sudo
  • Путь WorkingDirectory в файле /etc/systemd/system/gunicorn.service не указывает на каталог проекта
  • Параметры конфигурации, указанные для процесса gunicorn в директиве ExecStart, неверны. Проверьте следующие пункты:
    • Путь к двоичному файлу gunicorn указывает на фактическое расположение двоичного файла в виртуальной среде.
    • Директива --bind определяет файл для создания в каталоге, к которому Gunicorn может получить доступ
    • myproject.wsgi:application — это точный путь к вызываемому объекту WSGI. Это означает, что когда вы находитесь в WorkingDirectory, вы должны быть в состоянии получить доступ к вызываемому названию application, заглянув в myproject. Модуль .wsgi (который преобразуется в файл с именем ./myproject/wsgi.py)

    Если вы вносите изменения в файл /etc/systemd/system/gunicorn.service, перезагрузите демон, чтобы перечитать определение службы, и перезапустите процесс Gunicorn, набрав:

    1. sudo systemctl daemon-reload

    2. sudo systemctl restart gunicorn

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

    Настройте Nginx для передачи прокси-сервера Gunicorn

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

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

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

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

    server {
    listen 80;
    server_name server_domain_or_IP;
}

    Далее мы скажем Nginx игнорировать любые проблемы с поиском фавикона. Мы также сообщим ему, где найти статические ресурсы, которые мы собрали в нашем каталоге ~/myproject/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/myproject;
    }
}

    Наконец, мы создадим блок 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/myproject;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
    }
}

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

    1. sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

    Проверьте конфигурацию Nginx на наличие синтаксических ошибок, набрав:

    1. sudo nginx -t

    Если об ошибках не сообщается, перезапустите Nginx, набрав:

    1. sudo systemctl restart nginx

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

    1. sudo ufw delete allow 8000

    2. sudo ufw allow 'Nginx Full'

    Теперь вы сможете перейти на домен или IP-адрес вашего сервера, чтобы просмотреть свое приложение.

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

    Если у вас есть доменное имя, самый простой способ получить SSL-сертификат для защиты вашего трафика — использовать Let’s Encrypt. Следуйте этому руководству, чтобы настроить Let’s Encrypt с помощью Nginx в Ubuntu 16.04.

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

    Устранение неполадок 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, набрав:

    1. sudo tail -F /var/log/nginx/error.log

    Теперь сделайте еще один запрос в своем браузере, чтобы сгенерировать новую ошибку (попробуйте обновить страницу). Вы должны увидеть новое сообщение об ошибке, записанное в журнал. Если вы посмотрите на сообщение, оно должно помочь вам сузить круг проблемы.

    Вы можете увидеть следующее сообщение:

    connect() к unix:/home/sammy/myproject/myproject.sock не удалось (2: нет такого файла или каталога)

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

    Если вы не можете найти файл myproject.sock в каталоге вашего проекта, это обычно означает, что процесс gunicorn не смог его создать. Вернитесь к разделу о проверке файла сокета Gunicorn, чтобы выполнить шаги по устранению неполадок для Gunicorn.

    connect() к unix: /home/sammy/myproject/myproject.sock не удалось (13: разрешение отклонено)

    Это указывает на то, что Nginx не удалось подключиться к сокету Gunicorn из-за проблем с разрешениями. Обычно это происходит, когда процедура выполняется с использованием пользователя root вместо пользователя sudo. Хотя процесс Gunicorn может создать файл сокета, Nginx не может получить к нему доступ.

    Это может произойти, если в любой точке между корневым каталогом (/) и файлом myproject.sock имеются ограниченные разрешения. Мы можем увидеть разрешения и значения владельца файла сокета и каждого из его родительских каталогов, передав абсолютный путь к нашему файлу сокета в команду namei:

    1. namei -nom /home/sammy/myproject/myproject.sock

    

    Output
    f: /home/sammy/myproject/myproject.sock
 drwxr-xr-x root  root     /
 drwxr-xr-x root  root     home
 drwxr-xr-x sammy sammy    sammy
 drwxrwxr-x sammy sammy    myproject
 srwxrwxrwx sammy www-data myproject.sock

    В выходных данных отображаются разрешения для каждого из компонентов каталога. Глядя на разрешения (первый столбец), владельца (второй столбец) и владельца группы (третий столбец), мы можем выяснить, какой тип доступа разрешен к файлу сокета.

    В приведенном выше примере файл сокета и каждый из каталогов, ведущих к файлу сокета, имеют всемирные разрешения на чтение и выполнение (столбец разрешений для каталогов заканчивается r-x вместо --- ). Процесс Nginx должен успешно получить доступ к сокету.

    Если какой-либо из каталогов, ведущих к сокету, не имеет разрешения на чтение и выполнение для всего мира, Nginx не сможет получить доступ к сокету, не разрешив права на чтение и выполнение для всего мира или убедившись, что право собственности на группу предоставлено группе, частью которой является Nginx. из. Для важных мест, таких как каталог /root, оба вышеуказанных параметра опасны. Файлы проекта лучше переместить за пределы каталога, где можно безопасно контролировать доступ без ущерба для безопасности.

    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 запущен, набрав:

    1. sudo systemctl status postgresql

    Если это не так, вы можете запустить его и включить автоматический запуск при загрузке (если он еще не настроен для этого), набрав:

    1. sudo systemctl start postgresql

    2. sudo systemctl enable postgresql

    Если у вас по-прежнему возникают проблемы, убедитесь, что параметры базы данных, определенные в файле ~/myproject/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

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

    Если вы обновите свое приложение Django, вы можете перезапустить процесс Gunicorn, чтобы применить изменения, набрав:

    1. sudo systemctl restart gunicorn

    Если вы изменили системный файл службы gunicorn, перезагрузите демон и перезапустите процесс, набрав:

    1. sudo systemctl daemon-reload

    2. sudo systemctl restart gunicorn

    Если вы измените конфигурацию блока сервера Nginx, проверьте конфигурацию, а затем Nginx, набрав:

    1. sudo nginx -t && sudo systemctl restart nginx

    Эти команды полезны для получения изменений при настройке конфигурации.

    Заключение

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

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