部署 Perl 应用程序的最佳实践是什么？假设您正在部署到安装了少量 CPAN 模块的普通盒子上。理想的构建、部署方法是什么？ Module::Build、ExtUtils::MakeMaker，其他？我正在从那些针对大型应用程序重复执行此操作的人那里寻找一些最佳实践想法。
该应用程序正在部署到服务器上。它不是 CPAN 或脚本。它实际上是一个 PSGI Web 应用程序。也就是说，大量的 Perl 包。
我目前有一个部署脚本，它使用 Net::SSH::Expect 通过 SSH 连接到新服务器，安装一些工具并配置服务器，然后从源代码管理中拉取所需的应用程序分支。这感觉不错，但这是最佳实践吗？
下一步是构建应用程序。跟踪和管理依赖项、从 CPAN 安装这些依赖项以及确保应用程序准备好运行的最佳实践是什么？
谢谢
What are the best practices for deploying a Perl application? Assume that you are deploying onto a vanilla box with little CPAN module installation. What are the ideal build, deploy methods? Module::Build, ExtUtils::MakeMaker, other? I am looking for some best practice ideas from those who have done this repeatedly for large scale applications.
The application is deploying onto a server. It's not CPAN or a script. It's actually a PSGI web application. That is, a ton of Perl packages.
I currently have a deployment script that uses Net::SSH::Expect to SSH into new servers, install some tools and configure the server, then pull down the desired application branch from source control. This feels right, but is this best practice?
The next step is building the application. What are the best practices for tracking and managing dependencies, installing those dependencies from CPAN, and ensuring the application is ready to run?
Thanks
发布评论
评论（3）
我工作的公司目前为每个 CPAN 和 RPM 构建 RPM。安装到系统 site_perl 目录中的应用程序的内部依赖项（相当多的软件包！）。这有很多问题：
我们不再为每个依赖项构建 RPM，而是计划使用 carton [1] 为我们部署的每个应用程序构建一个完全独立的 Perl 库。我们正在将这些库构建到系统包中，但是如果您不想使用包管理器，您可以轻松地将它们压缩并手动将它们复制到适当的位置。
carton 的问题是，您需要设置一个内部 CPAN 镜像，如果您的应用程序依赖于 CPAN 之外的模块，则可以将内部依赖项安装到该镜像中。如果您不想处理这个问题，您始终可以手动将所需的库安装到 local::lib [2] 或 perlbrew [3] 中，并将生成的库打包以部署到您的生产环境中。
对于所有规定的解决方案，请务必小心 XS perl 库。您需要在与要部署到的主机相同的架构上构建 cartons/local:libs/perlbrews ，并确保您的生产盒具有与您用于构建的相同的二进制依赖项。
回答您关于源签出并安装到生产主机是否是最佳实践的问题的更新；我个人认为这不是一个好主意。我认为它有风险的原因在于，很难完全确定您安装的库集是否与您测试的库完全一致，因此部署可能是不可预测的。 Web 应用程序可能会加剧此问题，因为您很可能将相同的代码部署到多个生产环境中，而这些环境也可能不同步。虽然 Perl 社区在尝试发布向后兼容的高质量代码方面做得非常出色，但当出现问题时，通常需要付出很大的努力才能解决问题。这就是开发 carton 的原因，因为这会创建您需要在特定版本上冻结安装的所有发行版 tarball 的缓存，以便您可以可预测地部署代码。尽管如此；如果您愿意接受这种风险并在出现问题时进行修复，那么本地安装应该适合您。但是，至少我强烈建议安装到本地::lib，以便您可以在安装更新之前备份旧的本地库，以便在出现问题时有一个回滚点。
The company that I work at currently build RPMs for each and every CPAN & Internal dependency of an application (quite a lot of packages!) that install into the system site_perl directory. This has a number of problems:
We are moving away from building RPMs for every dependency and instead planning to use carton [1] to build a completely self contained perl library for every application we deploy. We're building these libraries into system packages, but you could just as easily tarball them up and manually copy them places if you don't want to deal with a package manager.
The problem with carton is that you'll need to setup an internal CPAN mirror that you can install your internal dependencies to if your application depends on modules that aren't on the CPAN. If you don't want to deal with that, you could always just manually install libs you need into local::lib [2] or perlbrew [3] and package the resulting libraries up for deployment to your production boxes.
With all of the prescribed solutions, be very careful of XS perl libs. You'll need to build your cartons/local:libs/perlbrews on the same architecture as the host you're deploying to and make sure your productions boxes have the same binary dependencies as what you used to build.
To answer the update to your question about whether it is best practice to source checkout and install onto you production host; I personally don't think that it is a good idea. The reasons why I believe that it is risky lays in the fact that it is hard to be completely sure that the set of libraries that you install exactly lines up to the libraries that you tested against, so deployments have the potential to be unpredictable. This issue can be exasperated by webapps as you are very likely to have the same code deployed to multiple production boxes that can get out of synch, also. While the perl community does a wonderful job of trying to release good quality code that is backwards compatible, when things go wrong it is normally quite an effort to figure things out. This is why carton is being developed, as this creates a cache of all the distribution tarballs that you need to install frozen at specific versions so that you can predictably deploy your code. All of that said though; if you are happy to accept that risk and fix things when they break then locally installing should be fine for you. However, at the very minimum I would strongly suggest installing to a local::lib so that you can back up the old local lib before installing updates so you have a rollback point if things get messed up.
如果它具有一些重要的 CPAN 依赖性，那么您可能需要编写一个使用 CPAN::Shell 的小脚本来安装必要的模块，或者编辑您的应用程序，以便它反映文件的
BUILD_REQUIRES部分中的必要依赖项。If it has some significant CPAN dependencies, then you might want to either write a small script that uses
CPAN::Shellto install the necessary modules or edit theMakefile.PLof your application so that it reflects the necessary dependencies in theBUILD_REQUIRESportion of the file.你可以看一下 sparrowdo 一个 perl6 配置管理工具，它附带了一些与 perl5 部署相关的方便插件，例如安装 cpan 软件包或部署 psgi 应用程序。
更新：此链接 https://dev.to/melezhik/deploying- perl5-application-by-sparrowdo-9mb 可能会有用。
披露 - 我是工具作者。
You may take a look at sparrowdo a perl6 configuration management tool, it comes with some handy plugins related to perl5 deployment, like installing cpan packages or deploying psgi application.
Update: this link https://dev.to/melezhik/deploying-perl5-application-by-sparrowdo-9mb could be useful.
Disclosure - I am the tool author.