Всем большое спасибо за комментарии к первой статье. Хочу дать несколько разъяснений по заданным вопросам и сформулировать текущее видение ситуации.

Особенности выкладки питоньих проектов

По просьбам рассказываю немного подробностей о том, как у нас сейчас всё управляется и выкладывается:

Комментарии

Многие написали (пример) про то, что можно жить двояко: какие-то библиотеки держать общие, какие-то — свои.

Такой компромисс — на деле то же самое, что житьё в отдельных средах. Как я упомянул, неважно, каким именно способом это реализуется. Важно решить: заставляем мы все проекты жить в одной среде или позволяем решать самим, чем пользоваться.

glader:

А вот тут я наверное что-то пропустил. В чем заключается поддержка библиотек админами? Они их допиливают? Или тестируют? Или что?

Честно говоря, я не знаю. Подозреваю, что со стороны разработчика идея о том, что "админы бесполезны" примерно так же соответствует реальности, как идея менеджера о том, что "программировать легко, разработчики просто набивают себе цену". Я исхожу из того, что работы админам хватает. Иначе бы они не стояли стеной за унификацию версий не только на одном кластере, но и вообще по всему Яндексу :-).

Но на самом деле, я говорю о лёгкости поддержки админами не столько относительно того, как это происходит сейчас, а относительно того, куда нужно стремиться. Одинаковая среда позволяет использовать общие подходы к администрированию проектов, а житьё по песочницам заставляет каждую команду админить свой проект. Впрочем, это не выбор "или-или", это диапазон, положение в котором можно выбирать. Важно понять, чего мы хотим.

glader:

И это хорошо. Зачем тратить время на апгрейд, если он не нужен?

А вот это интересно :-). Вопрос об "обеспечении яндексовости" не стоял бы вообще, если бы все проекты вели себя в этом отношении одинаково. Но это не так. В одних проектах разработчики отдают предпочтение частым апгрейдам и рефакторингам кода, в других — реализации фич, заказанных маркетингом проекта, и апгрейдятся только по крайней необходимости.

Выражаясь очень откровенно, я не доверяю мнению отдельных команд о том, когда им надо апгрейдиться :-). Не потому что я умнее их, а потому что у меня думать об этом — основная работа, а команда проекта думает про свои фичи, а не про абстрактное "будущее платформы".

С этой точки зрения, я сейчас ищу способ не тащить силком сопротивляющихся упрямых разработчиков в светлое будущее, а организовать процесс так, чтобы им этого самим хотелось и было легче, чем сейчас. Ну или по крайней мере, чтобы это могли спокойней делать те, кому и так хочется.

ogintal:

Может просто типизировать проекты. Разложить по сходности задач, собрав в пул для простоты обновления. Создать виртуальную среду для каждого пула […]

Это замечательная идея, но в таком виде она слишком дорогая. Мы, хоть и "могучий Яндекс", но не можем создавать кластеры с админами и всем полагающимся на любой проект, который этого хочет.

Впрочем, эта идея мне тоже пригодилась — подробней в конце статьи.

lrrr:

У каждого проекта должна быть своя среда, а переход на новые версии библиотек можно делать административно, типа "через два месяца джанго 1.1 использовать не будем нигде".

Что интересно, я и сейчас могу в качестве последнего средства попросить админов заморозить все собственные обновления сервиса, пока тот не проапгрейдится. Но сейчас это блокирует остальных. А если проекты развести, та же самая "ядерная бомба" будет влиять только на конкретный проект. Так что да, это большой плюс в сторону изолированных проектов.

Текущее видение

События последних недель (у нас как раз прямо сейчас медленно происходит пресловутый апгрейд) убедили меня, что жить в общей среде стало совсем непрактично. Как раз потому, что далеко не все команды заинтересованы в этом в достаточной степени. Поэтому надо придумывать, как жить отдельно, но при этом избежать проблем, ообзначенных в прошлом посте:

Некоторые комментаторы высказали мысль, что проблема надуманная и/или легко решается. Сейчас я, пожалуй, соглашусь. В любом случае, про проблемы такого рода проще думать, когда они возникают, а не абстрактно. Поживём — увидим.

Пусть это будет необходимым злом. Если у проекта, например, течёт память или не очень эффективно что-то парсится, то это его собственная проблема до тех пор, пока это не мешает остальным на том же кластере. Если начинает мешать, можно административно поднять приоритет починки этого бага и всячески команду анноить, но главное — никому другому не нужно будет для этого останавливать разработку.

Месиво версий труднее поддерживать админам, которые у нас общие на весь кластер.

Это то, что нужно будет пообсуждать с админами. У меня созрела идея о том, что текущее разделение обязанностей и ответственности у нас неудобное, и его можно поменять, перевалив на разработчиков часть того, за что отвечают админы. Я пока не готов про это написать подробно, но хочу написать, когда буду лучше владеть деталями.

У разработчиков пропадает инициатива распространять свои внутрипроектные удачные решения в другие проекты, потому что когда у всех своя уникальная среда, мало гарантий, что общая библиотека заработает сразу и легко.

Это была, пожалуй, самая большая чушь из всего, что я написал в прошлый раз :-). Желание делиться кодом нельзя привить политикой, оно либо само по себе есть у разработчика, либо нет. Если он срелизит что-то, что не подойдёт кому-то другому, то это будет решаться по факту: либо библиотеку сделают более совместимой, либо проект наконец проапгрейдят, либо локальные патчи наложат. Точно так, как это происходит в глобальном масштабе.


В итоге получается примерно такой набор идей для ближайшей реализации:

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

Буду стараться держать в курсе!

Комментарии: 15 (feed)

  1. glader.livejournal.com

    Подозреваю, что со стороны разработчика идея о том, что "админы бесполезны" примерно так же соответствует реальности, как идея менеджера о том, что "программировать легко, разработчики просто набивают себе цену".

    Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю. Пойду спрошу у пасанов, что их тревожит. А идею "ваша библиотека, вы с ней и развлекайтесь" полностью поддерживаю. Если библиотека не ломает что-то у других, ей вполне может заниматься команда того сервиса, которому эта библиотека нужна.

  2. Zubchick

    Надо каким то образом добиться того, что переезд пакета в виртуальную среду из глобальной был последним из вариантов решения проблемы, а не первым. А ещё не ясно как выкладывать такие пакеты часть зависимостей которых из виртуального окружения, а часть нет. В любом случае админы будут сильно не довольны.

  3. ogintal

    Это замечательная идея, но в таком виде она слишком дорогая. Мы, хоть и "могучий Яндекс", но не можем создавать кластеры с админами и всем полагающимся на любой проект, который этого хочет.

    Мне это дешевле казалось:) Зачем отдельные кластеры? У нас есть проекты : a, b, c, d. Мы понимаем, что проекты a и d имеют 80% схожести по процессам и использованным библиотекам, просто разворачиваем их вместе в одной виртуальной среде (virtualenv), админы остаются те же, команды разработчиков те же, мега больших ресурсов не нужно. В конце статьи к этому и пришло. Из минусов только почкование команд по пулам виртуализации, как у вас это решится не знаю:)

    Интересно, что же будет дальше.

  4. Ivan Sagalaev

    Ваня, ну не надо так уж совсем. Я сказал "не знаю" именно потому, что не знаю.

    Ну я тоже не подозреваю тебя серьёзно в такой точке зрения, это был сарказм :-). Это вообще больше объяснение для широкой публики, потому что да, мы с тобой как раз имеем возможность просто пойти и спросить лично.

  5. 3BEP

    У меня вопрос - а нужно ли вообще поощрять апгрейды?

    Переход на новую версию библиотеки вообще имеет смысл только при наличии явных бенефитов. Для продукта который находится в активной разрабоке. Продукт который заточен под выполнение определенных задач и который уже прекрасно с ними справляется - обновлять имеет смысл только при глобальном апгрейде/смене платформы.

  6. vmagamedov

    Вроде virtualenv подразумевает наличие сервера PyPi и/или репозиториев для установки зависимостей. Не уверен, что вашим админам это понравится. Также им лучше иметь предсказуемую и понятную структуру катологов с библиотеками, чем все эти хитрости с virtualenv. Это вы возможно и будете обсуждать с админами.

    Гляньте как сделано в Google App Engine, там есть возможность выбирать версии библиотек, которые уже доступны в окружении на каждой машине. Разработчикам заморачиваться с виртуальными окружениями тоже не приходится. Работает довольно хорошо.

    Таким образом в проекте можно написать так:

    use_library('django', '1.2')
    

    или, если на проекте решили пропатчить библиотеку, то как-то так:

    use_library('django', '1.2', 'afisha')
    

    Или же вынести эти зависимости в отдельный файл (requirements.txt) и написать запускалку приложений, которая будет делать тоже самое, что и код выше.

    Если без патчей нельзя - можно как-то организовать центральное хранение патчей, чтобы можно было их легко поддерживать, обсуждать, дорабатывать, портировать. Чтобы можно было автоматом собрать версию джанги с определенным набором патчей под конкретный проект в deb пакет и залить его в репозиторий.

    Так в системе будет установлено несколько deb пакетов с разными версиями джанги: стандартные версии и версии с наложенным набором патчей под конкретный проект:

    • yandex-django-1.2
    • yandex-django-1.2-afisha
    • yandex-django-1.3
    • ...

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

    Заставлять делать что-либо не эффективно, как мне кажется, лучше создать условия, чтобы программисты сами хотели расшарить свои наработки. В случае предложенного варианта с патчами, им будет некуда деваться, все патчи будут в одном месте и все их будут видеть и использовать/дорабатывать при необходимости. В случае общего проекта, в человеке будет играть то чувство, которое движет опенсорс. А кому это не интересно - их лучше не заставлять, они просто выполняют то, что от них требуется, ни больше ни меньше.

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

  7. Ivan Sagalaev

    Ну конечно апгрейды случаются не от нечего делать. Всегда есть какая-то причина. Только сейчас причина есть у одного сервиса, а апгрейдиться надо всем.

  8. alekam

    Странно, что нельзя апдейтить проекты по отдельности.

    Выкладку проектов нужно будет делать с использованием virtualenv, чтобы каждый проект легко и непринуждённо мог сам выбирать, какие библиотеки таскать локально, а какие использовать системно. Надо будет внимательно подумать над ресолвингом зависимостей и совмещении этого подхода с .deb-пакетами.

    .deb-пакеты тут явный оверхед. У python уже есть неплохая система дистрибуции пакетов. Проверить наличие обновлений с ее помощью не получится, но когда версии всех библиотек известны обновление происходит за одну операцию. Это отлично решается с помощью pip. Более того, зависимости между библиотеками можно указывать в их дистрибутивах.

    Вроде virtualenv подразумевает наличие сервера PyPi и/или репозиториев для установки зависимостей. Не уверен, что вашим админам это понравится. Также им лучше иметь предсказуемую и понятную структуру катологов с библиотеками, чем все эти хитрости с virtualenv. Это вы возможно и будете обсуждать с админами.

    Можно запустить локальный PyPi, содержащий все используемые в компании python-библиотеки. Для его построения достаточно апача с автоиндексом директорий.

    Процесс работы с virtualenv хорошо формализуется и автоматизируется, никаких хитростей и тайных знаний там нет )

  9. mixael

    От предложения использовать два менеджера пакетов админы точно будут в шоке!

    Согласен что в нынешнем положении явно не хватает гибкости. Часто хочется использовать плюшки из 1.3, приходится постоянно себя одергивать. Как с кирпичем на шее :) А еще бывают разные версии той же django в тестинге и на продакшене и это вообще грусно.

    Ваня, мне думается что virtualenv — правильная идея. Как минимум потому что это сократит количество костылей.

  10. alekam

    Вы же всемогущий Яндекс. Сделайте для себя хостинг django-приложений, тот же GreatBigCrane допилите и пусть оно само в изолированную среду (virtualenv или buildout в принципе неважно) проекты и их зависимости разворачивает. Все зависимости можно оформить как бинарные дистрибутивы, положить в локальный PyPi и ничего не нужно будет собирать на продакшине. Тогда админам нужно будет только предоставить разработчикам рабочий сервер с этой штукой и обеспечить работоспособность локального PyPi на каком-нибудь локальном сервере. Разработчики вместо сборки deb-пакетов, будут собирать python-дистрибутивы библиотек и загружать их новые версии в локальный PyPi. Тогда для развертывания проекта, им нужно будет загрузить в систему список зависимостей и она сама развернет проект. Как-то так.

  11. yarobob

    .deb-пакеты тут явный оверхед. У python уже есть неплохая система дистрибуции пакетов. Проверить наличие обновлений с ее помощью не получится, но когда версии всех библиотек известны обновление происходит за одну операцию. Это отлично решается с помощью pip. Более того, зависимости между библиотеками можно указывать в их дистрибутивах.

    Pip не спасает, когда есть байдинг к сишной библиотеке и ее нужно подтянуть по зависимости. Так же, бывают ситуации, когда в зависимости от версии дистрибутива, ставится та, или иная библиотека. А еще на боевых серверах нежелательно держать компиляторы и прочие инструменты сборки. Вобщем, есть ряд проблем, которые не решаются специфичными для платформы менеджерами библиотек (pip, cpan, maven), но решаются менеджерами пакетов от дистрибутива. Мы тоже в итоге пришли к использованию rpm, жить стало существенно легче, даже несмотря на ужасную архитектуру рпм и его спеков.

  12. alekam

    на боевых серверах нежелательно держать компиляторы и прочие инструменты сборки.

    Для библиотек можно собирать бинарные дистрибутивы (zip c откомпиленным кодом внутри вместо исходников)

  13. igogo

    в ITSM (ITIL)есть такие процессы - управление конфигурациями и управление релизами. может положить эти процессы в основу и тогда отпадет элемент "уговаривания" кого-либо. Метода работает и не надо придумывать велик.

  14. Если еще не читали 2 статьи на близкую тему в блоге Ивана Сагалаева, рекомендую прочитать: Вместе или врозь, Вместе или врозь: новая идея

  15. Powerman

    Я не комментировал предыдущую статью именно из-за надуманности части проблем/ограничений - при такой постановке задачи она не имела адекватного решения.

    А вот то, что описано в этой статье - практически идентично подходу, который давно используется у нас, так что лично мне он нравится и кажется вполне разумным. :) У нас мультиязычные сервисы (Perl, Limbo, Python), но подход для всех одинаковый:

    • на всех серверах кластера и машинах разработчиков стоят одинаковые последние стабильные версии используемых библиотек, и обновляются они админом независимо от обновлений сервисов (но после небольшого тестирования что никакие сервисы не "упали" после обновления общесистемных библиотек)
    • некоторые сервисы содержат внутри себя необходимые им версии библиотек, использующиеся вместо общесистемных
    • "стимул" использовать общесистемные библиотеки реализуется как раз за счёт того, что ответственность за поддержку/патчи/обновления локальных библиотек лежит на разработчиках сервиса
    • мы это пока не реализовали, но по-хорошему админу бы не помешало написать скриптик, сканирующий версии библиотек локально установленных во всех проектах/сервисах и уведомляющий о версиях с известными дырами в безопасности

    Что касается фич из серии "обеспечения яндексовости", то в нашем случае такие вещи решаются административно: если проект ведёт себя нетипичным образом либо массово по всех проектам необходимо изменить их поведение (напр. как ведутся те же логи), то подготавливаются примеры патчей/описания необходимых модификаций и эта задача ставится всем проектам с максимальным приоритетом. В большинстве проектов достаточно просто применить данный патч, в некоторых случаях требуется дополнительное допиливание, но как правило за два-три дня задача решается.

Добавить комментарий

Format with markdown