部署 Perl 应用程序的最佳实践是什么？假设您正在部署到安装了少量 CPAN 模块的普通盒子上。理想的构建、部署方法是什么？ Module::Build、ExtUtils::MakeMaker，其他？我正在从那些针对大型应用程序重复执行此操作的人那里寻找一些最佳实践想法。
该应用程序正在部署到服务器上。它不是 CPAN 或脚本。它实际上是一个 PSGI Web 应用程序。也就是说，大量的 Perl 包。
我目前有一个部署脚本，它使用 Net::SSH::Expect 通过 SSH 连接到新服务器，安装一些工具并配置服务器，然后从源代码管理中拉取所需的应用程序分支。这感觉不错，但这是最佳实践吗？
下一步是构建应用程序。跟踪和管理依赖项、从 CPAN 安装这些依赖项以及确保应用程序准备好运行的最佳实践是什么？
Thanks
我工作的公司目前为安装到系统 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 ，并确保您的生产框具有与您用于构建的相同的二进制依赖项。
回答有关源签出并安装到生产主机是否是最佳实践的问题的更新;我个人认为这不是一个好主意。我认为它有风险的原因在于，很难完全确定您安装的库集是否与您测试的库完全一致，因此部署可能是不可预测的。 Web 应用程序可能会加剧此问题，因为您很可能将相同的代码部署到多个生产环境中，而这些环境也可能不同步。虽然 Perl 社区在尝试发布向后兼容的高质量代码方面做得非常出色，但当出现问题时，通常需要付出很大的努力才能解决问题。这就是开发 carton 的原因，因为这会创建您需要在特定版本上冻结安装的所有发行版 tarball 的缓存，以便您可以可预测地部署代码。尽管如此；如果您愿意接受这种风险并在出现问题时进行修复，那么本地安装应该适合您。不过，至少我会强烈建议安装到 local::lib ，以便您可以在安装更新之前备份旧的本地库，以便在出现问题时有一个回滚点。
- Carton https://metacpan.org/module/Carton
- 本地::lib https://metacpan.org/module/local::lib
- perlbrew https://metacpan.org/module/perlbrew
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
