Развертывание приложения Perl

Каковы наилучшие методы развертывания приложения Perl? Предположим, что вы развертываете на ванильном ящике с небольшой установкой модуля CPAN. Каковы идеальные методы сборки, развертывания? Модуль:: Build, ExtUtils:: MakeMaker, другие? Я ищу некоторые идеи лучшей практики от тех, кто неоднократно делал это для крупномасштабных приложений.

Приложение развертывается на сервере. Это не CPAN или script. Это фактически веб-приложение PSGI. То есть, тонна пакетов Perl.

В настоящее время у меня есть развертывание script, которое использует Net:: SSH:: Expect для SSH на новые серверы, устанавливает некоторые инструменты и настраивает сервер, а затем вытаскивает нужную ветвь приложения из исходного элемента управления. Это правильно, но это лучшая практика?

Следующим шагом является создание приложения. Каковы наилучшие методы отслеживания и управления зависимостями, установка этих зависимостей из CPAN и обеспечение готовности приложения к запуску?

Спасибо

ОТВЕТЫ

Ответ 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, чтобы вы могли создать резервную копию старой локальной библиотеки перед установкой обновлений, чтобы у вас была точка отката, если что-то перепуталось.

Ответ 2

Если у него есть некоторые существенные зависимости CPAN, вы можете либо написать небольшой script, который использует CPAN::Shell для установки необходимых модулей, либо для редактирования Makefile.PL вашего приложения, чтобы он отражал необходимые зависимости в BUILD_REQUIRES часть файла.

Ответ 3

Вы можете взглянуть на sparrowdo инструмент управления конфигурацией perl6, он поставляется с некоторыми удобными плагинами, связанными с развертыванием perl5, например, установкой cpan пакетов или развертывания приложения psgi.

Обновление: эта ссылка https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb может быть полезна.

Раскрытие информации - я автор инструмента.