Боевой сервер для Django-приложения: Ubuntu Server 10.04 LTS + django 1.4 + nginx + gunicorn

[peanut]

Убунту можно и 12.04 использовать, она ведь ЛТС

[arezvov]

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

Доступна также и Ubuntu Server 12.04 LTS, мне без особого труда удалось ввести ее в строй, однако шаблон на хостинге появился недавно, да и специалисты поддержки хостинг-провайдера не рекомендуют пока ее ставить на боевые сервера. Сейчас использую ее только на тестовом сервере.

[grigoryvp]

Теперь отключаем возможность пользователю root логиниться по SSH (делать необязательно, мера безопасности)

Если не секрет, какую именно безопасность обеспечивает данная мера? Увеличивает количество попыток подбора пары логин+пароль с бесконечного до бесконечного?

[justabaka]

Если не запрещать подключение по SSH от root, количество попыток подбора пары «логин+пароль» снижается до количества подборок пароля, и весьма наивно полагать, что оно равняется бесконечности. Кроме того, если будет найдена уязвимость в ssh-сервере или связанных с ним библиотеках, позволяющая, скажем, заходить без пароля, то будет несоизмеримо лучше, если никто не сможет провернуть этот фокус от рута. Безопасность должна быть эшелонированной.

[jj_killer]

Ну раз эшелонированной, тогда myuser ALL=(ALL:ALL) ALL это уж слишком просторно.

[justabaka]

Да, некрасиво, но это уже вопрос к автору.

[arezvov]

Да, думаю, что это недоработка. При разработке своего рецепта я исходил из опыта, пытаясь решить 80% проблем за 20% усилий.

[grigoryvp]

С заходом без пароля забыл, спасибо.

[kmike]

А не лучше отключить вход по паролю через SSH совсем (и для рута, и для пользователей)? SSH с ключами и удобнее, и безопаснее.

[justabaka]

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

[garex]

И ключи не простые а с паролями

[dgeliko]

Если уж пошел разговор о безопасности — то надо использовать еще до кучи и knockd с нестандартными портами и тайм-аутами, но в рамках статьи это, ИМХО, избыточно уже.

[mkal]

А почему именно gunicorn, а не, скажем, uwsgi?

[overmes]

или mod_wsgi или cherrype или…
Это тема для отдельной статьи

Пробовал как-то apache mod_wsgi vs nginx uwsgi на своем не большом проекте — разницы не было, поэтому оставил apache

[arezvov]

Видимо ответ тот же — личные предпочтения.

[kmike]

В зависимостях лучше всегда указывать версии (причем даже ==, а не >= или <=) и коммиты в git-репозиториях. Сначала кажется, что это не очень важно, что вроде следишь за обновлениями и поправишь код, если что. Но когда через год проект перестает работать из-за того, что какой-то там пакет обновился, половина программистов, которые над кодом работали, занята чем-то другим, а другая уже и не помнит, о чем там речь была… Короче, лишняя ненужная работа получается.

supervisord еще можно в виртуаленв ставить (pip install supervisord): если на сервере несколько проектов, то у каждого будет свой supervisord, и sudo не нужно будет дергать для перезапуска.

[arezvov]

kmike, спасибо, за конструктивную критику, у меня стояла задача поддержать версионность пакетов, но из-за приоритетов так и не добрался до нее. Кстати, задача должна решаться просто, так как pip, с некоторых пор научили выдавать в том же формате список зависимостей с указанием версий.

[kmike]

pip freeze — да, но там разные «но» есть (с -e пакетами freeze может не справиться + после pip install -U уже не выяснить правильные зависимости). Проще сразу версии указывать явно, и обновления версий в VCS фиксировать (т.к. версии сторонних пакетов, по сути, тоже ведь код проекта определяют). Это не критика, дополнения просто, описано все хорошо.

[rushter]

Интересно узнать чем хорош gunicorn, сейчас я использую для подобных целей tornado, который так же запускает django проекты.
Но при этом в моей связке есть особенность, при который торнадо перестаёт отвечать, но не падает и supervisor не перезагружает его. Может gunicorn мне подойдёт.

[arezvov]

Не пробовал tornado, вполне возможно, что проект хорош. Мне проект gunicorn нравится за счет того, что был портирован из зарекомендовавшего себя unicorn из мира ROR. Если приложение виснет — смотрите логи.

[AgaFonOff]

Двум предыдущим отвечу: uwsgi не страдает (за 2 года не заметил) проблемами «перестаёт отвечать», а для перезапуска (в режиме императора) достаточно сделать touch конфига.
projects.unbit.it/uwsgi/wiki/Emperor

[gasya]

Чем Nginx + FastCGI не угодил?)

[arezvov]

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

[gasya]

Странно, что совершенно безобидный вопрос по теме заминусовали. К тому же, я кажется нигде и не затграгивал тему единственно верных решений.

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

[kmike]

Поставил минус, объясню почему. Каждое обсуждение способа развертывания питоньих проектов неизбежно скатывается в fastcgi vs uwsgi vs gunicorn vs apache mod_wsgi vs ..., как будто этот вопрос имеет хоть какое-то значение. Ну да, они все немного отличаются друг от друга по фичам и по способу настройки, но они не сделают магическим образом сайт быстрее или надежнее.

Значение имеет не набора букв в описании веб-стека, а то, как все настроено; чтоб все настроить хорошо, нужно понимание того, как все работает, и того, чего же хочется получить-то. Интернетные советы «uwsgi быстрее mod_wsgi», как мне кажется, от этого понимания отдаляют, а не приближают — вместо того, чтоб разобраться в проблеме, люди начинают верить в наборы букв (иногда еще обосновывая свою веру идиотскими бенчмарками хелло-вордов).

Кстати, мне кажется (судя по тому, что коммент про uwsgi заплюсован), что еще вам минусов понаставили из-за того, что в конкретный набор букв (fastcgi) не верят.

[gasya]

Другое дело. Спасибо.

[blackstone]

Интересно насчет хостинга FirstVDS, который вы рекомендуете.
Он сильно дешевле других. Не страдает ли качество?

[ajaxtelamonid]

Года три назад очень страдало.

[arezvov]

Сейчас работает два приносящих прибыль интернет-магазина. Не жалуемся на хостера уже пару лет.

[B7W]

Хочется отдельно сказать спасибо автору за краткое и емкое вступление, за оглавление и четкую структуру статьи.

[arezvov]

Спасибо, я старался сделать статью полезной.

[habrsa]

Присоединяюсь к отзыву о FirstVDS — тоже был приятно удивлён пол года назад.

По теме статьи:
* Вы указали fabric в зависимостях, так где же fabfile? Зачем какие то build_env.sh когда есть fabric?
* В зависимостях у Вас south, значит что нужно делать syncdb с миграциями

python manage.py syncdb --migrate

Из полезного по теме развёртывания и не только могу проделожить ознакомиться с lincolnloop.com/django-best-practices/ и с их темплейтным Django-проектом
github.com/lincolnloop/django-layout. Про деплой — обратите внимание на их fabfile. «Лучше день потерять, а потом за пять минут долететь» (с)

Мы для себя этот шаблонный проект несколько переосмыслили, добавили туда HTML5 Boilerplate сразу скрещенный с Bootstrap, ещё немного перчику — и получился приличный шаблон для быстрого старта.

[kamiram]

уже ненужно.
теперь

manage.py syncdb (sync для тех app, где нет south и проверка south что вобще делать собираемся)
manage.py migrate (собсно migrate для south)

[arezvov]

fabric — отдельная тема, активно используем, напишу, если время найдется.
по поводу south — у нас применяется ряд мер, в том числе, по залитию дампа базы, по syncdb домыслил, уточню, спасибо.

[UdarEC]

Спасибо тебе, добрый человек, за ссылки.

[habrsa]

как раз таки нужно
команда
syncdb --migrate
выполняет syncdb у приложений, которые не по south и migrate у тех, которые под south

[vinograd19]

Время идёт, а статья актуальна

[arezvov]

Спасибо, рад если помог вам.

[SergeyD]

Спасибо вам, статья всё еще актуальна.

[arezvov]

Спасибо, рад, конечно, что статья еще помогает, но с тех пор закрепились Ansible, Docker, Амазон предлагает вообще забыть о том как запускать веб-приложения.

Статья перешла в раздел «интересно сделать самому», в реальных приложениях сегодня делают по-другому.

[776166]

Не актуальна. Надо пользоваться системой управления конфигурациями.