Ответ 1
Компания, с которой я работаю, в настоящее время создает RPM для каждого CPAN и внутренней зависимости приложения (довольно много пакетов!), которые устанавливаются в каталог system_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. Вам нужно будет создать свои картонные/локальные: libs/perlbrews в той же архитектуре, что и хост, на котором вы развертываете, и убедитесь, что ваши коробки с продуктами имеют те же двоичные зависимости, что и вы, которые вы использовали для сборки.
Чтобы ответить на вопрос об обновлении вашего вопроса о том, является ли наилучшей практикой отправку исходного кода и установить на нем хост-сервер; Я лично не думаю, что это хорошая идея. Причины, по которым я считаю, что это рискованно, заключается в том, что трудно быть абсолютно уверенным, что набор библиотек, которые вы устанавливаете, точно соответствует библиотекам, на которые вы протестировали, поэтому возможности развертывания могут быть непредсказуемыми. Эта проблема может быть раздражена webapps, так как вы, скорее всего, будете иметь один и тот же код, развернутый в нескольких продуктовых ящиках, которые также могут выйти из строя. В то время как сообщество perl делает замечательную работу, пытаясь выпустить код хорошего качества, который обратно совместим, когда что-то идет не так, как правило, довольно сложно разобраться. Вот почему разрабатывается картон, так как это создает кэш всех дистрибутивов, которые необходимо установить для замораживания в определенных версиях, чтобы вы могли предсказуемо развернуть свой код. Все это сказало; если вы с радостью принимаете этот риск и исправляете вещи, когда они ломаются, то локальная установка должна быть хорошей для вас. Тем не менее, по крайней мере, я настоятельно рекомендую установить локальную:: lib, чтобы вы могли создать резервную копию старой локальной библиотеки перед установкой обновлений, чтобы у вас была точка отката, если что-то перепуталось.
- [1] https://metacpan.org/module/Carton (будьте осторожны, он все еще находится в тяжелом развитии)
- [2] https://metacpan.org/module/local::lib
- [3] https://metacpan.org/module/perlbrew