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

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

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

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 прокси. Но сделайте это все, прежде чем у вас есть приложение в производстве. Этот подход, я видел, увеличивает понимание и уменьшает разочарование.


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

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

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


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


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

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

обновление:

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

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


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