Разные способы развертывания проекта Django и их плюсы и минусы?

Question

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

Answer 1

В документации Django перечислены Apache / mod_wsgi, Apache / mod_python и FastCGI и т. Д.

mod_python устарело, вместо этого следует использовать mod_wsgi.

Django с mod_wsgi прост в настройке, но:

• вы можете использовать только одну версию Python за раз [править: вы даже можете использовать толькоPython версия mod_wsgi была скомпилирована для]
• [править: кажется, что я не прав на mod_wsgi, не поддерживающем virtualenv: так и есть]

Так для нескольких сайтов (нацеленных на разные django / pythonверсии) на сервере mod_wsgi - не лучшее решение.

FastCGI может использоваться с virtualenv, также с различными версиями Python, так как вы запускаете его с

./manage.py runfcgi …

а затем настройте свой веб-сервер на использование этого интерфейса fcgi.

По-видимому, новым, горячим материалом о развертывании django является gunicorn .Это веб-сервер, который реализует wsgi и обычно используется как серверная часть с «большим» веб-сервером в качестве прокси.

Развертывание с gunicorn очень похоже на fcgi: вы запускаете процесс, выполняющий обработку djangoчто-то вроде manage.py и веб-сервера в качестве внешнего интерфейса к миру.

Но развертывание gunicorn имеет некоторые преимущества перед fcgi:

• speed - я не нашел источники, ноТесты производительности говорят, что fcgi не так быстр, как f предлагает
• файлы конфигурации, для fcgi вы должны выполнить всю настройку в командной строке при выполнении команды manage.py.Это не удобно при запуске нескольких экземпляров django через init.d (запуск системной службы unix-like OS).Это всегда одна и та же командная строка с просто разными конфигурационными файлами
• gunicorn может отбросить привилегии: нет необходимости делать это в вашем скрипте init.d, и легко переключиться на одного пользователя на экземпляр django
• gunicorn ведет себя больше как демон: написание pidfile и logfile, разветвление на задний план и т. д. упрощает использование его в сценарии init.d.

Таким образом, я бы предложил использовать решение gunicornЕсли у вас нет одного сайта на одном сервере с низким трафиком, вы можете использовать решение wsgi.Но я думаю, что в конечном итоге вы будете более довольны Gunicorn.

Если у вас есть веб-сервер только с django, я бы предложил использовать nginx в качестве frontendproxy, так как он наиболее эффективен (опять же, это основано на тестахЯ читал в некоторых блогах - у меня больше нет URL).Лично я использую apache в качестве frontendproxy, так как он мне нужен для других сайтов, размещенных на сервере.

Простую инструкцию по установке для развертывания django можно найти здесь: http://ericholscher.com/blog/2010/aug/16/lessons-learned-dash-easy-django-deployment/

Мой init.dскрипт для gunicorn находится на github: https://gist.github.com/753053

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

Answer 2

Используйте Nginx / Apache / mod-wsgi, и вы не ошибетесь.

Если вы предпочитаете простую альтернативу, просто используйте Apache.

Существует очень хороший документ по развертыванию: http://lethain.com/entry/2009/feb/13/the-django-and-ubuntu-intrepid-almanac/

Answer 3

Я сам столкнулся с множеством проблем при развертывании Django Projects и автоматизации процесса развертывания.Apache и mod_wsgi были как проклятие для Django Deployment.Существует несколько инструментов, таких как Nginx , Gunicorn , SupervisorD и Fabric, которые используются для развертывания Django.Сначала я использовал / настраивал их по отдельности без автоматизации развертывания, что занимало много времени (мне приходилось поддерживать тестирование, а также рабочие серверы для моего клиента и обновлять их, как только новая функция была протестирована и одобрена). Но затемЯ наткнулся на django-fagungis, который полностью автоматизирует мое Django Deployment от клонирования моего проекта от bitbucket до развертывания на моем удаленном сервере (он использует Nginx, Gunicorn, SupervisorD, Fabtic и virtualenv, а также устанавливает все зависимости на лету), все столько три команды :) Вы можете найти больше об этом в моем блоге здесь .Теперь мне даже не нужно вмешиваться в этот процесс (который раньше занимал у меня много времени), и один из моих младших разработчиков запускает эти три команды django-fagungis , упомянутые здесь , на своей локальной машинеи мы получаем четкую новую копию нашего проекта, развернутую в считанные минуты без каких-либо хлопот:)