部署Perl应用程序

时间:2012-02-11 03:45:26

标签: perl deployment psgi

部署Perl应用程序的最佳做法是什么?假设您正在部署到安装了少量CPAN模块的香草盒上。什么是理想的构建,部署方法? Module :: Build,ExtUtils :: MakeMaker,其他?我正在寻找那些为大规模应用反复做过的人的最佳实践想法。

应用程序正在部署到服务器上。它不是CPAN或脚本。它实际上是一个PSGI Web应用程序。也就是说,大量的Perl包。

我目前有一个部署脚本,它使用Net :: SSH :: Expect来SSH到新服务器,安装一些工具并配置服务器,然后从源代码控制中下拉所需的应用程序分支。这感觉很好,但这是最好的做法吗?

下一步是构建应用程序。跟踪和管理依赖项,从CPAN安装这些依赖项以及确保应用程序已准备好运行的最佳实践是什么?

由于

3 个答案:

答案 0 :(得分:11)

我目前工作的公司目前为每个CPAN& amp;安装到系统site_perl目录中的应用程序(相当多的软件包!)的内部依赖性。这有很多问题:

  • 随着版本在CPAN上受到影响,继续构建RPM非常耗时。
  • 将自己绑定到系统perl意味着你受到你的发行版的支配,无论是制造还是破坏你的perl(在Centos 5中我们有最高perl版本的5.8.8!)。
  • 如果您将多个应用程序部署到同一主机,则为所有应用程序提供单个perl库意味着升级依赖项可能会很危险,而无需重新测试主机的每个应用程序。我们部署了大量独立的发行版,并且都有不同程度的维护注意,所以这对我们来说是个大问题。

我们正在逐步为每个依赖项构建RPM,而是计划使用carton [1]为我们部署的每个应用程序构建一个完全自包含的perl库。我们正在将这些库构建到系统包中,但如果您不想处理包管理器,您可以轻松地将它们压缩并手动复制它们。

纸箱的问题在于,如果您的应用程序依赖于不在CPAN上的模块,您将需要设置一个内部CPAN镜像,您可以安装内部依赖项。如果您不想处理它,您可以随时手动将所需的库安装到local :: lib [2]或perlbrew [3]中,并将生成的库打包并部署到生产箱中。

使用所有规定的解决方案,要非常小心XS perl libs。您需要在与您正在部署的主机相同的架构上构建您的cartons / local:libs / perlbrews,并确保您的制作盒具有与您以前构建的相同的二进制依赖关系。

要回答您的问题更新,了解是否最佳做法是将结帐并安装到您的生产主机上;我个人认为这不是一个好主意。我认为它存在风险的原因在于,很难完全确定您安装的库集完全符合您测试的库,因此部署可能无法预测。 Web应用程序可能会激怒此问题,因为您很可能将相同的代码部署到可能不同步的多个生产框中。虽然perl社区在尝试发布向后兼容的高质量代码方面做得非常出色,但当出现问题时,通常需要花费很多精力来解决问题。这就是开发纸盒的原因,因为这会创建一个缓存,您需要在特定版本中冻结安装所有分发tar包,以便您可以预测地部署代码。所有这些虽然说;如果你很乐意接受这种风险并在它们破裂时解决问题,那么本地安装应该没问题。但是,至少我会强烈建议安装到本地:: lib,这样你就可以在安装更新之前备份旧的本地库,这样如果事情搞砸就有了回滚点。< / p>

答案 1 :(得分:3)

如果它有一些重要的CPAN依赖关系,那么您可能要编写一个使用CPAN::Shell的小脚本来安装必要的模块或编辑应用程序的Makefile.PL以便它反映必要的文件的BUILD_REQUIRES部分中的依赖项。

答案 2 :(得分:0)

您可以查看sparrowdo perl6配置管理工具,它附带一些与perl5部署相关的便捷插件,如安装cpan软件包或部署psgi应用程序。

更新:此链接https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb可能很有用。

披露 - 我是工具作者。