Может ли Django работать на Gunicorn в одиночку (без Apache или nginx)?

Я пробовал почти каждый учебник django + nginx в интернете, и я не могу получить файл изображения для отображения на экране. Это всегда старая история ... --1-- > 404 СТРАНИЦА НЕ НАЙДЕНА. Веб-страница загружается нормально, но Джанго.PNG в моем /static/ нет. Не уверен, что это проблема в settings.py или с nginx.

Я так расстроен этим, что отказываюсь смотреть на другой "как получить учебник nginx/django". Если я разверну веб-сайт в ближайшем будущем будет ли Gunicorn достаточно для запуска сайта Django и одновременного обслуживания статических файлов без использования Apache или nginx? Есть ли большое преимущество в том, чтобы иметь обратный прокси-сервер в первую очередь?

8
amazon-ec2 django gunicorn nginx python

5 ответов

да. Gunicorn может служить статический.

Если все остальное не удается, пусть django сделает это за вас (хотя, сделайте это в крайнем случае перед разочарованием.) Для этого вам просто нужно добавить еще один шаблон url, как показано ниже:

urlpatterns = patterns('',
    # ... the rest of your URLconf goes here ...
) + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)

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

Я бы рекомендовал запустить nginx на другом порту для начала и изменить параметр django STATIC_URL для включения порта (после подтверждения того, что порт обслуживает статику). - Сделать это так же просто, как сделать simlink на MEDIA_ROOT из папки nginx.

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

Я вижу, как это может смущать тех, кто запуск и попытка сделать все (прокси-запросы, обслуживать статику, настраивать nginx) сразу. Попробуйте один за другим. Вам СМИ от gunicorn; затем обслуживать его с nginx и потом тоже в nginx прокси. Но сделайте это все, прежде чем у вас есть приложение в производстве. Этот подход, я видел, увеличивает понимание и уменьшает разочарование.

7

документация Gunicorn отмечает, что без прокси буферизации медленных клиентов, работник по умолчанию подвержен атакам: http://gunicorn.org/deploy.html

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

Это может быть не так при использовании одного из асинхронных рабочих, таких как gevent или tornado.

7

Если вы уже используете amazon web services, вы можете использовать ведра s3 для размещения статического контента и развертывания приложения в ec2 с помощью gunicorn (или что угодно). Таким образом, вам не нужно беспокоиться о настройке собственного статического файлового сервера.

5

Я рекомендую использовать Nginx спереди по нескольким причинам:

  • обслуживание или внутренняя страница ошибки сервера можно легко снабдить когда gunicorn вниз. Это означает, что вам всегда будет что ответить, если ваш сервер приложений не работает.
  • Как Gunicorn doc предполагает, что HTTP-атаки, такие как DOS, не обнаруживаются.
  • вы можете реализовать свою собственную стратегию балансировки нагрузки позже. Это станет более важным для релизов, как ваш проект. Лично я нашел AWS ELB немного ненадежным, и я думаю об этом.

обновление:

кроме того, см. хорошо написанный ответ разработчика Gunicorn:

зачем мне Nginx и что-то вроде Gunicorn?

2

Я сделал с помощью промежуточного сверла. Не является красивым, ни performant как использование сервера nginx, но выполняет работу:

установить STATIC_ROOT на settings.py

# project/settings.py
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__)))
STATIC_ROOT = BASE_DIR+'/static-collected'

чем сказать Werkzeug обслуживать файлы из этой папки

# project/wsgi.py
import os
BASE_DIR = os.path.dirname(os.path.dirname(__file__))

(...)
from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()
(...)

import os
from werkzeug.wsgi import SharedDataMiddleware
print 'Installing WSGI static files server middleware'
application = SharedDataMiddleware(application, {
    '/static': os.path.join(BASE_DIR, 'static-collected'),
})

когда DEBUG=True, Django обслуживает файлы. Когда DEBUG=False, Werkzeug обслуживает файлы из папки со статическим сбором. Для этого необходимо запустить collectstatic на сервере, использующем DEBUG=False.

Obs: Для по какой-то причине Werkzeug дает 500 для не найденных файлов, а не 404. Это странно, но все еще работает. Если вы знаете, почему, пожалуйста, прокомментируйте.

1