Комментарии 56
Неплохо, а нельзя имя проекта в переменную записать и вызывать скрипт с именем проекта, тогда и редактировать не надо будет вообще…
+2
Не, это уже другой скрипт, цель же скрипта, описанного в публикации, настроить инфраструктуру для джанго-проектов, так сказать. Он создаёт шаблоны конфигов сайта для nginx, для supervisor. При желании можно отдельным скриптом, эти шаблоны использовать для создания нового сайта.
Про скрипт, который конфигуряет новый сайт я уже думал, но пока как-то проще ручками создавать новые сайты т.е. действий там не слишком много.
Про скрипт, который конфигуряет новый сайт я уже думал, но пока как-то проще ручками создавать новые сайты т.е. действий там не слишком много.
+1
нехило… спасибо, пригодится
0
Хорошо, что дял этого придумали puppet
+3
Если ничего не путаю, я недавно пытался понять эту штуку — ничо не понял и забил :) Как он вообще работает, в двух словах?
0
Есть клиент и сервер. Клиенты — твой ботнет, сервер — командный центр.
+1
Как почти любая тулза для деплоймента. Пишете декларативный конфиг, в котором описано, что хотите получить, типа «установленные пакеты такие-то, созданные юзеры такие-то, распиханые конфиги туда-то».
Заливаете на нужные тачки, запускаете puppet, он пытается привести систему к описанному состоянию. При изменении конфига — puppet переконфигурирует, что нужно для достижения нового состояния. как-то так.
Заливаете на нужные тачки, запускаете puppet, он пытается привести систему к описанному состоянию. При изменении конфига — puppet переконфигурирует, что нужно для достижения нового состояния. как-то так.
+1
Я не очень понимаю, чем puppet лучше моего решения. Моя специфика в том, что я работаю лишь с одной машиной и мне не нужно поддерживать её состояние в будущем, один раз только настроить. Потом каждая машина живёт своей жизнью. Например, потом мне надоест uwsgi и я решу поиграться с чем-то ещё, на навых машинах-проектах будет эта новая штука, а на старых uwsgi (по принципу работает — не трогай).
Было бы конечно очень интересно взглянуть на документ, который бы описал как сделать то же самое с помощью puppet, но лично я вполне счастлив с моим скриптом и у меня нет достаточного интереса разбираться с puppet.
Честно говоря, я не очень понимаю, чем конфиг puppet будет отличаться от моего скрипта, точно так же надо ему сказать, чтобы поставил то через aptitude, то через pip. В результате будет мой срикпт, только завёрнутый ещё в один слой. Ещё раз повторяю, специфика в том, что мне не нужно поддерживать конфигурацию на нескольких машинах в соотвествии с некоторым стандартом, мне вообще не нужно работать с несколькими машинами единовременно. Вы всё ещё думаете, что puppet был бы лучше в моём случае?
Было бы конечно очень интересно взглянуть на документ, который бы описал как сделать то же самое с помощью puppet, но лично я вполне счастлив с моим скриптом и у меня нет достаточного интереса разбираться с puppet.
Честно говоря, я не очень понимаю, чем конфиг puppet будет отличаться от моего скрипта, точно так же надо ему сказать, чтобы поставил то через aptitude, то через pip. В результате будет мой срикпт, только завёрнутый ещё в один слой. Ещё раз повторяю, специфика в том, что мне не нужно поддерживать конфигурацию на нескольких машинах в соотвествии с некоторым стандартом, мне вообще не нужно работать с несколькими машинами единовременно. Вы всё ещё думаете, что puppet был бы лучше в моём случае?
+1
Если вы запустили скрипт, в том виде, как написал его я, то теперь у вас установлен nginx, postgres, supervisor, uwsgi, postgres.postgres забыли :)
0
А не было идеи реализовать тоже самое используя Puppet?
0
И откуда у всех «aptitude» в системе? Написали бы dependencies для своего скрипта.
Статья о том, как делать не нужно.
Статья о том, как делать не нужно.
0
Не нравится — не используйте. Я делюсь тем, что использую в данный момент. Если вам нравится подход, то замените aptitude на ваш пакетный менеджер. Если не нравится, то тогда вообще не понял, о чём вы говорите.
Статья не о том, как нужно или не нужно делать, статья о том, как делаю я :)
Статья не о том, как нужно или не нужно делать, статья о том, как делаю я :)
+2
НапИшите статью как делать нужно?
+1
А расскажите, что вы делаете фабриком на сервере?
+2
тонкий намёк :)
0
Я попозже напишу публикацию, как использую fabric/virtualenv/pip для деплоинга джанго-проектов.
0
Вы их с сервера деплоите разве? Если нет, то на сервере фабрик не нужен %)
+1
Ну, вообще я немножко извратился и делаю через фабрик всякие штуки локальные в основном :)
Вот пример из одного моего проекта: dumpz.org/57395/
Я fabric пока только-только изучаю, поэтому деплоинг у меня так-себе.
Вот пример из одного моего проекта: dumpz.org/57395/
Я fabric пока только-только изучаю, поэтому деплоинг у меня так-себе.
0
А я вот своим велосипедом пользуюсь. Умеет он гораздо больше, но расписывать здесь лень.
github.com/klen/makesite
github.com/klen/makesite
+1
Поправьте, но мне показалось, что ваш скрипт не установит nginx, БД, python, pip и т. п. То есть он должен работать после того как отработает сабж топика.
0
Вообще по-правильному надо бы пользоваться fabric. Но вот полноценных готовых не встречал.
Есть bitbucket.org/kmike/django-fab-deploy, но мне он категорически не нравится, в каждой мелочи.
Есть bitbucket.org/kmike/django-fab-deploy, но мне он категорически не нравится, в каждой мелочи.
0
Как именно воспользоваться fabric? Если просто запустить всё через fabric.api.run, то не вижу большой разницы :) Я ещё раз хочу подчеркнуть, этот скрипт не инструмент деплоинга джанго-сайтов, это базовая настройка VPS. Вообще я фабрик изучаю только первый месяц, но он мне сильно понравился.
0
а что особенно не нравится?
мне там тоже много что не нравится, но сайты не каждый день разворачиваешь
мне там тоже много что не нравится, но сайты не каждый день разворачиваешь
+1
Ну я пока им пытался сайт развернуть, меня многое раздражало :)
С ходу — мне не нравится --no-site-packages у virtualenv. То есть опцию врубили, а потом в wsgi скрипте зацепляем и virtualenv, и site packages. Зато в немодифицированном manage.py у вас появляется проблема с доступом к системному MySQLdb при активированном окружении.
Я может конечно не очень глубоко вник, мне собственно надо было сервер запускать, может и упустил что.
С ходу — мне не нравится --no-site-packages у virtualenv. То есть опцию врубили, а потом в wsgi скрипте зацепляем и virtualenv, и site packages. Зато в немодифицированном manage.py у вас появляется проблема с доступом к системному MySQLdb при активированном окружении.
Я может конечно не очень глубоко вник, мне собственно надо было сервер запускать, может и упустил что.
0
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 выкинуто и из других мест), может ощущения получше будут у людей, которые сейчас пробуют.
0
Я кстати так и не понял, зачем --no-site-packages? С этой опцией мы теряем пакетную базу дистрибутива, а бонусов не получаем. То есть в каких то случаях это может быть и нужно, при особом сочетании пакетов для редкого проекта, но в остальном только мешает. Приходится на продакт сервер ставить gcc и остальную плеяду бесполезных там штук, типа всяких *-dev.
Кстати что нравится, так это пуш — не люблю когда на сервер пуллят из центрального репо — тогда всем серверам к нему надо доступ давать.
Кстати что нравится, так это пуш — не люблю когда на сервер пуллят из центрального репо — тогда всем серверам к нему надо доступ давать.
0
Бонус с --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).
+1
Спасибо. Давно хочу попробовать django в действии.
0
Тихо заменить пользователю дефолтный редактор? Отлииично…
Добро пожаловать в академию пакостей ;)
Добро пожаловать в академию пакостей ;)
+1
Какой конфигурации vds нужен для небольшого django проекта?
0
Обновите, пожалуйста, джангу до 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;
}
+2
Ок, вы меня заинтриговали. Джанго, конечно, 1.3 Просто не успеваю следить за всеми фичами т.к. и без них всё работает.
0
а разве когда мы отдаем статику нджинксом напрямую, то не получаем прирост скорости?
0
Если вам часто приходится настраивать именно VPS, то проще сделать шаблон со своими изменениями (если, конечно, есть возможность разворачивать контейнеры из своего шаблона)
0
Хороший скрипт, спасибо. При следующей настройке наверное использую его как основу для своего.
У меня сейчас 2 сервера настроены схожим образом. Из всего что я пробовал связка Nginx+uWSGI + следящий supervisor мне больше всех пришлась по душе.
И еще, забавная опечатка:
restop, что-то есть в этой команде ))
У меня сейчас 2 сервера настроены схожим образом. Из всего что я пробовал связка Nginx+uWSGI + следящий supervisor мне больше всех пришлась по душе.
И еще, забавная опечатка:
/etc/init.d/supervisor restop
restop, что-то есть в этой команде ))
+1
Большое спасибо, очень полезно!
0
Интересно, спасибо! Мне кажется такое лучше выкатить на github/bitbucket чтоб люди могли форкать спокойно на здоровье и апдейтить по мере необходимости
+1
Спасибо за топик. Как раз искал.
Будет о чём почитать на досуге!
Будет о чём почитать на досуге!
0
после выполнения команды
у вас все подпроцессы uwsgi киляются?
/etc/init.d/supervisor stop
у вас все подпроцессы uwsgi киляются?
0
Не знаю, я уже несколько месяцев как перешёл на голый uwsgi :) Т.е. у меня только nginx + uwsgi-демоно в imperor mode, supervisor я выкинул.
0
почему перешли? вариант существенно выигрывает по производительности?
0
Просто эксперементирую. К тому же у меня были глюки с supervisor, какие-то процессы лишние в памяти оставались. Я подумал, чем разбираться, что к чему, выкину его вообще, ибо uwsgi и так работает отлично.
По поводу производительности, я думаю, одинаково, что с supervisor, что без — и там и там работает в итоге uwsgi-демон-сайта.
По поводу производительности, я думаю, одинаково, что с supervisor, что без — и там и там работает в итоге uwsgi-демон-сайта.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка сервера для django-проектов с нуля