Концептуальная проблема с пакетами в системе (devops)
Выписываю свои первые мысли по вопросу. У меня нет ещё готовой точки зрения и я хочу просто пока что сформулировать проблему и аргументы с каждой из точек зрения.
Вопрос простой: как должен свой софт появляться на серверах? Понятно, что репозитории, бранчи и так далее. Но ключевой вопрос, который, в радикально-религиозном формате звучит так: слакваря или пакеты?
Другими словами, make install или dpkg -i (yum localinstall, не важно)?
Сначала изложу формально религиозную позицию (которой я долгое время придерживался, и от которой мне не хочется отходить даже под давлением реальности).
Правильный метод установки ПО - посредством пакетов (для дальнейшего удобства я буду идти по debian-way). Другими словами, софт, поставленный без участия dpkg, это превращение системы в Слакварю, в адское смешение неявных зависимостей, невозможность спокойного обновления.
Для того, чтобы обновление проходило штатными методами, пакеты должны быть выложены на свой собственный миррор.
Для того, чтобы пакет полностью соответствовал требованиям, он должен содержать changelog.
Если пакет обязательно зависит от какой-то библиотеки, то она должна быть запакетирована ровно таким же образом.
Если все всё будут всегда пакетировать, то в мире наступит мир, покой и счастье.
Это такая ясная простая позиция системного администратора, который вволю нахлебался всяких там кривоустановщиков вида ./NVIDIA*, ./LSI* и т.д., помноженная на отлов глюков разных версий явы для разных проприентарных поделок.
Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость. Он использует кучу библиотек из pypy, rubygems, epel, hackage, opam и т.д. На сервере могут одновременно работать программы, которым нужна одна и та же библиотека, но с разными версиями. Например, одному нужна libfoo [>1.5, <2], другому libfoo [>2].
Более того, сами библиотеки так же могут начинать зависеть от конфликтного множества.
Таким образом, разрабочик хочет иметь себе комфортную систему управления зависимостями - pip, bunder, cabal, etc.
Казалось бы, ситуация ясная: системные пакеты - это системные пакеты, а свой софт собирает зависимости с помощью своего управлятора зависимостями.
Это так, ровно до того момента, пока очередной библиотеке не оказывается необходимо жить в присутствии системной библиотеки. Особенно, в районе -dev, которой по совести нужно иметь соответствующую ей не-dev версию.
И вот тут приходит некая непонятная мне конструкция, решения которой я не вижу.
Как подружить эти миры?
Злой голосок с соседнего стола нашёптывает, что если всё разворачивать одинаковыми рецептами шефа, то всё будет работать или не работать одинаково.
Но выход ли это? А, главное, у меня есть ощущение, что я не выписал проблему целиком.
Вопрос простой: как должен свой софт появляться на серверах? Понятно, что репозитории, бранчи и так далее. Но ключевой вопрос, который, в радикально-религиозном формате звучит так: слакваря или пакеты?
Другими словами, make install или dpkg -i (yum localinstall, не важно)?
Сначала изложу формально религиозную позицию (которой я долгое время придерживался, и от которой мне не хочется отходить даже под давлением реальности).
Правильный метод установки ПО - посредством пакетов (для дальнейшего удобства я буду идти по debian-way). Другими словами, софт, поставленный без участия dpkg, это превращение системы в Слакварю, в адское смешение неявных зависимостей, невозможность спокойного обновления.
Для того, чтобы обновление проходило штатными методами, пакеты должны быть выложены на свой собственный миррор.
Для того, чтобы пакет полностью соответствовал требованиям, он должен содержать changelog.
Если пакет обязательно зависит от какой-то библиотеки, то она должна быть запакетирована ровно таким же образом.
Если все всё будут всегда пакетировать, то в мире наступит мир, покой и счастье.
Это такая ясная простая позиция системного администратора, который вволю нахлебался всяких там кривоустановщиков вида ./NVIDIA*, ./LSI* и т.д., помноженная на отлов глюков разных версий явы для разных проприентарных поделок.
Однако, есть и противоположная позиция - позиция разработчика. У него - миллион и одна зависимость. Он использует кучу библиотек из pypy, rubygems, epel, hackage, opam и т.д. На сервере могут одновременно работать программы, которым нужна одна и та же библиотека, но с разными версиями. Например, одному нужна libfoo [>1.5, <2], другому libfoo [>2].
Более того, сами библиотеки так же могут начинать зависеть от конфликтного множества.
Таким образом, разрабочик хочет иметь себе комфортную систему управления зависимостями - pip, bunder, cabal, etc.
Казалось бы, ситуация ясная: системные пакеты - это системные пакеты, а свой софт собирает зависимости с помощью своего управлятора зависимостями.
Это так, ровно до того момента, пока очередной библиотеке не оказывается необходимо жить в присутствии системной библиотеки. Особенно, в районе -dev, которой по совести нужно иметь соответствующую ей не-dev версию.
И вот тут приходит некая непонятная мне конструкция, решения которой я не вижу.
Как подружить эти миры?
Злой голосок с соседнего стола нашёптывает, что если всё разворачивать одинаковыми рецептами шефа, то всё будет работать или не работать одинаково.
Но выход ли это? А, главное, у меня есть ощущение, что я не выписал проблему целиком.