我工作的公司目前为安装到系统 site_perl 目录中的应用程序(相当多的包!)的每个 CPAN 和内部依赖项构建 RPM。这有很多问题:
- 随着版本在 CPAN 上的碰撞,不断构建 RPM 非常耗时。
- 将自己绑定到系统 perl 意味着您可以任由您的发行版来决定或破坏您的 perl(在 Centos 5 中,我们有一个最大的 perl 版本 5.8.8 !)。
- 如果您将多个应用程序部署到同一主机,则为所有应用程序使用一个 perl 库意味着如果不重新测试主机的每个应用程序,升级依赖项可能会很危险。我们部署了很多独立的发行版,都具有不同程度的维护关注,所以这对我们来说很重要。
我们不再为每个依赖项构建 RPM,而是计划使用 carton [1] 为我们部署的每个应用程序构建一个完全自包含的 perl 库。我们正在将这些库构建到系统包中,但如果您不想与包管理器打交道,您可以轻松地将它们打包并手动复制它们的位置。
carton 的问题在于,如果您的应用程序依赖于不在 CPAN 上的模块,您将需要设置一个内部 CPAN 镜像,您可以将内部依赖项安装到该镜像上。如果您不想处理这个问题,您总是可以手动将所需的库安装到 local::lib [2] 或 perlbrew [3] 中,然后将生成的库打包以部署到您的生产环境中。
对于所有规定的解决方案,请非常小心 XS perl 库。您需要在与您要部署到的主机相同的架构上构建您的 cartons/local:libs/perlbrews,并确保您的生产盒具有与您过去构建的相同的二进制依赖项。
回答有关您的问题的更新,即采购结帐并安装到您的生产主机上是否是最佳实践; 我个人认为这不是一个好主意。我认为这是有风险的原因在于,很难完全确定您安装的库集与您测试的库完全一致,因此部署可能无法预测。webapps 可能会激怒这个问题,因为您很可能将相同的代码部署到多个生产机器上,这些机器也可能不同步。虽然 perl 社区在尝试发布向后兼容的高质量代码方面做得非常出色,但当出现问题时,通常需要付出很大的努力才能解决问题。这就是开发 carton 的原因,因为这会创建一个缓存,其中包含您需要在特定版本中冻结安装的所有分发 tarball,以便您可以预测地部署您的代码。尽管如此,所有这些都说了;如果您乐于接受这种风险并在故障时修复问题,那么本地安装对您来说应该没问题。但是,至少我会强烈建议安装到 local::lib,这样您就可以在安装更新之前备份旧的本地 lib,这样如果事情搞砸了,您就有一个回滚点。
- 纸盒
- 本地::lib
- perlbrew