Comments 41
Убунту можно и 12.04 использовать, она ведь ЛТС
Можно, но как я понял, сейчас, у хостера она поставляется не с родной версией ядра, что рождает много рисков.
И раз зашел разговор, я об этом писал в топике:
И раз зашел разговор, я об этом писал в топике:
Доступна также и Ubuntu Server 12.04 LTS, мне без особого труда удалось ввести ее в строй, однако шаблон на хостинге появился недавно, да и специалисты поддержки хостинг-провайдера не рекомендуют пока ее ставить на боевые сервера. Сейчас использую ее только на тестовом сервере.
Теперь отключаем возможность пользователю root логиниться по SSH (делать необязательно, мера безопасности)
Если не секрет, какую именно безопасность обеспечивает данная мера? Увеличивает количество попыток подбора пары логин+пароль с бесконечного до бесконечного?
Если не запрещать подключение по SSH от root, количество попыток подбора пары «логин+пароль» снижается до количества подборок пароля, и весьма наивно полагать, что оно равняется бесконечности. Кроме того, если будет найдена уязвимость в ssh-сервере или связанных с ним библиотеках, позволяющая, скажем, заходить без пароля, то будет несоизмеримо лучше, если никто не сможет провернуть этот фокус от рута. Безопасность должна быть эшелонированной.
А почему именно gunicorn, а не, скажем, uwsgi?
В зависимостях лучше всегда указывать версии (причем даже ==, а не >= или <=) и коммиты в git-репозиториях. Сначала кажется, что это не очень важно, что вроде следишь за обновлениями и поправишь код, если что. Но когда через год проект перестает работать из-за того, что какой-то там пакет обновился, половина программистов, которые над кодом работали, занята чем-то другим, а другая уже и не помнит, о чем там речь была… Короче, лишняя ненужная работа получается.
supervisord еще можно в виртуаленв ставить (pip install supervisord): если на сервере несколько проектов, то у каждого будет свой supervisord, и sudo не нужно будет дергать для перезапуска.
supervisord еще можно в виртуаленв ставить (pip install supervisord): если на сервере несколько проектов, то у каждого будет свой supervisord, и sudo не нужно будет дергать для перезапуска.
kmike, спасибо, за конструктивную критику, у меня стояла задача поддержать версионность пакетов, но из-за приоритетов так и не добрался до нее. Кстати, задача должна решаться просто, так как pip, с некоторых пор научили выдавать в том же формате список зависимостей с указанием версий.
pip freeze — да, но там разные «но» есть (с -e пакетами freeze может не справиться + после pip install -U уже не выяснить правильные зависимости). Проще сразу версии указывать явно, и обновления версий в VCS фиксировать (т.к. версии сторонних пакетов, по сути, тоже ведь код проекта определяют). Это не критика, дополнения просто, описано все хорошо.
Интересно узнать чем хорош gunicorn, сейчас я использую для подобных целей tornado, который так же запускает django проекты.
Но при этом в моей связке есть особенность, при который торнадо перестаёт отвечать, но не падает и supervisor не перезагружает его. Может gunicorn мне подойдёт.
Но при этом в моей связке есть особенность, при который торнадо перестаёт отвечать, но не падает и supervisor не перезагружает его. Может gunicorn мне подойдёт.
Двум предыдущим отвечу: uwsgi не страдает (за 2 года не заметил) проблемами «перестаёт отвечать», а для перезапуска (в режиме императора) достаточно сделать touch конфига.
projects.unbit.it/uwsgi/wiki/Emperor
projects.unbit.it/uwsgi/wiki/Emperor
Чем Nginx + FastCGI не угодил?)
Он имеет право на жизнь, как все остальные способы развертывания Django-приложений. В статье не утверждается что мой способ самый лучший.
Странно, что совершенно безобидный вопрос по теме заминусовали. К тому же, я кажется нигде и не затграгивал тему единственно верных решений.
Хотелось узнать почему вы выбрали именно такой спсобо для развертывания Django-приложений, но увы.
Хотелось узнать почему вы выбрали именно такой спсобо для развертывания Django-приложений, но увы.
Поставил минус, объясню почему. Каждое обсуждение способа развертывания питоньих проектов неизбежно скатывается в fastcgi vs uwsgi vs gunicorn vs apache mod_wsgi vs ..., как будто этот вопрос имеет хоть какое-то значение. Ну да, они все немного отличаются друг от друга по фичам и по способу настройки, но они не сделают магическим образом сайт быстрее или надежнее.
Значение имеет не набора букв в описании веб-стека, а то, как все настроено; чтоб все настроить хорошо, нужно понимание того, как все работает, и того, чего же хочется получить-то. Интернетные советы «uwsgi быстрее mod_wsgi», как мне кажется, от этого понимания отдаляют, а не приближают — вместо того, чтоб разобраться в проблеме, люди начинают верить в наборы букв (иногда еще обосновывая свою веру идиотскими бенчмарками хелло-вордов).
Кстати, мне кажется (судя по тому, что коммент про uwsgi заплюсован), что еще вам минусов понаставили из-за того, что в конкретный набор букв (fastcgi) не верят.
Значение имеет не набора букв в описании веб-стека, а то, как все настроено; чтоб все настроить хорошо, нужно понимание того, как все работает, и того, чего же хочется получить-то. Интернетные советы «uwsgi быстрее mod_wsgi», как мне кажется, от этого понимания отдаляют, а не приближают — вместо того, чтоб разобраться в проблеме, люди начинают верить в наборы букв (иногда еще обосновывая свою веру идиотскими бенчмарками хелло-вордов).
Кстати, мне кажется (судя по тому, что коммент про uwsgi заплюсован), что еще вам минусов понаставили из-за того, что в конкретный набор букв (fastcgi) не верят.
Интересно насчет хостинга FirstVDS, который вы рекомендуете.
Он сильно дешевле других. Не страдает ли качество?
Он сильно дешевле других. Не страдает ли качество?
Хочется отдельно сказать спасибо автору за краткое и емкое вступление, за оглавление и четкую структуру статьи.
Присоединяюсь к отзыву о FirstVDS — тоже был приятно удивлён пол года назад.
По теме статьи:
* Вы указали fabric в зависимостях, так где же fabfile? Зачем какие то build_env.sh когда есть fabric?
* В зависимостях у Вас south, значит что нужно делать syncdb с миграциями
Из полезного по теме развёртывания и не только могу проделожить ознакомиться с lincolnloop.com/django-best-practices/ и с их темплейтным Django-проектом
github.com/lincolnloop/django-layout. Про деплой — обратите внимание на их fabfile. «Лучше день потерять, а потом за пять минут долететь» (с)
Мы для себя этот шаблонный проект несколько переосмыслили, добавили туда HTML5 Boilerplate сразу скрещенный с Bootstrap, ещё немного перчику — и получился приличный шаблон для быстрого старта.
По теме статьи:
* Вы указали 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, ещё немного перчику — и получился приличный шаблон для быстрого старта.
уже ненужно.
теперь
manage.py syncdb (sync для тех app, где нет south и проверка south что вобще делать собираемся)
manage.py migrate (собсно migrate для south)
теперь
manage.py syncdb (sync для тех app, где нет south и проверка south что вобще делать собираемся)
manage.py migrate (собсно migrate для south)
fabric — отдельная тема, активно используем, напишу, если время найдется.
по поводу south — у нас применяется ряд мер, в том числе, по залитию дампа базы, по syncdb домыслил, уточню, спасибо.
по поводу south — у нас применяется ряд мер, в том числе, по залитию дампа базы, по syncdb домыслил, уточню, спасибо.
Спасибо тебе, добрый человек, за ссылки.
как раз таки нужно
команда
syncdb --migrate
выполняет syncdb у приложений, которые не по south и migrate у тех, которые под south
команда
syncdb --migrate
выполняет syncdb у приложений, которые не по south и migrate у тех, которые под south
Время идёт, а статья актуальна
Sign up to leave a comment.
Боевой сервер для Django-приложения: Ubuntu Server 10.04 LTS + django 1.4 + nginx + gunicorn