One place for hosting & domains

      Postgres

      Настройка Django с Postgres, Nginx и Gunicorn в Ubuntu 18.04


      Введение

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

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

      Предварительные требования и цели

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

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

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

      Давайте приступим.

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

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

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

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

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

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

      Выполните вход в интерактивный сеанс Postgres, введя следующую команду:

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

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

      • CREATE DATABASE myproject;

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

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

      • CREATE USER myprojectuser WITH PASSWORD 'password';

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

      Мы зададим кодировку по умолчанию UTF-8, чего и ожидает Django. Также мы зададим схему изоляции транзакций по умолчанию «read committed», которая будет блокировать чтение со стороны неподтвержденных транзакций. В заключение мы зададим часовой пояс. По умолчанию наши проекты Django настроены на использование времени по Гринвичу (UTC). Все эти рекомендации взяты из проекта Django:

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

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

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Завершив настройку, закройте диалог PostgreSQL с помощью следующей команды:

      Теперь настройка 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 с помощью следующей команды:

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

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

      • source myprojectenv/bin/activate

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

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

      Примечание. Если виртуальная среда активна (когда перед командной строкой стоит (myprojectenv)), необходимо использовать pip вместо pip3, даже если вы используете Python 3. Копия инструмента в виртуальной среде всегда имеет имя pip вне зависимости от версии Python.

      • pip install django gunicorn psycopg2-binary

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

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

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

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

      Примечание. Обязательно используйте 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 с помощью следующей команды:

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

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      Откройте в браузере доменное имя или IP-адрес вашего сервера с суффиксом :8000:

      http://server_domain_or_IP:8000
      

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

      Страница индекса Django

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

      Вход в панель администратора Django

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

      Интерфейс администрирования Django

      Завершив изучение, нажмите CTRL+C в окне терминала, чтобы завершить работу сервера разработки.

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

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

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

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

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

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

      После завершения тестирования нажмите CTRL+C в окне терминала, чтобы остановить работу Gunicorn.

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

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

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

      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 как прокси для Gunicorn

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

      Для начала нужно создать и открыть новый серверный блок в каталоге Nginx sites-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 игнорировать любые проблемы при поиске favicon. Также мы укажем, где можно найти статичные ресурсы, собранные нами в каталоге ~/myprojectdir/static. Все эти строки имеют стандартный префикс URI «/static», так что мы можем создать блок location для соответствия этим запросам:

      /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 на ошибки синтаксиса:

      Если ошибок не будет найдено, перезапустите Nginx с помощью следующей команды:

      • sudo systemctl restart nginx

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

      • sudo ufw delete allow 8000
      • sudo ufw allow 'Nginx Full'

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

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

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

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

      Диагностика и устранение неисправностей Nginx и Gunicorn

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

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

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

      Nginx использует server_name, чтобы определять, какой серверный блок использовать для ответа на запросы. Если вы увидите страницу Nginx по умолчанию, это будет означать, что Nginx не может найти явное соответствие запросу в серверном блоке и выводит блок по умолчанию, заданный в /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() to unix:/run/gunicorn.sock failed (2: No such file or directory)

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

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

      connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

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

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

      • namei -l /run/gunicorn.sock

      Output

      f: /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 выводит ошибку: «could not connect to server: Connection refused»

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



      Source link

      How To Set Up Django with Postgres, Nginx, and Gunicorn on Ubuntu 18.04


      Introdução

      O Django é um framework Web poderoso, que pode ajudar o seu aplicativo Python ou site a decolar. O Django inclui um servidor de desenvolvimento simplificado para testar seu código localmente, mas para qualquer coisa ligeiramente relacionada com produção, é necessário um servidor Web mais seguro e poderoso.

      Neste guia, vamos demonstrar como instalar e configurar alguns componentes no Ubuntu 18.04 para apoiar e servir aplicativos do Django. Vamos configurar um banco de dados PostgreSQL ao invés de usar o banco de dados padrão SQLite. Vamos configurar o servidor do aplicativo Gunicorn para interagir com nossos aplicativos. Então, vamos configurar o Nginx como proxy reverso do Gunicorn, dando-nos acesso aos seus recursos de segurança e desempenho para servir nossos aplicativos.

      Pré-requisitos e objetivos

      Para completar este guia, você deve ter uma nova instância de servidor Ubuntu 18.04 com um firewall básico e um usuário não raiz com privilégios sudo configurados. Você pode aprender como configurar isso examinando nosso guia de configuração inicial do servidor.

      Vamos instalar o Django em um ambiente virtual. Instalar o Django em um ambiente específico do seu projeto permitirá que seus projetos e seus requisitos sejam tratados separadamente.

      Assim que tivermos nosso banco de dados e aplicativo funcionando, vamos instalar e configurar o servidor do aplicativo Gunicorn. Isso servirá como uma interface para nosso aplicativo, traduzindo os pedidos do cliente de HTTP para chamadas Python que nosso aplicativo consegue processar. Então, vamos configurar o Nginx na frente do Gunicorn para aproveitar seus mecanismos de gerenciamento de conexão de alta performance e seus recursos de segurança fáceis de implementar.

      Vamos começar.

      Instalando os pacotes dos repositórios do Ubuntu

      Para começar o processo, vamos baixar e instalar todos os itens que precisamos dos repositórios do Ubuntu. Vamos usar o gerenciador de pacotes Python pip para instalar componentes adicionais um pouco mais tarde.

      Precisamos atualizar o índice de pacotes local apt e, em seguida, baixar e instalar os pacotes. Os pacotes que instalamos dependem da versão do Python que seu projeto usará.

      Se estiver usando o Django com o Python 3, digite:

      • sudo apt update
      • sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

      O Django 1.11 é a última versão do Django que suportará o Python 2. Se você estiver começando novos projetos, é altamente recomendado que escolha o Python 3. Se ainda for necessário usar o Python 2, digite:

      • sudo apt update
      • sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

      Isso instalará o pip, os arquivos de desenvolvimento do Python necessários para criar o Gunicorn mais tarde, o sistema de banco de dados Postgres e as bibliotecas necessárias para interagir com ele, e o servidor Web Nginx.

      Criando o banco de dados e o usuário PostgreSQL

      Vamos ir direto e criar um banco de dados e um usuário do banco de dados para nosso aplicativo Django.

      Por padrão, o Postgres usa um esquema de autenticação chamado de “autenticação por peer” para conexões locais. Basicamente, isso significa que se o nome de usuário do sistema operacional do usuário corresponder a um nome de usuário do Postgres válido, o usuário pode logar-se sem autenticação adicional.

      Durante a instalação do Postgres, um usuário do sistema operacional chamado postgres foi criado para corresponder ao usuário administrativo postgres do PostgreSQL. Precisamos usar este usuário para realizar tarefas administrativas. Podemos usar o sudo e passar o nome de usuário com a opção -u.

      Logue-se em uma sessão interativa do Postgres digitando:

      Você receberá um prompt do PostgreSQL onde podemos configurar nossos requisitos.

      Primeiramente, crie um banco de dados para seu projeto:

      • CREATE DATABASE myproject;

      Nota: Cada declaração do Postgres deve terminar com um ponto e vírgula, para garantir que seu comando termine com um, caso esteja passando por problemas.

      Em seguida, crie um usuário do banco de dados para nosso projeto. Certifique-se de selecionar uma senha segura:

      • CREATE USER myprojectuser WITH PASSWORD 'password';

      Depois disso, vamos modificar alguns dos parâmetros de conexão para o usuário que acabamos de criar. Isso irá acelerar as operações do banco de dados para que os valores corretos não tenham que ser consultados e definidos cada vez que uma conexão for estabelecida.

      Estamos definindo a codificação padrão para UTF-8, que é a que o Django espera. Também estamos definindo o esquema padrão de isolamento de transação para “ler confirmados”, que bloqueia a leitura de transações não confirmadas. Por fim, vamos definir o fuso horário. Por padrão, nossos projetos Django serão configurados para usar o UTC. Essas são todas recomendações do projeto Django em si:

      • 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';

      Agora, podemos dar ao nosso novo usuário acesso para administrar nosso novo banco de dados:

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Quando tiver terminado, saia do prompt do PostgreSQL digitando:

      O Postgres agora está configurado para que o Django possa se conectar ao seu banco de dados e gerenciar suas informações.

      Criando um Ambiente Virtual Python para seu Projeto

      Agora que temos nosso banco de dados, podemos começar a preparar o resto dos nossos requisitos do projeto. Vamos instalar nossos requisitos do Python em um ambiente virtual para fácil gerenciamento.

      Para isso, precisamos primeiro acessar o comando virtualenv. Podemos instalar isso com o pip.

      Se estiver usando o Python 3, atualize o pip e instale o pacote digitando:

      • sudo -H pip3 install --upgrade pip
      • sudo -H pip3 install virtualenv

      Se estiver usando o Python 2, atualize o pip e instale o pacote digitando:

      • sudo -H pip install --upgrade pip
      • sudo -H pip install virtualenv

      Com o virtualenv instalado, podemos começar a formar nosso projeto. Crie um diretório onde possamos manter nossos arquivos do projeto e vá até ele:

      • mkdir ~/myprojectdir
      • cd ~/myprojectdir

      Dentro do diretório do projeto, crie um ambiente virtual do Python digitando:

      Isso criará um diretório chamado myprojectenv dentro do seu diretório myprojectdir. Lá dentro, ele instalará uma versão local do Python e uma versão local do pip. Podemos usar isso para instalar e configurar um ambiente Python isolado para nosso projeto.

      Antes de instalarmos os requisitos Python do nosso projeto, precisamos ativar o ambiente virtual. Você pode fazer isso digitando:

      • source myprojectenv/bin/activate

      Seu prompt deverá mudar para indicar que você agora está operando em um ambiente virtual Python. Eles se parecerão com isso: (myprojectenv)user@host:~/myprojectdir$.

      Com seu ambiente virtual ativo, instale o Django, Gunicorn, e o adaptador do PostgreSQL psycopg2 com a instância local do pip:

      Nota: Quando o ambiente virtual for ativado (quando seu prompt tiver (myprojectenv) antecedendo ele) use o pip ao invés do pip3, mesmo se estiver usando o Python 3. A cópia da ferramenta do ambiente virtual é sempre chamada de pip, independente da versão Python.

      • pip install django gunicorn psycopg2-binary

      Agora, você deve ter todos os softwares necessários para iniciar um projeto Django.

      Criando e Configurando um Projeto Django Novo

      Com nossos componentes Python instalados, podemos criar os arquivos do projeto Django em si.

      Criando o Projeto Django

      Como já temos um diretório de projeto, vamos dizer ao Django para instalar os arquivos aqui. Ele criará um diretório de segundo nível com o código real, o que é normal, e colocará um script de gerenciamento neste diretório. A chave para isso é que estamos definindo o diretório explicitamente ao invés de permitir que o Django tome decisões sobre nosso diretório atual:

      • django-admin.py startproject myproject ~/myprojectdir

      Neste ponto, seu diretório de projeto (~/myprojectdir no nosso caso) deve ter o seguinte conteúdo:

      • ~/myprojectdir/manage.py: um script de gerenciamento de projeto Django.
      • ~/myprojectdir/myproject/: o pacote do projeto Django. Isso deve conter os arquivos __init__.py, settings.py, urls.py e wsgi.py.
      • ~/myprojectdir/myprojectenv/: o diretório do ambiente virtual que criamos anteriormente.

      Ajustando as configurações do Projeto

      A primeira coisa que devemos fazer com nossos arquivos de projeto recém-criados é ajustar as configurações. Abra as configurações no seu editor de texto:

      • nano ~/myprojectdir/myproject/settings.py

      Comece locando a diretriz ALLOWED_HOSTS. Isso define uma lista dos endereços ou nomes de domínio do servidor que podem ser usados para se conectar à instância Django. Qualquer pedido recebido com um cabeçalho Host que não está nesta lista irá criar uma exceção. O Django exige que você defina isso para prevenir uma certa classe de vulnerabilidade de segurança.

      Dentro dos colchetes, liste os endereços IP ou nomes de domínio associados ao seu servidor do Django. Cada item deve ser listado entre aspas, com entradas separadas divididas por uma vírgula. Se você quiser pedidos para um domínio inteiro e quaisquer subdomínios, anteceda um período ao início da entrada. No trecho abaixo, há alguns exemplos comentados usados como demonstração:

      Nota: Certifique-se de incluir o localhost como uma das opções, uma vez que vamos estar passando conexões por um proxy através de uma instância local do 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']
      

      Em seguida, encontre a seção que configura o acesso ao banco de dados. Ela começará com DATABASES. A configuração no arquivo é para um banco de dados SQLite. Já criamos um banco de dados PostgreSQL para nosso projeto, então precisamos ajustar as configurações.

      Altere as configurações com as informações do seu banco de dados PostgreSQL. Diremos ao Django para usar o adaptador psycopg2 que instalamos com o pip. Precisamos fornecer o nome do banco de dados, o nome de usuário do banco de dados, a senha do usuário do banco de dados, e então especificar que o banco de dados está localizado no computador local. Você pode deixar a configuração PORT como uma string vazia:

      ~/myprojectdir/myproject/settings.py

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

      Em seguida, vá até o final do arquivo e adicione uma configuração indicando onde os arquivos estáticos devem ser colocados. Isso é necessário para que o Nginx possa lidar com pedidos para esses itens. A seguinte linha diz ao Django para colocá-los em um diretório chamado static no diretório base do projeto:

      ~/myprojectdir/myproject/settings.py

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

      Salve e feche o arquivo quando você terminar.

      Completando a Configuração Inicial do Projeto

      Agora, podemos migrar o esquema inicial do banco de dados para nosso banco de dados PostgreSQL usando o script de gerenciamento:

      • ~/myprojectdir/manage.py makemigrations
      • ~/myprojectdir/manage.py migrate

      Crie um usuário administrativo para o projeto digitando:

      • ~/myprojectdir/manage.py createsuperuser

      Você terá que selecionar um nome de usuário, fornecer um endereço e-mail, e escolher uma senha e confirmá-la.

      Podemos coletar todos o conteúdo estático no local do diretório que configuramos digitando:

      • ~/myprojectdir/manage.py collectstatic

      Você terá que confirmar a operação. Os arquivos estáticos serão então colocados em um diretório chamado static dentro do seu diretório.

      Se seguiu o guia de configuração inicial do servidor, você deve ter um firewall UFW protegendo seu servidor. Para testar o servidor de desenvolvimento, vamos ter que permitir o acesso à porta que iremos usar.

      Crie uma exceção para a porta 8000 digitando:

      Finalmente, você pode testar nosso projeto iniciando o servidor de desenvolvimento Django com este comando:

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      No seu navegador Web, visite o nome de domínio ou endereço IP do seu servidor seguido de :8000:

      http://server_domain_or_IP:8000
      

      Você deve ver a página inicial padrão do Django:

      Django index page

      Se adicionar /admin no final do URL na barra de endereço, você será solicitado a colocar o nome de usuário administrativo e a senha que criou com o comando createsuperuser:

      Django admin login

      Após a autenticação, você pode acessar a interface de admin do Django padrão:

      Django admin interface

      Quando você terminar de explorar, clique em CTRL-C na janela do terminal para fechar o servidor de desenvolvimento.

      Testando a capacidade do Gunicorn para servir o projeto

      A última coisa que queremos fazer antes de deixar nosso ambiente virtual é testar o Gunicorn para garantir que ele possa servir o aplicativo. Podemos fazer isso entrando no nosso diretório de projeto e usando o gunicorn para carregar o módulo WSGI do projeto:

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

      Isso irá iniciar o Gunicorn na mesma interface em que o servidor de desenvolvimento do Django estava sendo executado. Você pode voltar e testar o aplicativo novamente.

      Nota: A interface admin não terá qualquer um dos estilos aplicados, uma vez que o Gunicorn não sabe como encontrar o conteúdo CSS estático responsável por isso.

      Passamos um módulo ao Gunicorn especificando o caminho de diretório relativo para o arquivo wsgi.py do Django, que é o ponto de entrada para nosso aplicativo, usando a sintaxe do módulo do Python. Dentro deste arquivo, é definida uma função chamada de application, que é usada para se comunicar com o aplicativo. Para aprender mais sobre a especificação WSGI, clique aqui.

      Quando terminar os testes, clique em CTRL-C na janela do terminal para interromper o Gunicorn.

      Agora, acabamos de configurar nosso aplicativo Django. Podemos sair do nosso ambiente virtual digitando:

      O indicador do ambiente virtual no seu prompt será removido.

      Criando arquivos de socket e de serviço systemd para o Gunicorn

      Nós testamos que o Gunicorn pode interagir com nosso aplicativo Django, mas devemos implementar uma maneira mais robusta de começar e parar o servidor do aplicativo. Para isso, vamos fazer arquivos de serviço e de socket do systemd.

      O socket Gunicorn será criado no boot e escutará as conexões. Quando ocorrer uma conexão, o systemd irá iniciar o processo Gunicorn automaticamente para lidar com a conexão.

      Comece criando e abrindo um arquivo de socket do systemd para o Gunicorn com privilégios sudo:

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

      Dentro, vamos criar uma seção [Unit] para descrever o socket, uma seção [Socket] para definir a localização do socket e uma seção [Install] para garantir que o socket seja criado no momento certo:

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Salve e feche o arquivo quando você terminar.

      Em seguida, crie e abra um arquivo de serviço do systemd para o Gunicorn com privilégios sudo no seu editor de texto. O nome do arquivo de serviço deve corresponder ao nome do arquivo do socket com exceção da extensão:

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

      Comece com a seção [Unit], que é usada para especificar os metadados e dependências. Vamos colocar uma descrição do nosso serviço aqui e dizer ao sistema init para iniciar isso somente após o objetivo da rede ter sido alcançado. Uma vez que nosso serviço se baseia no socket do arquivo do socket, precisamos incluir uma diretriz Requires para indicar essa relação:

      /etc/systemd/system/gunicorn.service

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

      Em seguida, vamos abrir a seção [Service]. Nós especificaremos o usuário e o grupo em que queremos que o processo seja executado. Vamos dar à nossa conta de usuário regular a posse do processo uma vez que ela possui todos os arquivos relevantes. Vamos atribuir a posse do grupo ao grupo www-data para que o Nginx possa se comunicar facilmente com o Gunicorn.

      Então, vamos mapear o diretório em funcionamento e especificar o comando a ser usado para iniciar o serviço. Neste caso, precisaremos especificar o caminho completo para o executável do Gunicorn, que está instalado dentro do nosso ambiente virtual. Vamos ligar o processo ao socket Unix que criamos dentro do diretório /run para que o processo possa se comunicar com o Nginx. Nós registramos todos os dados na saída padrão para que o processo journald possa recolher os registros do Gunicorn. Também podemos especificar quaisquer ajustes opcionais no Gunicorn aqui. Por exemplo, especificamos 3 processos de trabalho neste caso:

      /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
      

      Finalmente, adicionaremos uma seção [Install]. Isso dirá ao systemd o que ligar a este serviço se nós habilitarmos que ele seja iniciado no boot. Queremos que este serviço comece quando o sistema regular de vários usuários estiver funcionando:

      /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
      

      Com isso, nosso arquivo de serviço systemd está completo. Salve e feche-o agora.

      Agora, podemos iniciar e habilitar o socket do Gunicorn. Isso criará o arquivo do socket em /run/gunicorn.sock agora e no boot. Quando uma conexão for feita no socket, o systemd irá iniciar o gunicorn.service automaticamente para lidar com ela:

      • sudo systemctl start gunicorn.socket
      • sudo systemctl enable gunicorn.socket

      Podemos confirmar que a operação foi bem sucedida verificando o arquivo do socket.

      Verificando o arquivo de socket do Gunicorn

      Verifique o status do processo para descobrir se ele foi capaz de iniciar:

      • sudo systemctl status gunicorn.socket

      Em seguida, verifique a existência do arquivo gunicorn.sock dentro do diretório /run:

      Output

      /run/gunicorn.sock: socket

      Se o comando systemctl status indicou que um erro ocorreu ou se você não encontrou o arquivo gunicorn.sock no diretório, é uma indicação de que o socket do Gunicorn não foi criado corretamente. Verifique os registros do socket do Gunicorn digitando:

      • sudo journalctl -u gunicorn.socket

      Veja novamente o seu arquivo /etc/systemd/system/gunicorn.socket para corrigir qualquer problema antes de continuar.

      Testando a ativação do socket

      Se tiver iniciado apenas a unidade gunicorn.socket, o gunicorn.service ainda não estará ativo, já que o socket ainda não recebeu nenhuma conexão. Você pode verificar isso digitando:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead)

      Para testar o mecanismo de ativação do socket, podemos enviar uma conexão para o socket através do curl digitando:

      • curl --unix-socket /run/gunicorn.sock localhost

      Você deve ver a saída HTML do seu aplicativo no terminal. Isso indica que o Gunicorn foi iniciado e conseguiu servir seu aplicativo Django. Você pode verificar se o serviço Gunicorn está funcionando digitando:

      • 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"

      Se o resultado do curl ou o resultado do systemctl status indicar que um problema ocorreu, verifique os registros para mais detalhes:

      • sudo journalctl -u gunicorn

      Verifique seu arquivo /etc/systemd/gunicorn.service quanto a problemas. Se fizer alterações no arquivo /etc/systemd/system/gunicorn.service, recarregue o daemon para reler a definição do serviço e reinicie o processo do Gunicorn digitando:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn

      Certifique-se de que você tenha resolvido os problemas acima antes de continuar.

      Configurar o Nginx para passagem de proxy para o Gunicorn

      Agora que o Gunicorn está configurado, precisamos configurar o Nginx para passar o tráfego para o processo.

      Inicie criando e abrindo um novo bloco de servidor no diretório sites-available do Nginx:

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

      Lá dentro, abra um novo bloco de servidor. Vamos começar especificando que este bloco deve escutar a porta normal 80 e que ele deve responder ao nome de domínio ou endereço IP do nosso servidor:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      }
      

      Em seguida, vamos dizer ao Nginx para ignorar todos os problemas ao encontrar um favicon. Também vamos dizer a ele onde encontrar os ativos estáticos que coletamos no nosso diretório ~/myprojectdir/static Todos esses arquivos têm um prefixo URI padrão “/static”, então podemos criar um bloco de localização para corresponder a esses pedidos:

      /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;
          }
      }
      

      Por fim, vamos criar um bloco location / {} para corresponder a todos os outros pedidos. Dentro deste local, vamos incluir o arquivo proxy_params padrão incluído na instalação do Nginx e então vamos passar o tráfego diretamente para o socket do 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;
          }
      }
      

      Salve e feche o arquivo quando você terminar. Agora, podemos habilitar o arquivo ligando-o ao diretório sites-enabled:

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Teste sua configuração do Nginx para erros de sintaxe digitando:

      Se nenhum erro for reportado, vá em frente e reinicie o Nginx digitando:

      • sudo systemctl restart nginx

      Por fim, precisamos abrir nosso firewall para o tráfego normal na porta 80. Como já não precisamos mais acessar o servidor de desenvolvimento, podemos remover também a regra para abrir a porta 8000:

      • sudo ufw delete allow 8000
      • sudo ufw allow 'Nginx Full'

      Agora, você deve conseguir ir ao domínio ou endereço IP do seu servidor para ver seu aplicativo.

      Nota: Depois de configurar o Nginx, o próximo passo deve ser proteger o tráfego para o servidor usando SSL/TLS. Isso é importante, pois sem ele, todas as informações, incluindo senhas são enviadas para a rede em texto simples.

      Se você tiver um nome de domínio, a maneira mais fácil de obter um certificado SSL para proteger seu tráfego é usando o Let’s Encrypt. Siga este guia para configurar o Let’s Encrypt com o Nginx no Ubuntu 18.04. Siga o procedimento usando o bloco de servidor do Nginx que criamos neste guia.

      Se você não tiver um nome de domínio, ainda é possível proteger seu site como teste e aprendizado com um certificado SSL autoassinado. Novamente, siga o procedimento usando o bloco de servidor do Nginx que criamos neste tutorial.

      Solucionando problemas do Nginx e do Gunicorn

      Se este último passo não mostrar o seu aplicativo, será necessário resolver o problema da sua instalação.

      Nginx está mostrando a página padrão ao invés do aplicativo Django

      Se o Nginx mostra a página padrão em vez de transferir via proxy para seu aplicativo, isso geralmente significa que você precisa ajustar o server_name dentro do arquivo /etc/nginx/sites-available/myproject para apontar ao endereço IP ou nome de domínio do seu servidor.

      O Nginx usa o server_name para determinar qual bloco de servidor usar para responder aos pedidos. Se você estiver vendo a página padrão do Nginx, é um sinal de que o Nginx não conseguiu corresponder ao pedido a um bloco de servidor explicitamente, então ele está recorrendo ao bloco padrão definido em /etc/nginx/sites-available/default.

      O server_name no bloco de servidor do seu projeto deve ser mais específico do que aquele no bloco de servidor padrão para ser selecionado.

      Nginx está exibindo um erro 502 Bad Gateway ao invés do aplicativo Django

      Um erro 502 indica que o Nginx é incapaz de atuar como proxy para o pedido com sucesso. Uma ampla gama de problemas de configuração se expressam com um erro 502, então é necessário mais informações para resolver o problema corretamente.

      O primeiro lugar para procurar mais informações é nos registros de erro do Nginx. Geralmente, isso irá dizer-lhe quais condições causaram problemas durante o evento de proxy. Vá até os registros de erro do Nginx, digitando:

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

      Agora, faça outro pedido no seu navegador para gerar um novo erro (tente atualizar a página). Você deve ver uma nova mensagem de erro escrita no registro. Se olhar para a mensagem, ela deve ajudar você a estreitar o problema.

      Pode ser que você veja algumas dessas mensagens:

      connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

      Isso indica que o Nginx foi incapaz de encontrar o arquivo gunicorn.sock no local indicado. Você deve comparar a localização do proxy_pass definida dentro do arquivo /etc/nginx/sites-available/myproject com a localização real do arquivo gunicorn.sock gerado pela unidade systemd gunicorn.socket.

      Se você não puder encontrar um arquivo gunicorn.sock dentro do diretório /run, isso signica geralmente que o arquivo de socket do systemd foi incapaz de criá-lo. Volte para a seção sobre checar o arquivo de socket do Gunicorn para seguir as etapas de solução de problemas para o Gunicorn.

      connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

      Isso indica que o Nginx foi incapaz de se conectar ao socket do Gunicorn devido a problemas de permissão. Isso pode acontecer quando o procedimento é seguido usando o usuário raiz ao invés de um usuário sudo. Embora o systemd seja capaz de criar o arquivo de socket do Gunicorn, o Nginx é incapaz de acessá-lo.

      Isso pode acontecer se houver permissões limitadas em qualquer ponto entre o diretório raiz (/) e o arquivo gunicorn.sock. Podemos ver as permissões e os valores de posse do arquivo de socket e cada um dos seus diretórios pais passando o caminho absoluto para nosso arquivo de socket pelo comando namei:

      • namei -l /run/gunicorn.sock

      Output

      f: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock

      O resultado mostra as permissões de cada um dos componentes do diretório. Ao olhar para as permissões (primeira coluna), proprietário (segunda coluna) e proprietário do grupo (terceiro coluna), podemos descobrir qual tipo de acesso é permitido ao arquivo de socket.

      No exemplo acima, o arquivo de socket e cada um dos diretórios que levam ao arquivo de socket têm permissões de leitura e execução global (a coluna de permissões para os diretórios termina com r-x ao invés de ---). O processo Nginx deve ser capaz de acessar o socket com sucesso.

      Se qualquer um dos diretórios que levam ao socket não tiverem permissão de leitura e execução global, o Nginx não poderá acessar o socket sem permitir permissões de leitura e execução globais ou garantir que o proprietário do grupo seja dado a um grupo do qual o Nginx faça parte.

      Django está exibindo: “could not connect to server: Connection refused”

      Uma mensagem que você pode ver do Django ao tentar acessar partes do aplicativo no navegador Web é:

      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?
      

      Isso indica que o Django é incapaz de se conectar ao banco de dados do Postgres. Certifique-se de que a instância do Postgres está sendo executada digitando:

      • sudo systemctl status postgresql

      Se não estiver, você pode iniciá-la e habilitá-la para iniciar automaticamente no boot (se ela ainda não estiver configurada para fazer isso) digitando:

      • sudo systemctl start postgresql
      • sudo systemctl enable postgresql

      Se ainda estiver tendo problemas, certifique-se de que as configurações do banco de dados definidas no arquivo ~/myprojectdir/myproject/settings.py estão corretas.

      Soluções de problemas adicionais

      Para soluções de problemas adicionais, os registros podem ajudar a reduzir os problemas de raiz. Verifique cada um deles individualmente e procure mensagens que indiquem áreas de problemas.

      Os registros a seguir podem ser úteis:

      • Verifique os registros de processo do Nginx digitando: sudo journalctl -u nginx
      • Verifique os registros de acesso do Nginx digitando: sudo less /var/log/nginx/access.log
      • Verifique os registros de erro do Nginx digitando: sudo less /var/log/nginx/error.log
      • Verifique os registros do aplicativo Gunicorn digitando: sudo journalctl -u gunicorn
      • Verifique os registros do socket do Gunicorn digitando: sudo journalctl -u gunicorn.socket

      Conforme atualiza sua configuração ou aplicativo, provavelmente precisará reiniciar os processos para ajustá-los às suas alterações.

      Se atualizar seu aplicativo Django, você pode reiniciar o processo Gunicorn para aplicar as alterações, digitando:

      • sudo systemctl restart gunicorn

      Se alterar o socket ou arquivos de serviço do Gunicorn, recarregue o daemon e reinicie o processo, digitando:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn.socket gunicorn.service

      Se alterar a configuração do bloco de servidor do Nginx, teste a configuração e então o Nginx digitando:

      • sudo nginx -t && sudo systemctl restart nginx

      Estes comandos são úteis para aplicar as alterações conforme você ajusta sua configuração.

      Conclusão

      Neste guia, configuramos um projeto Django em seu próprio ambiente virtual. Configuramos o Gunicorn para traduzir pedidos de clientes para que o Django possa lidar com eles. Depois disso, configuramos o Nginx para agir como um proxy reverso para lidar com conexões de clientes e servir o projeto correto, dependendo da solicitação do cliente.

      O Django torna a criação de projetos e aplicativos simples, fornecendo muitas peças comuns, permitindo que você se concentre nos elementos únicos. Ao utilizar a cadeia de ferramentas geral descrita neste artigo, você pode servir facilmente os aplicativos que criar a partir de um único servidor.



      Source link

      Cómo configurar Django con Postgres, Nginx y Gunicorn en Ubuntu 18.04


      Introducción

      Django es un poderoso framework que puede ayudarle a poner en marcha su aplicación o sitio web con Python. Incluye un servidor de desarrollo simplificado para probar su código a nivel local. Sin embargo, para cualquier cosa que esté incluso apenas relacionada con la producción se requiere un servidor web más seguro y potente.

      En esta guía, demostraremos la forma de instalar y configurar algunos componentes en Ubuntu 18.04 para que sean compatibles y permitan que funcionen aplicaciones de Django. Configuraremos una base de datos de PostgreSQL en lugar de usar la base de datos predeterminada de SQLite. Configuraremos el servidor de aplicaciones de Gunicorn para que interactúe con nuestras aplicaciones. Luego, configuraremos Nginx para que invierta el proxy de Gunicorn, lo que nos dará acceso a sus funciones de seguridad y rendimiento para nuestras aplicaciones.

      Requisitos previos y objetivos

      Para completar esta guía, debe disponer de una nueva instancia de servidor de Ubuntu 18.04 con un cortafuegos básico y un usuario no root con privilegios sudo configurados. Puede aprender a configurar esto en nuestra guía de configuración inicial para servidores.

      Instalaremos Django en un entorno virtual. Instalar Django en un entorno específico para nuestro proyecto permitirá que sus proyectos y los requisitos de estos se administren por separado.

      Una vez que tengamos nuestra base de datos y la aplicación en funcionamiento, instalaremos y configuraremos el servidor de aplicaciones de Gunicorn. Esto servirá como interfaz para nuestra aplicación, al traducir las solicitudes de los clientes de HTTP a llamadas Python que nuestra aplicación puede procesar. Luego, instalaremos Nginx frente a Gunicorn para aprovechar sus mecanismos de administración de conexiones de alto rendimiento y sus características de seguridad fáciles de implementar.

      Comencemos.

      Instalar los paquetes desde los repositorios de Ubuntu

      Para iniciar este proceso, descargaremos e instalaremos todos los elementos necesarios desde los repositorios de Ubuntu. Usaremos el administrador de paquetes de Python pip para instalar componentes adicionales más tarde.

      Necesitaremos actualizar el índice de paquetes apt local y luego descargaremos e instalaremos los paquetes. Los paquetes que instalemos dependen de la versión de Python que use en su proyecto.

      Si usa Django con Python 3, escriba lo siguiente:

      • sudo apt update
      • sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

      Django 1.11 es la última versión que será compatible con Python 2. Si inicia nuevos proyectos, le recomendamos totalmente elegir Python 3. Si todavía necesita usar Python 2, escriba lo siguiente:

      • sudo apt update
      • sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

      Con esto se instalarán pip, los archivos de desarrollo de Python necesarios para compilar Gunicorn posteriormente, el sistema de base de datos de Postgres, las bibliotecas necesarias para la interacción con él, y el servidor web de Nginx.

      Crear la base de datos y el usuario de PostgreSQL

      Crearemos una base de datos y un usuario de base de datos para nuestra aplicación de Django.

      Por defecto, Postgres usa un esquema de autenticación llamado “autenticación por pares” para las conexiones locales. Básicamente, esto significa que si el nombre de usuario del sistema operativo del usuario coincide con un nombre de usuario de Postgres válido, ese usuario puede iniciar sesión sin autenticaciones adicionales.

      Durante la instalación de Postgres, se creó un usuario del sistema operativo llamado postgres para que se corresponda con el usuario administrativo postgres de PostgreSQL. Necesitamos usar este usuario para realizar tareas administrativas. Podemos usar sudo y pasar el nombre de usuario con la opción -u.

      Inicie una sesión interactiva de Postgres escribiendo lo siguiente:

      Recibirá un mensaje de PostgreSQL en el que se pueden configurar los requisitos.

      Primero, cree una base de datos para su proyecto:

      • CREATE DATABASE myproject;

      Nota: Cada instrucción de Postgres debe terminar con un punto y coma. Por ello, si está experimenta problemas debe asegurarse de que su comando tenga esta terminación.

      A continuación, cree un usuario de base de datos para nuestro proyecto. Asegúrese de elegir una contraseña segura.

      • CREATE USER myprojectuser WITH PASSWORD 'password';

      Más adelante, modificaremos algunos de los parámetros de conexión para el usuario que acabamos de crear. Esto acelerará las operaciones de la base de datos para que no sea necesario consultar y fijar los valores correctos cada vez que se establezca una conexión.

      Fijaremos el código predeterminado en UTF-8, lo que se prevé para Django. También fijaremos el esquema predeterminado de aislamiento de transacciones en “read committed”, que bloquea las lecturas de transacciones no comprometidas. Por último, configuraremos la zona horaria. Por defecto, nuestros proyectos de Django se configurarán para usar la opción UTC. Estas son todas las recomendaciones del propio proyecto de Django:

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

      Ahora, podemos brindar a nuestro nuevo usuario acceso para administrar nuestra nueva base de datos:

      • GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

      Cuando termine, cierre la línea de comandos de PostgreSQL escribiendo lo siguiente:

      Postgres quedará, así, configurado para que Django pueda conectarse y administrar la información de su base de datos.

      Crear un entorno virtual de Python para su proyecto

      Ahora que tenemos nuestra base de datos, podemos empezar a cumplir con el resto de los requisitos de nuestro proyecto. Instalaremos los componentes de Python requeridos en un entorno virtual para facilitar la administración.

      Para hacerlo, primero necesitamos acceso al comando virtualenv. Podemos instalarlo con pip.

      Si usa Python 3, actualice pip e instale el paquete escribiendo lo siguiente:

      • sudo -H pip3 install --upgrade pip
      • sudo -H pip3 install virtualenv

      Si usa** Python 2**, actualice pip e instale el paquete escribiendo lo siguiente:

      • sudo -H pip install --upgrade pip
      • sudo -H pip install virtualenv

      Con virtualenv instalado, podemos comenzar a dar forma a nuestro proyecto. Cree y un directorio en el que podamos guardar los archivos de nuestro proyecto y posiciónese en él:

      • mkdir ~/myprojectdir
      • cd ~/myprojectdir

      En el directorio del proyecto, cree un entorno virtual de Python escribiendo lo siguiente:

      Con esto, se creará un directorio llamado myprojectenv en su directorio myprojectdir. De forma interna, instalará una versión local de Python y una versión local de pip. Podemos usar esto para instalar y configurar un entorno aislado de Python para nuestro proyecto.“”“

      Antes de instalar los componentes de Python requeridos para nuestro proyecto, debemos activar el entorno virtual. Puede hacerlo escribiendo lo siguiente:

      • source myprojectenv/bin/activate

      Su línea de comandos cambiará para indicar que ahora realiza operaciones en un entorno virtual de Python. Tendrá un aspecto parecido a este: (myprojectenv)user@host:~/myprojectdir$.”

      Con su entorno virtual activo, instale Django, Gunicorn y el adaptador psycopg2 de PostgreSQL con la instancia local de pip:

      Nota: Cuando se active el entorno virtual (cuando (myprojectenv) se encuentre al inicio de su línea de comandos), use pip en lugar de pip3, incluso si emplea Python 3. La copia del entorno virtual de la herramienta siempre se llama pip, independientemente de la versión de Python.

      • pip install django gunicorn psycopg2-binary

      Con esto, debería contar con todo el software necesario para iniciar un proyecto en Django.

      Crear y configurar un nuevo proyecto de Django

      Una vez instalados nuestros componentes de Python, podemos crear los archivos reales del proyecto en Django.

      Crear el proyecto de Django

      Debido a que ya disponemos de un directorio de proyectos, le indicaremos a Django que instale los archivos en él. Se creará un directorio de segundo nivel con el código real, lo cual es normal, y se dispondrá una secuencia de comandos de administración en este directorio. La clave para esto es que definiremos el directorio de forma explícita en lugar de permitir que Django tome decisiones vinculadas con nuestro directorio actual:

      • django-admin.py startproject myproject ~/myprojectdir

      En este punto, el directorio de su proyecto (~/myprojectdir en nuestro caso) debe tener el siguiente contenido:“

      • ~/myprojectdir/manage.py: secuencia de comandos de administración del proyecto en Django.
      • ~/myprojectdir/myproject/: paquete de proyectos de Django. Este debería contener los archivos __init__.py, settings.py, urls.py y wsgi.py.
      • ~/myprojectdir/myprojectenv/: directorio del entorno virtual que creamos antes.

      Ajustar la configuración del proyecto

      Lo primero que debemos hacer con los archivos del proyecto recientemente creado es ajustar la configuración. Abra el archivo de configuración en su editor de texto:

      • nano ~/myprojectdir/myproject/settings.py

      Localice primero la directiva ALLOWED_HOSTS. Con esto, se define una lista de las direcciones de los servidores o los nombres de dominio que pueden usarse para establecer una conexión con la instancia en Django. Cualquier solicitud entrante con un encabezado de Host que no figure en esta lista generará una excepción. Django necesita que configure esto para evitar una clase de vulnerabilidad de seguridad determinada.

      Dentro de los corchetes, enumere las direcciones IP o los nombres de dominio asociados a su servidor de Django. Cada elemento debe listarse entre comillas y las entradas deben ir separadas por una coma. Si desea solicitudes para un dominio completo y cualquier subdominio, anteponga un punto al comienzo de la entrada. En el fragmento inferior, hay algunos ejemplos comentados que se usan para demostrar lo siguiente:

      Nota: Asegúrese de incluir localhost como una de las opciones, ya que autorizaremos conexiones a través de una instancia local de 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']
      

      A continuación, busque la sección que configura el acceso a la base de datos. Se iniciará con DATABASES. La configuración del archivo es para una base de datos de SQLite. Ya creamos una base de datos de PostgreSQL para nuestro proyecto. Ahora debemos ajustar las configuraciones.

      Cambie las configuraciones por la información de su base de datos de PostgreSQL. Indicaremos a Django que use el adaptador psycopg2 que instalamos con pip. Debemos proporcionar el nombre de la base de datos, el nombre de usuario y la contraseña del usuario, y luego especificar que la base de datos se encuentra en una computadora local. Puede dejar la configuración de PORT como una secuencia de comandos vacía:

      ~/myprojectdir/myproject/settings.py

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

      A continuación, diríjase hasta la parte inferior del archivo y agregue una configuración que indique dónde deben disponerse los archivos estáticos. Esto es necesario para que Nginx pueda manejar las solicitudes de estos elementos. La siguiente línea indica a Django que los disponga en un directorio llamado static en el directorio de proyectos de base:

      ~/myprojectdir/myproject/settings.py

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

      Guarde y cierre el archivo cuando termine.

      Completar la configuración inicial del proyecto

      Ahora, podemos migrar el esquema inicial de la base de datos a nuestra base de datos de PostgreSQL usando la secuencia de comandos de administración:

      • ~/myprojectdir/manage.py makemigrations
      • ~/myprojectdir/manage.py migrate

      Cree un usuario administrativo para el proyecto escribiendo lo siguiente:

      • ~/myprojectdir/manage.py createsuperuser

      Deberá seleccionar el nombre de usuario, proporcionar una dirección de correo electrónico y elegir y confirmar una contraseña.

      Podemos recolectar todo el contenido estático en la ubicación del directorio que configuramos escribiendo lo siguiente:

      • ~/myprojectdir/manage.py collectstatic

      Deberá confirmar la operación. Luego, los archivos estáticos se ubicarán en un directorio llamado static, dentro del directorio de su proyecto.

      Si siguió la guía de configuración inicial para servidores, debería proteger su servidor con un firewall UFW. Para probar el servidor de desarrollo, tendremos que permitir el acceso al puerto que usaremos.

      Cree una excepción para el puerto 8000 escribiendo lo siguiente:

      Por último, puede probar su proyecto iniciando el servidor de desarrollo de Django con este comando:

      • ~/myprojectdir/manage.py runserver 0.0.0.0:8000

      En su buscador web, agregue :8000 al final del nombre del dominio o de la dirección IP de su servidor y visítelos:

      http://server_domain_or_IP:8000
      

      Debería ver la página de índice predeterminada de Django:

      Página de índice de Django

      Si agrega /admin al final de la URL en la barra de direcciones, se le solicitará el nombre de usuario administrativo y la contraseña que creó con el comando createsuperuser:

      Inicio de sesión de administrador de Django

      Después de la autenticación, puede acceder a la interfaz administrativa predeterminada de Django:

      Interfaz de administración de Django

      Cuando finalice la exploración, presione *CTRL-C *en la ventana de la terminal para desactivar el servidor de desarrollo.

      Poner a prueba la capacidad de Gunicorn para presentar el proyecto

      Lo último que nos convendrá hacer antes de cerrar nuestro entorno virtual será probar Gunicorn para asegurarnos de que pueda hacer funcionar la aplicación. Podemos hacerlo ingresando a nuestro directorio de proyectos y usando gunicorn para cargar el módulo WSGI del proyecto:

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

      Con esto se iniciará Gunicorn en la misma interfaz en la que se encontraba en ejecución el servidor de desarrollo en Django. Puede volver y probar la aplicación de nuevo.

      Nota: No se aplicará el estilo a la interfaz de administración, ya que Gunicorn no tiene forma de encontrar el contenido estático de CSS responsable de este.

      Pasamos a Gunicorn un módulo especificando la ruta relativa del directorio al archivo wsgi.py de Django, que es el punto de entrada a nuestra aplicación, usando la sintaxis del módulo de Python. Dentro de este archivo, se define una función llamada application, que se usa para comunicarse con la aplicación. Para obtener más información sobre la especificación de WSGI, haga clic aquí.

      Cuando termine de realizar las pruebas, presione CTRL-C en la ventana de la terminal para detener Gunicorn.

      Con esto habremos terminado de configurar nuestra aplicación en Django. Podemos cerrar nuestro entorno virtual escribiendo lo siguiente:

      Se eliminará el indicador del entorno virtual en su línea de comandos.

      Crear archivos de socket y servicio de systemd para Gunicorn

      Comprobamos que Gunicorn puede interactuar con nuestra aplicación en Django, pero debemos implementar un mejor método para iniciar y detener el servidor de la aplicación. Para lograr esto, crearemos archivos de servicio y socket systemd.

      El socket Gunicorn se creará en el inicio y escuchará las conexiones. Cuando se establezca una conexión, systemd iniciará de forma automática el proceso de Gunicorn para manejarla conexión.

      Comience creando y abriendo un archivo de socket de systemd para Gunicorn con privilegios sudo:

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

      Dentro de él, crearemos una sección [Unit] para describir el socket, una sección [Socket] para definir la ubicación del socket y una sección [Install] para asegurarnos de que el socket se cree en el momento adecuado:

      /etc/systemd/system/gunicorn.socket

      [Unit]
      Description=gunicorn socket
      
      [Socket]
      ListenStream=/run/gunicorn.sock
      
      [Install]
      WantedBy=sockets.target
      

      Guarde y cierre el archivo cuando termine.

      A continuación, cree y abra un archivo de servicio systemd para Gunicorn con privilegios sudo en su editor de texto. El nombre del archivo de servicio debe coincidir con el de socket, salvo en la extensión:

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

      Empiece por la sección [Unit], que se usa para especificar metadatos y dependencias. Aquí introduciremos una descripción de nuestro servicio e indicaremos al sistema init que lo inicie solo tras haber alcanzado el objetivo de red: Debido a que nuestro servicio se basa en el socket del archivo de sockets, necesitamos incluir una directiva Requires para indicar esta relación:

      /etc/systemd/system/gunicorn.service

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

      A continuación, abriremos la sección [Service]. Especificaremos el usuario y el grupo con los cuales deseamos que se ejecute el proceso. Otorgaremos la propiedad del proceso a nuestra cuenta de usuario normal, ya que tiene la propiedad de todos los archivos pertinentes. Otorgaremos la propiedad del grupo al grupo www-data para que Nginx pueda comunicarse fácilmente con Gunicorn.

      Luego, mapearemos el directorio de trabajo y especificaremos el comando que se usará para iniciar el servicio. En este caso, tendremos que especificar la ruta completa al ejecutable de Gunicorn, que está instalado en nuestro entorno virtual. Vincularemos el proceso con el socket de Unix que creamos en el directorio /run para que el proceso pueda comunicarse con Nginx. Registramos todos los datos a la salida estándar para que el proceso journald pueda recopilar los registros de Gunicorn. También podemos especificar cualquier ajuste opcional de Gunicorn aquí. Por ejemplo, especificamos 3 procesos de trabajadores en este caso:

      /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
      

      Por último, agregaremos una sección [Install]. Esto indicará a systemd a qué deberá vincular este servicio si lo habilitamos para que se cargue en el inicio. Queremos que este servicio se inicie cuando el sistema multiusuario normal esté en funcionamiento:

      /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
      

      Con eso, nuestro archivo de servicio de systemd quedará completo. Guárdelo y ciérrelo ahora.

      Ahora podemos iniciar y habilitar el socket de Gunicorn. Con esto se creará el archivo de socket en /run/gunicorn.sock ahora y en el inicio. Cuando se establezca una conexión con ese socket, systemd iniciará gunicorn.service de forma automática para gestionarla:

      • sudo systemctl start gunicorn.socket
      • sudo systemctl enable gunicorn.socket

      Podemos confirmar que la operación se haya completado con éxito revisando el archivo de sockets.

      Verificar el archivo de socket de Gunicorn

      Compruebe el estado del proceso para saber si pudo iniciar lo siguiente:

      • sudo systemctl status gunicorn.socket

      A continuación, compruebe la existencia del archivo gunicorn.sock en el directorio /run:

      Output

      /run/gunicorn.sock: socket

      Si el comando systemctl status indica que se produjo un error o si no encuentra el archivo gunicorn.sock en el directorio, significa que no se pudo crear de forma correcta el socket de Gunicorn. Verifique los registros del socket de Gunicorn escribiendo lo siguiente:

      • sudo journalctl -u gunicorn.socket

      Vuelva a revisar su archivo /etc/systemd/system/gunicorn.socket para solucionar cualquier problema antes de continuar.

      Poner a prueba la activación de sockets

      En este punto, si solo inició la unidad gunicorn.socket, gunicorn.service aún no estará activo, ya que el socket aún no habrá recibido conexiones. Puede comprobarlo escribiendo lo siguiente:

      • sudo systemctl status gunicorn

      Output

      ● gunicorn.service - gunicorn daemon Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled) Active: inactive (dead)

      Para probar el mecanismo de activación de sockets, podemos enviar una conexión al socket a través de curl escribiendo lo siguiente:

      • curl --unix-socket /run/gunicorn.sock localhost

      Debería ver el resultado HTML de su aplicación en la terminal. Esto indica que Gunicorn se inició y pudo presentar su aplicación de Django. Puede verificar que el servicio de Gunicorn funcione escribiendo lo siguiente:

      • 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"

      Si el resultado de curl o systemctl status indica que se produjo un problema, verifique los registros para obtener información adicional:

      • sudo journalctl -u gunicorn

      Verifique su archivo /etc/systemd/systemd/system/gunicorn.service en busca de problemas. Si realiza cambios en el archivo /etc/systemd/systemd/system/gunicorn.service, vuelva a cargar el demonio para volver a leer la definición de servicio y reiniciar el proceso de Gunicorn escribiendo lo siguiente:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn

      Asegúrese de resolver los problemas mencionados previamente antes de continuar.

      Configurar Nginx para un pase de autorización a Gunicorn

      Ahora que Gunicorn está configurado, debemos configurar Nginx para transferir tráfico al proceso.

      Comience creando y abriendo un nuevo bloque de servidor en el directorio sites-available de Nginx:

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

      Dentro de este, abra un nuevo bloque de servidor. Comenzaremos especificando que este bloque debe escuchar en el puerto normal 80 y responder al nombre de dominio o a la dirección IP de nuestro servidor:

      /etc/nginx/sites-available/myproject

      server {
          listen 80;
          server_name server_domain_or_IP;
      }
      

      A continuación, indicaremos a Nginx que ignore cualquier problema para encontrar un favicon. También le indicaremos dónde encontrar los activos estáticos que recolectamos en nuestro directorio ~/myprojectdir/static. Todos estos archivos tienen un prefijo URI de “/static”, para que podamos crear un bloque de ubicación que coincida con estas solicitudes:”

      /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;
          }
      }
      

      Por último, crearemos un bloque location / {} para que coincida con todas las demás solicitudes. Dentro de esta ubicación, agregaremos el archivo proxy_params estándar incluido con la instalación de Nginx y luego transferiremos el tráfico directamente al socket de 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;
          }
      }
      

      Guarde y cierre el archivo cuando termine. Ahora, podemos habilitar el archivo vinculándolo al directorio sites-enabled:

      • sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

      Pruebe su configuración de Nginx para descartar errores de sintaxis escribiendo lo siguiente:

      Si no se notifican errores, reinicie Nginx escribiendo lo siguiente:

      • sudo systemctl restart nginx

      Por último, debemos abrir nuestro firewall al tráfico normal en el puerto 80. Como ya no necesitamos acceso al servidor de desarrollo, podemos eliminar la regla para abrir también el puerto 8000:

      • sudo ufw delete allow 8000
      • sudo ufw allow 'Nginx Full'

      Ahora debería poder acceder al dominio o a la dirección IP de su servidor para ver su aplicación.

      Nota: Después de configurar Nginx, el siguiente paso debería ser proteger el tráfico al servidor usando SSL/TLS. Esto es importante porque, si no se aplica, toda la información, incluidas las contraseñas, se envía a través de la red en texto simple.

      Si tiene un nombre de dominio, la alternativa más sencilla para obtener un certificado SSL para proteger su tráfico es usar Let’s Encrypt. Siga esta guía para configurar Let’s Encrypt con Nginx en Ubuntu 18.04. Siga el procedimiento usando el bloque de servidor de Nginx que creamos en esta guía.

      Si no tiene un nombre de dominio, aún puede proteger su sitio para pruebas y aprendizaje con un certificado SSL autofirmado. Nuevamente, siga el proceso usando el bloque de servidor Nginx que creamos en este tutorial.

      Resolver problemas en Nginx y Gunicorn

      Si con este último paso no se muestra su aplicación, deberá resolver problemas en su instalación.

      Nginx muestra la página predeterminada en lugar de la aplicación de Django

      Si Nginx muestra la página predeterminada en lugar de actualizar su aplicación, normalmente significa que deberá ajustar el server_name dentro del archivo /etc/nginx/sites-available/myproject para apuntar a la dirección IP o al nombre de dominio de su servidor.

      Nginx usa el server_name para determinar el bloque de servidor que usará para responder a solicitudes. Si ve la página predeterminada de Nginx, significa que Nginx no pudo hacer coincidir la solicitud con un bloque de servidor de forma explícita, por lo cual recurre al bloque por defecto definido en /etc/nginx/sites-available/default.

      El server_name del bloque de servidor de su proyecto debe ser más específico que el del bloque de servidor predeterminado que se seleccionará.

      Nginx muestra un error de puerta de enlace 502 en lugar de la aplicación de Django

      Un error 502 indica que Nginx no puede autorizar con éxito la solicitud. Con el error 502 se transmite una amplia variedad de problemas de configuración, por lo que se necesita más información para resolver los problemas de forma adecuada.

      Los registros de errores de Nginx son el recurso principal para buscar más información. Generalmente, esto le indicará las condiciones que ocasionaron problemas durante el evento de autorización. Siga los registros de errores de Nginx escribiendo lo siguiente:

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

      Ahora, realice otra solicitud en su navegador para generar un nuevo error (intente actualizar la página). Debería ver un nuevo mensaje de error escrito en el registro. Si ve el mensaje, le servirá para reducir el problema.

      Es posible que vea algunos de los mensajes que se muestran a continuación:

      connect() to unix:/run/gunicorn.sock failed (2: No such file or directory)

      Esto indica que Nginx no pudo encontrar el archivo gunicorn.sock en la ubicación en cuestión. Debería comparar la ubicación de proxy_pass definida en el archivo /etc/nginx/sites-available/myproject con la ubicación actual del archivo gunicorn.sock generado por la unidad de systemd gunicorn.sock.

      Si no puede encontrar un archivo gunicorn.sock en el directorio /run, por lo general significa que el archivo de socket de systemd no pudo crearlo. Regrese a la sección de verificación del archivo de socket de Gunicorn para seguir los pasos de resolución de problemas de Gunicorn.

      connect() to unix:/run/gunicorn.sock failed (13: Permission denied)

      Esto indica que Nginx no pudo conectarse al socket de Gunicorn debido a problemas de permisos. Esto puede ocurrir cuando se sigue el procedimiento con un usuario root en lugar de un usuario sudo. Aunque systemd puede crear el archivo de socket de Gunicorn, Nginx no puede acceder a él.

      Esto puede ocurrir si existen permisos limitados en cualquier punto entre el directorio root (/) y el archivo gunicorn.sock. Podemos ver los permisos y valores de propiedad del archivo de socket y cada uno de sus directorios pasando la ruta absoluta a nuestro archivo de socket al comando namei:

      • namei -l /run/gunicorn.sock

      Output

      f: /run/gunicorn.sock drwxr-xr-x root root / drwxr-xr-x root root run srw-rw-rw- root root gunicorn.sock

      En el resultado se muestran los permisos de cada uno de los componentes del directorio. Al mirar los permisos (primera columna), el propietario (segunda columna) y el propietario del grupo (tercera columna), podemos averiguar el tipo de acceso permitido para el archivo de socket.

      En el ejemplo anterior, el archivo de sockets y cada directorio que conduce a este tienen permisos mundiales de lectura y ejecución (la columna de permisos para los directorios termina en r-x en lugar de ---). El proceso de Nginx debería poder acceder al socket de forma correcta.

      Si algunos directorios que conducen al socket no tienen permiso mundial de lectura y ejecución, Nginx no podrá acceder al socket sin otorgar permisos mundiales de lectura y ejecución ni asegurarse de que se otorgue propiedad del grupo a un grupo del que forme parte Nginx.

      Django muestra el mensaje “could not connect to server: Connection refused”

      Se puede ver el el siguiente mensaje de Django al intentar acceder a partes de la aplicación en el navegador web:

      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?
      

      Esto indica que Django no puede conectarse a la base de datos de Postgres. Asegúrese de que la instancia de Postgres esté en ejecución escribiendo lo siguiente:

      • sudo systemctl status postgresql

      Si esto no sucede, puede iniciarla y activarla para que se cargue automáticamente en el inicio (si aún no está cargada la configuración para ello) escribiendo lo siguiente:

      • sudo systemctl start postgresql
      • sudo systemctl enable postgresql

      Si todavía experimenta problemas, asegúrese de que los ajustes de la base de datos definidos en el archivo ~/myprojectdir/myproject/settings.py sean correctos.

      Solución de problemas adicionales

      Para resolver problemas adicionales, los registros pueden servir para reducir las causas raíces. Verifique cada uno de ellos por separado y busque mensajes que indiquen las áreas problemáticas.

      Los siguientes registros pueden ser útiles:

      • Verifique los registros de proceso de Nginx escribiendo lo siguiente: sudo journalctl -u nginx.
      • Verifique los registros de acceso de Nginx escribiendo lo siguiente: sudo less /var/log/nginx/access.log
      • Verifique los registros de errores de Nginx escribiendo lo siguiente: sudo less /var/log/nginx/error.log.
      • Verifique los registros de la aplicación de Gunicorn escribiendo lo siguiente: sudo journalctl -u gunicorn.
      • Verifique los registros de sockets de Gunicorn escribiendo lo siguiente: sudo journalctl -u gunicorn.socket.

      Cuando actualice su configuración o aplicación, es probable que necesite reiniciar los procesos para que asimilen sus cambios.

      Si actualiza su aplicación de Django, puede reiniciar el proceso de Gunicorn para que incorpore los cambios escribiendo lo siguiente:

      • sudo systemctl restart gunicorn

      Si cambia los archivos de socket y servicio de Gunicorn, vuelva a cargar el demonio y reinicie el proceso escribiendo lo siguiente:

      • sudo systemctl daemon-reload
      • sudo systemctl restart gunicorn.socket gunicorn.service

      Si cambia la configuración de bloque del servidor de Nginx, pruébela y luego verifique Nginx escribiendo lo siguiente:

      • sudo nginx -t && sudo systemctl restart nginx

      Estos comandos son útiles para incorporar cambios cuando ajusta su configuración.

      Conclusión

      En esta guía, creamos un proyecto de Django en su propio entorno virtual. Configuramos Gunicorn para que traduzca las solicitudes de los clientes a fin de que Django pueda manejarlas. Posteriormente, configuramos Nginx para que actúe como proxy inverso a fin de manejar las conexiones de los clientes y presentar el proyecto correcto según la solicitud del cliente.

      Django simplifica la creación de proyectos y aplicaciones proporcionando muchas de las piezas comunes, lo que le permite centrarse en los elementos únicos. Al aprovechar la cadena general de herramientas descrita en este artículo, puede ofrecer fácilmente las aplicaciones que cree desde un servidor único.



      Source link