Запуск Django с Gunicorn - лучшая практика

Существует 3 способа запуска приложения django с помощью gunicorn:

  • Стандарт gunicorn + wsgi (ref django doc)

    gunicorn project.wsgi:application

  • Использование интеграции пуэрстона django (ref gunicorn doc и django doc):

    python manage.py run_gunicorn

  • Использование команды gunicorn_django (ref gunicorn doc)

    gunicorn_django [OPTIONS] [SETTINGS_PATH]

Документация Django предлагает использовать 1., который даже не указан в документации по Gunicorn.

Есть ли какая-либо лучшая практика для наилучшего способа запуска приложения django с помощью gunicorn, и каковы преимущества или недостатки этих различных решений?

Взглянув на код увольнения, похоже, что они почти все делают то же самое: 2. похоже, создается приложение wsgi, используя django internals и 3. использует 2.

Если это так, я даже не пойму, в чем причина не просто использовать "1.", все время, тем более что файл wsgi.py автоакпируется для вас с django 1.4; если это правда, возможно, просто рекомендуется улучшить документацию...

Кроме того, лучшая практика для настроек пушки с django будет отличной. Используя 1., имеет смысл установить некоторые значения по умолчанию в файле wsgi и избежать дополнительных настроек?

Литература:

Ответы

Ответ 1

После проверки я бы сказал, что лучший способ - использовать gunicorn + wsgi

$ gunicorn project.wsgi:application

Теперь это подтверждается и в документах-стрелках: если вы запускаете Django 1.4 или новее, настоятельно рекомендуется просто запустить приложение с интерфейсом WSGI с помощью пушки команда и django как указано выше.

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

О настройках

Файл настроек Django, который будет использоваться, может быть передан через переменную ENV или настроен в файле wsgi.py. Иногда я создаю несколько файлов wsgi.py, если у меня есть несколько параметров (например, несколько веб-сайтов), которые должны запускаться из одного проекта - См. Django Doc для получения дополнительной информации.

Однострочное решение, которое не требует никакого нового файла из Carl comment:

DJANGO_SETTINGS_MODULE=project.settings.prod gunicorn project.wsgi:application

звучит как приятный способ (хотя я, вероятно, в конечном итоге напишу его в некоторых командах оболочки, чтобы было легко "запомнить" ).

Настройки Gunicorn могут быть переданы как -c settings_file, но я изучаю другие способы и попытаюсь обновить этот ответ, если найду что-нибудь. Использование переменных среды кажется рабочим, но только для ограниченных случаев

В частности, было бы неплохо получить/поделиться некоторыми настройками между django и gunicorn; в документации по стрельбе:

В настоящее время только приложения Paster имеют доступ к инфраструктуре конкретные настройки. Если у вас есть идеи по настройке WSGI приложения или вытаскивание информации из настроек Djangos.py бесплатно, чтобы открыть вопрос, чтобы сообщить нам.

( Обновить: не нашли более разумного способа, но ведь для всех наиболее распространенных случаев достаточно env-переменных).

Ответ 2

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

Это в основном то же самое, что и usign gunicorn project.wsgi:application, но для добавления в INSTALLED_APPS необходимо добавить gunicorn, чтобы django распознал команду run_gunicorn, поэтому он, вероятно, не по умолчанию...

Использование gunicorn_django более или менее устарело, так как в документации также указано здесь...