nginx + FastCGI для приложения django --- запустить два веб-сервера или один?

Question

Я собираюсь развернуть приложение Django на веб-сервере nginx и хочу убедиться, что я правильно собираю систему.

Кажется, что распространено мнение, что если вы развертываете Django на сервере apache, вам все равно следует поместить сервер nginx перед приложением для обслуживания статических файлов, что делает nginx более производительным.

Если вместо apache для кода Django я бы хотел использовать nginx + FastCGI для размещения приложения Django, есть ли причина настроить вторую установку nginx на сервер nginx, обслуживающий динамический контент, обрабатывать статический контент, а также перенаправлять на динамический контент?

В частности, будут ли разные параметры конфигурации для статического и динамического контента, из-за которых я хочу разделить серверы, или я могу разместить все это в одной установке nginx, при этом некоторые URL-адреса будут сопоставлены с контентом django а остальные сопоставляются со статическим контентом, обслуживаемым из той же установки nginx?

Спасибо за ваш совет!

Answer 1

Большинство директив config могут находиться в блоках местоположения (то есть они не только глобальные), и это очень распространенная практика. У вас не должно возникнуть проблем с настройкой, используя только 1 экземпляр nginx.

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

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

Answer 2

Чтобы ответить на ваш вопрос о размещении сервера nginx перед другим nginx: Нет, обычно для этого нет веских причин. Этот старый совет исходит от Apache, особенно когда mod_python использовался с prefork MPM Apache. В этой настройке каждый экземпляр Django будет запускаться как отдельный процесс внутри контейнера mod_python / Apache, и для этого потребуется много оперативной памяти. Идея состояла в том, чтобы сохранить обслуживание статических файлов вдали от Apache, разместив легкий, управляемый событиями HTTP-сервер, такой как nginx, перед тяжелыми процессами Apache. Это позволило сэкономить оперативную память и повысить производительность. При использовании облегченного сервера, такого как nginx, для всех запросов это не проблема.

nginx хорошо справляется с перезаписью URL, посмотрите в модуль Rewrite.

В вашем вопросе не указано, какую нагрузку (число соединений в секунду) вы ожидаете или почему вы хотите использовать nginx. Если это для блога на VPS-сервере или аналогичной установки с низкой нагрузкой, то обратите внимание на использование Apache с mod_wsgi в режиме демона. Это имеет производительность и использование ОЗУ очень близко к FastCGI, и mod_wsgi недавно стал официально рекомендованным способом размещения Django, см. http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/

В общем, я бы предложил использовать Apache / mod_wsgi, если это возможно, это стабильная и гибкая комбинация. Убедитесь, что вы не «преждевременно оптимизируете», используя nginx, где Apache + mod_wsgi прекрасно подойдет. Обзор производительности mod_wsgi в режиме демона смотрите: http://code.google.com/p/modwsgi/wiki/PerformanceEstimates

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

Answer 3

Я бы сказал, что прокси-сервер django на его собственный сервер действительно вступает в действие только в том случае, если вы работаете с mod_python, т. Е. Обслуживаете статические данные с помощью nginx и прокси-django для экземпляра apache, выполняющего mod_python. Я с удовольствием запускаю django в lighttpd через fastcgi с тем же lighttpd, обслуживающим и статический контент.

Answer 4

Я уверен, что можно настроить все динамическое и статическое содержимое в одном файле конфигурации с одним сервером nginx