2012-02-11 171 views
14

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

该应用程序正在部署到服务器上。这不是CPAN或脚本。它实际上是一个PSGI网络应用程序。那就是,大量的Perl软件包。

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

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

感谢

回答

3

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

11

我工作的公司目前为每个CPAN构建RPMs安装到系统site_perl目录中的应用程序的内部依赖关系(相当多的包!)。这有许多问题:

  • 当版本在CPAN上碰撞时,保持构建RPM非常耗时。
  • 将你自己绑定到系统perl意味着你受到你的发行版的制约或者破坏你的perl(在Centos 5中我们有一个最大的perl版本5.8.8!)。
  • 如果您将多个应用程序部署到同一个主机,那么对于所有应用程序拥有一个perl库意味着如果不重新测试主机的每个应用程序,那么升级依赖关系可能很危险。我们部署了很多单独的发行版,并且都有不同程度的维护注意力,所以这对我们来说是很重要的。

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

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

对于所有规定的解决方案,要非常小心XS perl库。您需要在与要部署的主机相同的架构上构建您的纸箱/本地:libs/perlbrews,并确保您的产品盒具有与您以前构建的相同的二进制相关性。

要回答有关是否最佳实践来源检出并安装到生产主机上的更新问题;我个人认为这不是一个好主意。我认为这样做有风险的原因在于,很难完全确定您安装的一系列库与您所测试的库完全一致,因此部署有可能无法预测。 Web应用程序可能会激怒这个问题,因为您很可能会将相同的代码部署到可能不同步的多个生产框。虽然perl社区在尝试发布向后兼容的高质量代码方面做得非常出色,但当出现问题时,通常很难找出结果。这就是为什么正在开发纸箱的原因,因为这会创建一个缓存所有需要在特定版本中冻结的分发tarball,以便可预测地部署您的代码。尽管如此,如果您很乐意接受这种风险并在事件发生时解决问题,那么本地安装应该适合您。但是,至少我会强烈建议将安装到local :: lib,这样您可以在安装更新之前备份旧的本地库,以便在事情搞糟时有回滚点。

+1

+1上“非常小心的XS Perl库” – tangent 2012-02-11 17:46:19

+0

我想也许我们指的是两个不同的东西。我正在讨论如何从中央源代码控制系统(如GitHub)提取特定分支或“版本”的应用程序代码。看来你是指自己的依赖关系,即CPAN包。我同意需要非常小心地确保您的CPAN模块版本在各个节点(包括您的开发/登台环境)中保持一致,但是在部署期间将特定的源代码分支拉到每个节点似乎是确保应用软件本身。 – MadHacker 2012-02-12 14:29:54

+0

还有一个问题。在使用Carton的经验中,处理依赖关系的依赖性有多好?意思是说,如果我的Makefile.PL只包含我的应用程序显式“需要”或“使用”的软件包,Carton在分析这些模块的依赖性方面有多好? – MadHacker 2012-02-12 16:49:03