Пакетировать или нет
На неделе пытался (разумеется, безуспешно) собрать свою версию bluez5. Собрать-то собрал, да никакого осмысленного эффекта старый пульсаудио с новым блюзом не дают.
Впрочем, рассказ не про них.
В рассуждении о пакетировании есть некоторая крайне сложная область, которая касается жизни системы.
В описаниях openstack часто звучит метафора "cattle, not the pet" - мол, виртуалки - расхожее мясо для выполнения задач, а не что-то, о чём заботишься.
Классическая модель (как виндов, так и всех приличных линуксов) исходила из идеи, что хост - это важно. Этой позиции придерживается человек, который что-то делает на десктопе. Ему не хочется в результате какой-то ошибки остаться один на один с поломанными иксами или udev'ом. Отсюда крайняя степень консервативности к изменениям в системе (транзакции rpm, например), сложный свод правил, который должны соблюдать программы, тысячи тонких настроек и т.д.
Эта же модель успешно была перенесена на сервер (давайте признаемся - линуксы выросли с рабочих станций/десктопов, не говоря уже про винды). Даже в виндах есть масса тонких нюансиков, которые должны соблюдаться всеми для всеобщей гармонии.
Комфорт продолжительного сосуществования - вот, к чему стремятся все дистрибутивы.
Система сборки пакетов в дебиане преследует ту же цель - делать это комфортно. Это означает, что если для сборки пакетов нам надо 100500 зависимостей, то мы их можем поставить, не рискуя сломом всего и вся (если эти зависимости в комплекте). Есть apt-get build-dep, даже. Правда, нет обратного реверса (то есть снести их обратно так просто не получится). Я вполне это ощутил с bluez'ом, когда не смотря на миллионы странных пакетов в зависимостях, я просто и легко вернулся к предыдущему состоянию системы без бэкапов и откатов. Просто поставил на место старый блюз, удалил предусмотрительно выписанные новые зависимости и снёс каталог с сырцами.
Однако, если мы говорим про devops, то мы явно или нет, подходим к модели минимально необходимого функционала, а не комфортного продолжительного существования.
Сервер делает то, что должен делать и не делает то, что делать не должен - это ли не формула для идеальной инсталляции?
Заметим, что если мы говорим про серверочек в маленькой компании (пусть даже пяток серверов), то его роли - это что-то крайне объёмное и трудноописываемое. Если серверов несколько - то они делают всё. А значит, с ними нужно длительно и комфортно жить.
Если же мы переходим в массовый режим, где сервера многочисленны и безлики, плюс добавляем к этому виртуализацию (где provision ещё сервера - это десятки секунд времени), то ситуация сильно меняется.
Смотрите:
* Конфигурация сервера описана в системе управления конфигурации (chef, puppet, etc)
* Весь значимый софт либо обслуживается компанией, либо осмысленно используется (осмысленно - это значит, что за изменениями для софта следят), либо написан в стенах компании.
* Развёртывание сервера очень быстрое.
Есть ли в этой ситуации необходимость в длительном комфортном сосуществовании? Нет. Надо пойти и сделать что сказали. Более того, если выясняется, что по каким-то важным причинам сервер надо капитально переделать - никто не будет это делать "на живую". Сервер просто выведут из эксплуатации, а вместо него (если виртуалка) или поверх него (если железо) поставят новую конфигурацию.
В концепции "конфигурация как код" (диффы в гите, ревью коллегами) просто нет места долгоживущей инсталляции, у которой есть сложная история.
Таким образом, конфликт между пакетированием и "pip/cpan way" - это на самом деле идейный конфликт между "нам с этим потом жить" и "надо - переделаем в два клика". То есть тот же самый конфликт pet - cattle, о котором говорят openstack'овцы.
Впрочем, рассказ не про них.
В рассуждении о пакетировании есть некоторая крайне сложная область, которая касается жизни системы.
В описаниях openstack часто звучит метафора "cattle, not the pet" - мол, виртуалки - расхожее мясо для выполнения задач, а не что-то, о чём заботишься.
Классическая модель (как виндов, так и всех приличных линуксов) исходила из идеи, что хост - это важно. Этой позиции придерживается человек, который что-то делает на десктопе. Ему не хочется в результате какой-то ошибки остаться один на один с поломанными иксами или udev'ом. Отсюда крайняя степень консервативности к изменениям в системе (транзакции rpm, например), сложный свод правил, который должны соблюдать программы, тысячи тонких настроек и т.д.
Эта же модель успешно была перенесена на сервер (давайте признаемся - линуксы выросли с рабочих станций/десктопов, не говоря уже про винды). Даже в виндах есть масса тонких нюансиков, которые должны соблюдаться всеми для всеобщей гармонии.
Комфорт продолжительного сосуществования - вот, к чему стремятся все дистрибутивы.
Система сборки пакетов в дебиане преследует ту же цель - делать это комфортно. Это означает, что если для сборки пакетов нам надо 100500 зависимостей, то мы их можем поставить, не рискуя сломом всего и вся (если эти зависимости в комплекте). Есть apt-get build-dep, даже. Правда, нет обратного реверса (то есть снести их обратно так просто не получится). Я вполне это ощутил с bluez'ом, когда не смотря на миллионы странных пакетов в зависимостях, я просто и легко вернулся к предыдущему состоянию системы без бэкапов и откатов. Просто поставил на место старый блюз, удалил предусмотрительно выписанные новые зависимости и снёс каталог с сырцами.
Однако, если мы говорим про devops, то мы явно или нет, подходим к модели минимально необходимого функционала, а не комфортного продолжительного существования.
Сервер делает то, что должен делать и не делает то, что делать не должен - это ли не формула для идеальной инсталляции?
Заметим, что если мы говорим про серверочек в маленькой компании (пусть даже пяток серверов), то его роли - это что-то крайне объёмное и трудноописываемое. Если серверов несколько - то они делают всё. А значит, с ними нужно длительно и комфортно жить.
Если же мы переходим в массовый режим, где сервера многочисленны и безлики, плюс добавляем к этому виртуализацию (где provision ещё сервера - это десятки секунд времени), то ситуация сильно меняется.
Смотрите:
* Конфигурация сервера описана в системе управления конфигурации (chef, puppet, etc)
* Весь значимый софт либо обслуживается компанией, либо осмысленно используется (осмысленно - это значит, что за изменениями для софта следят), либо написан в стенах компании.
* Развёртывание сервера очень быстрое.
Есть ли в этой ситуации необходимость в длительном комфортном сосуществовании? Нет. Надо пойти и сделать что сказали. Более того, если выясняется, что по каким-то важным причинам сервер надо капитально переделать - никто не будет это делать "на живую". Сервер просто выведут из эксплуатации, а вместо него (если виртуалка) или поверх него (если железо) поставят новую конфигурацию.
В концепции "конфигурация как код" (диффы в гите, ревью коллегами) просто нет места долгоживущей инсталляции, у которой есть сложная история.
Таким образом, конфликт между пакетированием и "pip/cpan way" - это на самом деле идейный конфликт между "нам с этим потом жить" и "надо - переделаем в два клика". То есть тот же самый конфликт pet - cattle, о котором говорят openstack'овцы.