Космическая Змея в Магазине или Как Мы «CheeseShop» Ставили

[marazmiki]

Скажите, а почему Вы не использовали Fabric? Всё-таки более питоничное решение

[marklarius]

Руки не дошли да и времени не хватало толком разобратся — хотелось закончить процесс с минимумом «левых» зависимостей. В будущем будем использовать Fabric/Puppet.

[marazmiki]

Ну это же странно: то ли пакеты платформозависимые собирать, то ли писать на хорошо известном питоне простые и понятные вещи.

[marklarius]

(Тыкнул не туда, см. комментарий в основной ветке.)

[marklarius]

Fabric не поможет мне, например, поставить MySQL-python без компилятора; так что собирать пакеты придется в любом случае.

[marazmiki]

Установкой MySQL-python не Fabric занимается, а pip:

run('pip install MySQL-python')

Если в системе будут найдены требуемые h-файлы, за милую душу соберёт. А ещё ведь и easy_install есть, он, кажется, умеет и из бинарных сборок ставить.

[marklarius]

Да, но какой смысл ставить libmysql-devel, gcc, glibc-devel и т.д. на боевом сервере, когда можно собрать пакет и парой кликов отправить его на все контролируемые сервера?

[marazmiki]

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

[marklarius]

Я вас не совсем понял; можете описать ситуацию в которой центральный контроль над установленными RPM-ами противопоказан?

[marazmiki]

Самое простое — разные версии какого-либо пакета. К примеру, проекту нужен именно psycopg2==2.4.1 (после этой версии что-то поменяли в механизме транзакций), а в пакете будет самый свежий, 2.4.5.

[marklarius]

Теперь ясно. В таком случае, можно настроить Spacewalk Channel, который будет раздавать эту версию и подписать сервер на него.

В любом случае, мы не собираем все пакеты в RPM, а только те которые почти универсальны (и требуют компиляции) PIL, MySQL. Пакеты которые pure Python ставятся через pip v в virtualenv.

[marazmiki]

Мне как-то спокойнее, когда проекты разрабатываются в девственно чистых окружениях, изолированных от системного. Это гарантирует, что слепок окружения (pip freeze) покажет те и только те пакеты версий, которые используются в проекте. Удобно :-)

Ради такой независимости пакетов можно и gcc потерпеть, и кучу dev-пакетов с заголовочниками. Лежат себе, каши не простят.

[marklarius]

У нас любой проект, «доживший» до деплоймента ставится на абсолютно чистый сервер, на котором стоит «наш» Python. Да и вообще, infosec-отдел нам не даёт ставить GCC… Так и живём.

[klen]

Для себя написал такое: github.com/klen/makesite

[marklarius]

Долго думал — «Почему не использовать Fabric?», а потом дошло :)

[MYPABEU]

Успешно пользуюсь makesite на работе.
Долго мучал автора вопросами: великолепно, быстро и развернуто получал ответы с примерами, описаниями.
В общем — спасибо =)

[marazmiki]

Я правильно понимаю, что Makesite сперва надо на целевом сервере установить?

[klen]

Ага, makesite и fabric совсем разные вещи если честно. Может быть вам поможет вот эта статья с примером: klen.github.com/deploy-setup-ru.html

[marazmiki]

Да, я её уже нагуглил, спасибо :-)

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