Вместе или врозь: новая идея » комментарииhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/2011-07-07T03:56:02.753584-07:00Иван Сагалаев о программировании и веб-разработкеhttp://softwaremaniacs.org/media/sm_org/style/photo.jpgPowerman на "Вместе или врозь: новая идея"
2011-07-07T03:56:02.753584-07:00Powermanhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-90943Я не комментировал предыдущую статью именно из-за надуманности части проблем/ограничений - при такой постановке задачи она не имела адекватного решения. А вот то, что описано в этой статье - практически идентично подходу, который давно используется у нас, так что лично мне он нравится и кажется вполне разумным. :) У нас...
<p>Я не комментировал предыдущую статью именно из-за надуманности части проблем/ограничений - при такой постановке задачи она не имела адекватного решения.</p>
<p>А вот то, что описано в этой статье - практически идентично подходу, который давно используется у нас, так что лично мне он нравится и кажется вполне разумным. :) У нас мультиязычные сервисы (Perl, Limbo, Python), но подход для всех одинаковый:</p>
<ul>
<li>на всех серверах кластера и машинах разработчиков стоят одинаковые последние стабильные версии используемых библиотек, и обновляются они админом независимо от обновлений сервисов (но после небольшого тестирования что никакие сервисы не "упали" после обновления общесистемных библиотек)</li>
<li>некоторые сервисы содержат внутри себя необходимые им версии библиотек, использующиеся вместо общесистемных</li>
<li>"стимул" использовать общесистемные библиотеки реализуется как раз за счёт того, что ответственность за поддержку/патчи/обновления локальных библиотек лежит на разработчиках сервиса</li>
<li>мы это пока не реализовали, но по-хорошему админу бы не помешало написать скриптик, сканирующий версии библиотек локально установленных во всех проектах/сервисах и уведомляющий о версиях с известными дырами в безопасности</li>
</ul>
<p>Что касается фич из серии "обеспечения яндексовости", то в нашем случае такие вещи решаются административно: если проект ведёт себя нетипичным образом либо массово по всех проектам необходимо изменить их поведение (напр. как ведутся те же логи), то подготавливаются примеры патчей/описания необходимых модификаций и эта задача ставится всем проектам с максимальным приоритетом. В большинстве проектов достаточно просто применить данный патч, в некоторых случаях требуется дополнительное допиливание, но как правило за два-три дня задача решается.The New Heroku (Part 4 of 4): Erosion-resistance & Explicit Contracts - Блог Романа Ворушина на "Вместе или врозь: новая идея"
2011-06-30T01:21:55.036909-07:00The New Heroku (Part 4 of 4): Erosion-resistance & Explicit Contracts - Блог Романа Ворушинаhttp://vorushin.ru/blog/link/154/https://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-89911Если еще не читали 2 статьи на близкую тему в блоге Ивана Сагалаева, рекомендую прочитать: Вместе или врозь, Вместе или врозь: новая идея
<p>Если еще не читали 2 статьи на близкую тему в блоге Ивана Сагалаева, рекомендую прочитать: Вместе или врозь, Вместе или врозь: новая идеяigogo на "Вместе или врозь: новая идея"
2011-06-24T02:58:49.343889-07:00igogohttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-89057в ITSM (ITIL)есть такие процессы - управление конфигурациями и управление релизами. может положить эти процессы в основу и тогда отпадет элемент "уговаривания" кого-либо. Метода работает и не надо придумывать велик.
<p>в ITSM (ITIL)есть такие процессы - управление конфигурациями и управление релизами. может положить эти процессы в основу и тогда отпадет элемент "уговаривания" кого-либо. Метода работает и не надо придумывать велик.alekam на "Вместе или врозь: новая идея"
2011-06-23T23:37:17.330204-07:00alekamhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-89028на боевых серверах нежелательно держать компиляторы и прочие инструменты сборки. Для библиотек можно собирать бинарные дистрибутивы (zip c откомпиленным кодом внутри вместо исходников)
<blockquote>
<p>на боевых серверах нежелательно держать компиляторы и прочие инструменты сборки.</p>
</blockquote>
<p>Для библиотек можно собирать бинарные дистрибутивы (zip c откомпиленным кодом внутри вместо исходников)yarobob на "Вместе или врозь: новая идея"
2011-06-21T02:05:42.810646-07:00yarobobhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-88715.deb-пакеты тут явный оверхед. У python уже есть неплохая система дистрибуции пакетов. Проверить наличие обновлений с ее помощью не получится, но когда версии всех библиотек известны обновление происходит за одну операцию. Это отлично решается с помощью pip. Более того, зависимости между библиотеками можно указывать в их дистрибутивах. Pip не спасает,...
<blockquote>
<p>.deb-пакеты тут явный оверхед. У python уже есть неплохая система дистрибуции пакетов. Проверить наличие обновлений с ее помощью не получится, но когда версии всех библиотек известны обновление происходит за одну операцию. Это отлично решается с помощью pip. Более того, зависимости между библиотеками можно указывать в их дистрибутивах.</p>
</blockquote>
<p>Pip не спасает, когда есть байдинг к сишной библиотеке и ее нужно подтянуть по зависимости. Так же, бывают ситуации, когда в зависимости от версии дистрибутива, ставится та, или иная библиотека. А еще на боевых серверах нежелательно держать компиляторы и прочие инструменты сборки. Вобщем, есть ряд проблем, которые не решаются специфичными для платформы менеджерами библиотек (pip, cpan, maven), но решаются менеджерами пакетов от дистрибутива. Мы тоже в итоге пришли к использованию rpm, жить стало существенно легче, даже несмотря на ужасную архитектуру рпм и его спеков.alekam на "Вместе или врозь: новая идея"
2011-06-20T07:23:16.703231-07:00alekamhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-88432Вы же всемогущий Яндекс. Сделайте для себя хостинг django-приложений, тот же GreatBigCrane допилите и пусть оно само в изолированную среду (virtualenv или buildout в принципе неважно) проекты и их зависимости разворачивает. Все зависимости можно оформить как бинарные дистрибутивы, положить в локальный PyPi и ничего не нужно будет собирать на продакшине....
<p>Вы же всемогущий Яндекс. Сделайте для себя хостинг django-приложений, тот же GreatBigCrane допилите и пусть оно само в изолированную среду (virtualenv или buildout в принципе неважно) проекты и их зависимости разворачивает. Все зависимости можно оформить как бинарные дистрибутивы, положить в локальный PyPi и ничего не нужно будет собирать на продакшине. Тогда админам нужно будет только предоставить разработчикам рабочий сервер с этой штукой и обеспечить работоспособность локального PyPi на каком-нибудь локальном сервере. Разработчики вместо сборки deb-пакетов, будут собирать python-дистрибутивы библиотек и загружать их новые версии в локальный PyPi. Тогда для развертывания проекта, им нужно будет загрузить в систему список зависимостей и она сама развернет проект. Как-то так.mixael на "Вместе или врозь: новая идея"
2011-06-18T12:38:34.057957-07:00mixaelhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-88027От предложения использовать два менеджера пакетов админы точно будут в шоке! Согласен что в нынешнем положении явно не хватает гибкости. Часто хочется использовать плюшки из 1.3, приходится постоянно себя одергивать. Как с кирпичем на шее :) А еще бывают разные версии той же django в тестинге и на продакшене и...
<p>От предложения использовать два менеджера пакетов админы точно будут в шоке!</p>
<p>Согласен что в нынешнем положении явно не хватает гибкости. Часто хочется использовать плюшки из 1.3, приходится постоянно себя одергивать. Как с кирпичем на шее :) А еще бывают разные версии той же django в тестинге и на продакшене и это вообще грусно.</p>
<p>Ваня, мне думается что virtualenv — правильная идея. Как минимум потому что это сократит количество костылей.alekam на "Вместе или врозь: новая идея"
2011-06-17T10:27:18.315004-07:00alekamhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87910Странно, что нельзя апдейтить проекты по отдельности. Выкладку проектов нужно будет делать с использованием virtualenv, чтобы каждый проект легко и непринуждённо мог сам выбирать, какие библиотеки таскать локально, а какие использовать системно. Надо будет внимательно подумать над ресолвингом зависимостей и совмещении этого подхода с .deb-пакетами. .deb-пакеты тут явный оверхед. У...
<p>Странно, что нельзя апдейтить проекты по отдельности.</p>
<blockquote>
<p>Выкладку проектов нужно будет делать с использованием virtualenv, чтобы каждый проект легко и непринуждённо мог сам выбирать, какие библиотеки таскать локально, а какие использовать системно. Надо будет внимательно подумать над ресолвингом зависимостей и совмещении этого подхода с .deb-пакетами.</p>
</blockquote>
<p>.deb-пакеты тут явный оверхед. У python уже есть неплохая система дистрибуции пакетов. Проверить наличие обновлений с ее помощью не получится, но когда версии всех библиотек известны обновление происходит за одну операцию. Это отлично решается с помощью pip. Более того, зависимости между библиотеками можно указывать в их дистрибутивах.</p>
<blockquote>
<p>Вроде virtualenv подразумевает наличие сервера PyPi и/или репозиториев для установки зависимостей. Не уверен, что вашим админам это понравится. Также им лучше иметь предсказуемую и понятную структуру катологов с библиотеками, чем все эти хитрости с virtualenv. Это вы возможно и будете обсуждать с админами.</p>
</blockquote>
<p>Можно запустить локальный PyPi, содержащий все используемые в компании python-библиотеки. Для его построения достаточно апача с автоиндексом директорий.</p>
<p>Процесс работы с virtualenv хорошо формализуется и автоматизируется, никаких хитростей и тайных знаний там нет )Ivan Sagalaev на "Вместе или врозь: новая идея"
2011-06-15T12:20:15.730350-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87678Ну конечно апгрейды случаются не от нечего делать. Всегда есть какая-то причина. Только сейчас причина есть у одного сервиса, а апгрейдиться надо всем.
<p>Ну конечно апгрейды случаются не от нечего делать. Всегда есть какая-то причина. Только сейчас причина есть у одного сервиса, а апгрейдиться надо всем.vmagamedov на "Вместе или врозь: новая идея"
2011-06-15T11:30:18.615488-07:00vmagamedovhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87671Вроде virtualenv подразумевает наличие сервера PyPi и/или репозиториев для установки зависимостей. Не уверен, что вашим админам это понравится. Также им лучше иметь предсказуемую и понятную структуру катологов с библиотеками, чем все эти хитрости с virtualenv. Это вы возможно и будете обсуждать с админами. Гляньте как сделано в Google App Engine,...
<p>Вроде virtualenv подразумевает наличие сервера PyPi и/или репозиториев для установки зависимостей. Не уверен, что вашим админам это понравится. Также им лучше иметь предсказуемую и понятную структуру катологов с библиотеками, чем все эти хитрости с virtualenv. Это вы возможно и будете обсуждать с админами.</p>
<p>Гляньте как сделано в Google App Engine, там есть возможность выбирать версии библиотек, которые уже доступны в окружении на каждой машине. Разработчикам заморачиваться с виртуальными окружениями тоже не приходится. Работает довольно хорошо.</p>
<p>Таким образом в проекте можно написать так:</p>
<pre><code>use_library('django', '1.2')
</code></pre>
<p>или, если на проекте решили пропатчить библиотеку, то как-то так:</p>
<pre><code>use_library('django', '1.2', 'afisha')
</code></pre>
<p>Или же вынести эти зависимости в отдельный файл (requirements.txt) и написать запускалку приложений, которая будет делать тоже самое, что и код выше.</p>
<p>Если без патчей нельзя - можно как-то организовать центральное хранение патчей, чтобы можно было их легко поддерживать, обсуждать, дорабатывать, портировать. Чтобы можно было автоматом собрать версию джанги с определенным набором патчей под конкретный проект в deb пакет и залить его в репозиторий.</p>
<p>Так в системе будет установлено несколько deb пакетов с разными версиями джанги: стандартные версии и версии с наложенным набором патчей под конкретный проект:</p>
<ul>
<li>yandex-django-1.2</li>
<li>yandex-django-1.2-afisha</li>
<li>yandex-django-1.3</li>
<li>...</li>
</ul>
<p>Если нужно поделиться своим кодом - можно создать общий проект, в котором будут собраны лучшие наработки проектов. В проекте будет транк и бранчи как в джанге. Новые фичи идут в транк и бэкпортируются на другие бранчи по мере необходимости.</p>
<p>Заставлять делать что-либо не эффективно, как мне кажется, лучше создать условия, чтобы программисты сами хотели расшарить свои наработки. В случае предложенного варианта с патчами, им будет некуда деваться, все патчи будут в одном месте и все их будут видеть и использовать/дорабатывать при необходимости. В случае общего проекта, в человеке будет играть то чувство, которое движет опенсорс. А кому это не интересно - их лучше не заставлять, они просто выполняют то, что от них требуется, ни больше ни меньше.</p>
<p>Самый трудный вопрос - это некая автоматизация перехода на другую версию, тут видимо только одними уговорами можно что-то сделать, если само собой не идет.3BEP на "Вместе или врозь: новая идея"
2011-06-15T06:30:38.621223-07:003BEPhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87636У меня вопрос - а нужно ли вообще поощрять апгрейды? Переход на новую версию библиотеки вообще имеет смысл только при наличии явных бенефитов. Для продукта который находится в активной разрабоке. Продукт который заточен под выполнение определенных задач и который уже прекрасно с ними справляется - обновлять имеет смысл только при...
<p>У меня вопрос - а нужно ли вообще поощрять апгрейды?</p>
<p>Переход на новую версию библиотеки вообще имеет смысл только при наличии явных бенефитов. Для продукта который находится в активной разрабоке. Продукт который заточен под выполнение определенных задач и который уже прекрасно с ними справляется - обновлять имеет смысл только при глобальном апгрейде/смене платформы.Ivan Sagalaev на "Вместе или врозь: новая идея"
2011-06-14T23:42:41.735916-07:00Ivan Sagalaevhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87576Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю. Ну я тоже не подозреваю тебя серьёзно в такой точке зрения, это был сарказм :-). Это вообще больше объяснение для широкой публики, потому что да, мы с тобой как раз имеем возможность просто пойти...
<blockquote>
<p>Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю.</p>
</blockquote>
<p>Ну я тоже не подозреваю тебя серьёзно в такой точке зрения, это был сарказм :-). Это вообще больше объяснение для широкой публики, потому что да, мы с тобой как раз имеем возможность просто пойти и спросить лично.ogintal на "Вместе или врозь: новая идея"
2011-06-14T23:27:40.559429-07:00ogintalhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87575Это замечательная идея, но в таком виде она слишком дорогая. Мы, хоть и "могучий Яндекс", но не можем создавать кластеры с админами и всем полагающимся на любой проект, который этого хочет. Мне это дешевле казалось:) Зачем отдельные кластеры? У нас есть проекты : a, b, c, d. Мы понимаем, что...
<blockquote>
<p>Это замечательная идея, но в таком виде она слишком дорогая. Мы, хоть и "могучий Яндекс", но не можем создавать кластеры с админами и всем полагающимся на любой проект, который этого хочет.</p>
</blockquote>
<p>Мне это дешевле казалось:) Зачем отдельные кластеры? У нас есть проекты : a, b, c, d. Мы понимаем, что проекты a и d имеют 80% схожести по процессам и использованным библиотекам, просто разворачиваем их вместе в одной виртуальной среде (virtualenv), админы остаются те же, команды разработчиков те же, мега больших ресурсов не нужно. В конце статьи к этому и пришло. Из минусов только почкование команд по пулам виртуализации, как у вас это решится не знаю:)</p>
<p>Интересно, что же будет дальше.Zubchick на "Вместе или врозь: новая идея"
2011-06-14T23:19:53.823567-07:00Zubchickhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87574Надо каким то образом добиться того, что переезд пакета в виртуальную среду из глобальной был последним из вариантов решения проблемы, а не первым. А ещё не ясно как выкладывать такие пакеты часть зависимостей которых из виртуального окружения, а часть нет. В любом случае админы будут сильно не довольны.
<p>Надо каким то образом добиться того, что переезд пакета в виртуальную среду из глобальной был последним из вариантов решения проблемы, а не первым. А ещё не ясно как выкладывать такие пакеты часть зависимостей которых из виртуального окружения, а часть нет. В любом случае админы будут сильно не довольны. glader.livejournal.com на "Вместе или врозь: новая идея"
2011-06-14T22:40:17.493208-07:00glader.livejournal.comhttps://softwaremaniacs.org/blog/2011/06/14/shared-or-isolated-2/#comment-87567Подозреваю, что со стороны разработчика идея о том, что "админы бесполезны" примерно так же соответствует реальности, как идея менеджера о том, что "программировать легко, разработчики просто набивают себе цену". Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю. Пойду спрошу у пасанов, что...
<blockquote>
<p>Подозреваю, что со стороны разработчика идея о том, что "админы бесполезны" примерно так же соответствует реальности, как идея менеджера о том, что "программировать легко, разработчики просто набивают себе цену".</p>
</blockquote>
<p>Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю. Пойду спрошу у пасанов, что их тревожит. А идею "ваша библиотека, вы с ней и развлекайтесь" полностью поддерживаю. Если библиотека не ломает что-то у других, ей вполне может заниматься команда того сервиса, которому эта библиотека нужна.