Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 56
Неплохо, а нельзя имя проекта в переменную записать и вызывать скрипт с именем проекта, тогда и редактировать не надо будет вообще…
Не, это уже другой скрипт, цель же скрипта, описанного в публикации, настроить инфраструктуру для джанго-проектов, так сказать. Он создаёт шаблоны конфигов сайта для nginx, для supervisor. При желании можно отдельным скриптом, эти шаблоны использовать для создания нового сайта.
Про скрипт, который конфигуряет новый сайт я уже думал, но пока как-то проще ручками создавать новые сайты т.е. действий там не слишком много.
Про скрипт, который конфигуряет новый сайт я уже думал, но пока как-то проще ручками создавать новые сайты т.е. действий там не слишком много.
нехило… спасибо, пригодится
Хорошо, что дял этого придумали puppet
Если ничего не путаю, я недавно пытался понять эту штуку — ничо не понял и забил :) Как он вообще работает, в двух словах?
Есть клиент и сервер. Клиенты — твой ботнет, сервер — командный центр.
Как почти любая тулза для деплоймента. Пишете декларативный конфиг, в котором описано, что хотите получить, типа «установленные пакеты такие-то, созданные юзеры такие-то, распиханые конфиги туда-то».
Заливаете на нужные тачки, запускаете puppet, он пытается привести систему к описанному состоянию. При изменении конфига — puppet переконфигурирует, что нужно для достижения нового состояния. как-то так.
Заливаете на нужные тачки, запускаете puppet, он пытается привести систему к описанному состоянию. При изменении конфига — puppet переконфигурирует, что нужно для достижения нового состояния. как-то так.
Я не очень понимаю, чем puppet лучше моего решения. Моя специфика в том, что я работаю лишь с одной машиной и мне не нужно поддерживать её состояние в будущем, один раз только настроить. Потом каждая машина живёт своей жизнью. Например, потом мне надоест uwsgi и я решу поиграться с чем-то ещё, на навых машинах-проектах будет эта новая штука, а на старых uwsgi (по принципу работает — не трогай).
Было бы конечно очень интересно взглянуть на документ, который бы описал как сделать то же самое с помощью puppet, но лично я вполне счастлив с моим скриптом и у меня нет достаточного интереса разбираться с puppet.
Честно говоря, я не очень понимаю, чем конфиг puppet будет отличаться от моего скрипта, точно так же надо ему сказать, чтобы поставил то через aptitude, то через pip. В результате будет мой срикпт, только завёрнутый ещё в один слой. Ещё раз повторяю, специфика в том, что мне не нужно поддерживать конфигурацию на нескольких машинах в соотвествии с некоторым стандартом, мне вообще не нужно работать с несколькими машинами единовременно. Вы всё ещё думаете, что puppet был бы лучше в моём случае?
Было бы конечно очень интересно взглянуть на документ, который бы описал как сделать то же самое с помощью puppet, но лично я вполне счастлив с моим скриптом и у меня нет достаточного интереса разбираться с puppet.
Честно говоря, я не очень понимаю, чем конфиг puppet будет отличаться от моего скрипта, точно так же надо ему сказать, чтобы поставил то через aptitude, то через pip. В результате будет мой срикпт, только завёрнутый ещё в один слой. Ещё раз повторяю, специфика в том, что мне не нужно поддерживать конфигурацию на нескольких машинах в соотвествии с некоторым стандартом, мне вообще не нужно работать с несколькими машинами единовременно. Вы всё ещё думаете, что puppet был бы лучше в моём случае?
Если вы запустили скрипт, в том виде, как написал его я, то теперь у вас установлен nginx, postgres, supervisor, uwsgi, postgres.postgres забыли :)
А не было идеи реализовать тоже самое используя Puppet?
И откуда у всех «aptitude» в системе? Написали бы dependencies для своего скрипта.
Статья о том, как делать не нужно.
Статья о том, как делать не нужно.
Не нравится — не используйте. Я делюсь тем, что использую в данный момент. Если вам нравится подход, то замените aptitude на ваш пакетный менеджер. Если не нравится, то тогда вообще не понял, о чём вы говорите.
Статья не о том, как нужно или не нужно делать, статья о том, как делаю я :)
Статья не о том, как нужно или не нужно делать, статья о том, как делаю я :)
НапИшите статью как делать нужно?
А расскажите, что вы делаете фабриком на сервере?
тонкий намёк :)
Я попозже напишу публикацию, как использую fabric/virtualenv/pip для деплоинга джанго-проектов.
Вы их с сервера деплоите разве? Если нет, то на сервере фабрик не нужен %)
Ну, вообще я немножко извратился и делаю через фабрик всякие штуки локальные в основном :)
Вот пример из одного моего проекта: dumpz.org/57395/
Я fabric пока только-только изучаю, поэтому деплоинг у меня так-себе.
Вот пример из одного моего проекта: dumpz.org/57395/
Я fabric пока только-только изучаю, поэтому деплоинг у меня так-себе.
А я вот своим велосипедом пользуюсь. Умеет он гораздо больше, но расписывать здесь лень.
github.com/klen/makesite
github.com/klen/makesite
Вообще по-правильному надо бы пользоваться fabric. Но вот полноценных готовых не встречал.
Есть bitbucket.org/kmike/django-fab-deploy, но мне он категорически не нравится, в каждой мелочи.
Есть bitbucket.org/kmike/django-fab-deploy, но мне он категорически не нравится, в каждой мелочи.
Как именно воспользоваться fabric? Если просто запустить всё через fabric.api.run, то не вижу большой разницы :) Я ещё раз хочу подчеркнуть, этот скрипт не инструмент деплоинга джанго-сайтов, это базовая настройка VPS. Вообще я фабрик изучаю только первый месяц, но он мне сильно понравился.
а что особенно не нравится?
мне там тоже много что не нравится, но сайты не каждый день разворачиваешь
мне там тоже много что не нравится, но сайты не каждый день разворачиваешь
Ну я пока им пытался сайт развернуть, меня многое раздражало :)
С ходу — мне не нравится --no-site-packages у virtualenv. То есть опцию врубили, а потом в wsgi скрипте зацепляем и virtualenv, и site packages. Зато в немодифицированном manage.py у вас появляется проблема с доступом к системному MySQLdb при активированном окружении.
Я может конечно не очень глубоко вник, мне собственно надо было сервер запускать, может и упустил что.
С ходу — мне не нравится --no-site-packages у virtualenv. То есть опцию врубили, а потом в wsgi скрипте зацепляем и virtualenv, и site packages. Зато в немодифицированном manage.py у вас появляется проблема с доступом к системному MySQLdb при активированном окружении.
Я может конечно не очень глубоко вник, мне собственно надо было сервер запускать, может и упустил что.
wsgi — из вики к mod_wsgi взят, возможно, слишком давно (Graham где-то обновленный супер-правильный wsgi-скрипт для джанги выкладывал).
Но в wsgi-файле системный site-packages не специально зацепляется. Зацепляются как раз папки из virtualenv'а, и помещаются выше всего того, что в sys.path раньше было (а там был системный site-packages), т.к. процесс-то веб-сервера стартует без активированного virtualenv'а. Это как раз такой специальный wsgi-файл с поддержкой виртуаленвов без --no-site-packages ;) Угу, странно получилось. Т.е. ошибка тут не в том, что manage.py на mysqldb ругнулся, когда mysqldb не установлен, а в том, что wsgi не ругнулся, даже если --no-site-packages у виртуаленва стоит.
У меня обычно и локально, и на сервере везде --no-site-packages, и ставится все из одних и тех же файлов с зависимостями (+ доп. файлик для того, что только для разработки нужно), поэтому без установленного mysqldb все и локально падает (а упало — добавляю в зависимости просто нужный пакет) => обнаружить эту ошибку мог только чудом)
Интересный баг, добавил в трекер.
С --no-site-packages минус в том, что долго бывает, это да. Как раз из-за этого по умолчанию файлы с зависимостями на несколько предлагается разбить там, и часть обновлять более-менее регулярно и удобно, а часть (со всякими PIL и mysqldb) использовать только при первичной установке.
Насчет раздражителей — там за последнее время разные штуки еще поменялись как раз чтоб раздражать поменьше (работа через sudo без root'а — где можно, произвольная структура папок в проекте, зависимости одним файлом можно, пользователь БД — не root, немного мусора из push выкинуто и из других мест), может ощущения получше будут у людей, которые сейчас пробуют.
Но в wsgi-файле системный site-packages не специально зацепляется. Зацепляются как раз папки из virtualenv'а, и помещаются выше всего того, что в sys.path раньше было (а там был системный site-packages), т.к. процесс-то веб-сервера стартует без активированного virtualenv'а. Это как раз такой специальный wsgi-файл с поддержкой виртуаленвов без --no-site-packages ;) Угу, странно получилось. Т.е. ошибка тут не в том, что manage.py на mysqldb ругнулся, когда mysqldb не установлен, а в том, что wsgi не ругнулся, даже если --no-site-packages у виртуаленва стоит.
У меня обычно и локально, и на сервере везде --no-site-packages, и ставится все из одних и тех же файлов с зависимостями (+ доп. файлик для того, что только для разработки нужно), поэтому без установленного mysqldb все и локально падает (а упало — добавляю в зависимости просто нужный пакет) => обнаружить эту ошибку мог только чудом)
Интересный баг, добавил в трекер.
С --no-site-packages минус в том, что долго бывает, это да. Как раз из-за этого по умолчанию файлы с зависимостями на несколько предлагается разбить там, и часть обновлять более-менее регулярно и удобно, а часть (со всякими PIL и mysqldb) использовать только при первичной установке.
Насчет раздражителей — там за последнее время разные штуки еще поменялись как раз чтоб раздражать поменьше (работа через sudo без root'а — где можно, произвольная структура папок в проекте, зависимости одним файлом можно, пользователь БД — не root, немного мусора из push выкинуто и из других мест), может ощущения получше будут у людей, которые сейчас пробуют.
Я кстати так и не понял, зачем --no-site-packages? С этой опцией мы теряем пакетную базу дистрибутива, а бонусов не получаем. То есть в каких то случаях это может быть и нужно, при особом сочетании пакетов для редкого проекта, но в остальном только мешает. Приходится на продакт сервер ставить gcc и остальную плеяду бесполезных там штук, типа всяких *-dev.
Кстати что нравится, так это пуш — не люблю когда на сервер пуллят из центрального репо — тогда всем серверам к нему надо доступ давать.
Кстати что нравится, так это пуш — не люблю когда на сервер пуллят из центрального репо — тогда всем серверам к нему надо доступ давать.
Бонус с --no-site-packages в том, что всегда понятно, какое у проекта окружение, и будет явно выводиться ошибка, если чего-то нет (а не использоваться, например, устаревшая версия из репозитория — что вполне актуально для lenny может быть). Системные пакеты с заголовками все равно для многих полупитоньих пакетов нужны, а плеяду бесполезных штук django-fab-deploy ставит в самом начале.
Я не то чтобы уж очень за --no-site-packages, но на практике из минусов только установку долгую замечал — зато меньше неявных проблем, когда у одного разработчика работает, у другого не работает, на сервере работает, но со скрытой ошибкой и тд. Когда все зависимости явно прописаны (например, не python-beautifulsoup, который 3.0 в lenny, жуткий 3.1 в squeeze и непонятно какой ставить локально и откуда узнать, что его вообще ставить нужно, а BeautifulSoup==3.2), такое бывает реже.
Практических проблем вроде не так много ни с тем, ни с другим вариантом, думаю, вопрос больше идеологический — мне как-то проще, когда точно знаю, какое питонье окружение у проекта, и это явно где-то записано (не надо, например, аналоги дебиановских пакетов искать в macports или pypi).
Я не то чтобы уж очень за --no-site-packages, но на практике из минусов только установку долгую замечал — зато меньше неявных проблем, когда у одного разработчика работает, у другого не работает, на сервере работает, но со скрытой ошибкой и тд. Когда все зависимости явно прописаны (например, не python-beautifulsoup, который 3.0 в lenny, жуткий 3.1 в squeeze и непонятно какой ставить локально и откуда узнать, что его вообще ставить нужно, а BeautifulSoup==3.2), такое бывает реже.
Практических проблем вроде не так много ни с тем, ни с другим вариантом, думаю, вопрос больше идеологический — мне как-то проще, когда точно знаю, какое питонье окружение у проекта, и это явно где-то записано (не надо, например, аналоги дебиановских пакетов искать в macports или pypi).
Спасибо. Давно хочу попробовать django в действии.
Тихо заменить пользователю дефолтный редактор? Отлииично…
Добро пожаловать в академию пакостей ;)
Добро пожаловать в академию пакостей ;)
Какой конфигурации vds нужен для небольшого django проекта?
Обновите, пожалуйста, джангу до 1.3, познайте staticfiles и уберите вот этот ужас:
location /static/admin-media {
alias /web/PROJECT/var/.env/lib/python2.6/site-packages/django/contrib/admin/media;
}
location /static/admin-media {
alias /web/PROJECT/var/.env/lib/python2.6/site-packages/django/contrib/admin/media;
}
Если вам часто приходится настраивать именно VPS, то проще сделать шаблон со своими изменениями (если, конечно, есть возможность разворачивать контейнеры из своего шаблона)
Хороший скрипт, спасибо. При следующей настройке наверное использую его как основу для своего.
У меня сейчас 2 сервера настроены схожим образом. Из всего что я пробовал связка Nginx+uWSGI + следящий supervisor мне больше всех пришлась по душе.
И еще, забавная опечатка:
restop, что-то есть в этой команде ))
У меня сейчас 2 сервера настроены схожим образом. Из всего что я пробовал связка Nginx+uWSGI + следящий supervisor мне больше всех пришлась по душе.
И еще, забавная опечатка:
/etc/init.d/supervisor restoprestop, что-то есть в этой команде ))
Большое спасибо, очень полезно!
Интересно, спасибо! Мне кажется такое лучше выкатить на github/bitbucket чтоб люди могли форкать спокойно на здоровье и апдейтить по мере необходимости
Спасибо за топик. Как раз искал.
Будет о чём почитать на досуге!
Будет о чём почитать на досуге!
после выполнения команды
у вас все подпроцессы uwsgi киляются?
/etc/init.d/supervisor stop у вас все подпроцессы uwsgi киляются?
Не знаю, я уже несколько месяцев как перешёл на голый uwsgi :) Т.е. у меня только nginx + uwsgi-демоно в imperor mode, supervisor я выкинул.
почему перешли? вариант существенно выигрывает по производительности?
Просто эксперементирую. К тому же у меня были глюки с supervisor, какие-то процессы лишние в памяти оставались. Я подумал, чем разбираться, что к чему, выкину его вообще, ибо uwsgi и так работает отлично.
По поводу производительности, я думаю, одинаково, что с supervisor, что без — и там и там работает в итоге uwsgi-демон-сайта.
По поводу производительности, я думаю, одинаково, что с supervisor, что без — и там и там работает в итоге uwsgi-демон-сайта.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка сервера для django-проектов с нуля