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