Компания, над которой я сейчас работаю, создает RPM для каждой и каждой зависимости CPAN & Internal приложения (довольно много пакетов!), Которое устанавливается в системный каталог site_perl.У этого есть ряд проблем:
- Создание сборок RPM занимает много времени, поскольку версии сталкиваются с CPAN.
- Привязка к системному Perl означает, что вы находитесь намилость вашего дистрибутива, чтобы создать или сломать ваш perl (в Centos 5 у нас максимальная версия perl 5.8.8!).
- Если на одном хосте развернуто несколько приложений с единой библиотекой perl длявсе приложения означают, что обновление зависимостей может быть опасным без повторного тестирования каждого приложения хоста.Мы развернули довольно много отдельных дистрибутивов, все с разной степенью внимательности к обслуживанию, поэтому для нас это большое дело.
Мы отказываемся от создания RPM для каждой зависимости и вместо этого планируем использовать картонную коробку.[1] создать полностью автономную библиотеку perl для каждого приложения, которое мы развертываем.Мы встраиваем эти библиотеки в системные пакеты, но вы также можете легко их собрать и скопировать вручную, если не хотите иметь дело с менеджером пакетов.
Проблема с коробкой заключается в том, что выВам нужно будет настроить внутреннее зеркало CPAN, в которое вы можете установить свои внутренние зависимости, если ваше приложение зависит от модулей, которые не входят в CPAN.Если вы не хотите иметь с этим дело, вы всегда можете просто вручную установить нужные библиотеки в local :: lib [2] или perlbrew [3] и упаковать полученные библиотеки для развертывания на ваших производственных блоках.
При всех предписанных решениях будьте очень осторожны с XS perl libs.Вам нужно будет собрать ваши cartons / local: libs / perlbrews на той же архитектуре, что и хост, на который вы развертываете, и убедиться, что ваши производственные блоки имеют те же бинарные зависимости, что и те, которые вы использовали для сборки.
Чтобы ответить на обновление вашего вопроса о том, является ли наилучшей практикой исходная проверка и установка на ваш рабочий хост ;Я лично не думаю, что это хорошая идея.Причины, по которым я полагаю, что это рискованно, кроются в том, что трудно быть полностью уверенным в том, что набор устанавливаемых вами библиотек точно соответствует библиотекам, с которыми вы тестировали, поэтому развертывание потенциально может быть непредсказуемым.Эта проблема может усугубляться веб-приложениями, поскольку вы, скорее всего, будете иметь один и тот же код, развернутый на нескольких производственных блоках, которые также могут быть не синхронизированы.В то время как сообщество Perl делает замечательную работу, пытаясь выпустить качественный код с обратной совместимостью, когда что-то идет не так, как правило, довольно сложно разобраться.Вот почему коробка разрабатывается, так как она создает кеш всех дистрибутивов дистрибутива, которые вам нужно установить, замороженных в определенных версиях, чтобы вы могли предсказуемо развернуть свой код.Все это сказал, хотя;Если вы счастливы принять этот риск и исправить вещи, когда они сломаются, то локальная установка будет вам подойдет.Однако, как минимум, я бы настоятельно рекомендовал установить на локальный :: lib, чтобы вы могли создать резервную копию старого локального lib перед установкой обновлений, чтобы у вас была точка отката, если что-то испортилось.