问题描述
部署Perl应用程序的最佳做法是什么？假设您正在部署少量安装CPAN模块的香草盒。什么是理想的构建，部署方法？ Module :: Build，ExtUtils :: MakeMaker，other？我正在寻找那些为大规模应用程序反复进行的一些最佳实践创意。
应用程序正在部署到服务器上。它不是CPAN或脚本。它实际上是一个PSGI Web应用程序。那就是一大堆Perl软件包。
我目前有一个部署脚本，它使用Net :: SSH :: Expect将SSH连接到新的服务器中，安装一些工具并配置服务器，然后从源代码控制下拉所需的应用程序分支。这是最好的做法吗？
下一步是构建应用程序。跟踪和管理依赖关系的最佳做法是什么，从CPAN安装这些依赖关系，并确保应用程序准备好运行？
谢谢
我正在为每一个CPAN&一个应用程序的内部依赖（相当多的包！）安装到系统的site_perl目录中。这有一些问题：
- 随着版本在CPAN上碰撞，继续构建RPMs是耗时的。
- 将系统perl绑在一起意味着你正在分配你的分配，以打破你的perl（在Centos 5中，我们有一个最大perl版本的5.8.8！）。
- 如果您将多个应用程序部署到同一台主机，对所有应用程序都安装了一个perl库，这意味着升级依赖关系可能是危险的，无需重新测试主机的每个应用程序。我们部署了很多不同程度的维护注意事项，所以这对我们来说很重要。
我们是远离建立每个依赖关系的RPM，而是计划使用纸箱[1]为我们部署的每个应用程序构建一个完全自包含的perl库。我们正在将这些库构建到系统包中，但如果您不想处理包管理器，您可以轻松地将其压缩并手动复制它们。
纸箱的问题是，您需要设置一个内部CPAN镜像，如果应用程序依赖于不在CPAN上的模块，则可以安装内部依赖关系。如果您不想处理这些，您可以随时手动将需要的libs安装到local :: lib [2]或perlbrew [3]中，并将生成的库打包到部署到生产箱中。
使用所有规定的解决方案，请谨慎使用XS perl库。您将需要在与您部署的主机相同的架构上构建您的纸箱/本地：libs / perlbrews，并确保您的制作框具有与您以前构建的相同的二进制依赖关系。
要回答关于您的问题的更新是否是最佳做法来源结帐并安装到生产主机;我个人认为这不是一个好主意。我认为这是有风险的原因，因为很难完全确定您安装的一组库与您测试的库完全一致，因此部署有可能是不可预测的。这个问题可能会被webapps吓倒，因为您很可能将相同的代码部署到可以脱离同步的多个生产箱中。虽然perl社区做了一个很好的工作，试图发布质量好的向后兼容的代码，当出现问题时，通常会很努力地弄清楚。这就是为什么正在开发纸箱，因为这会创建一个缓存，您需要在特定版本中安装冻结的所有分发tarball，以便可以预见部署代码。所有这一切说如果您乐意接受这种风险并在遇到困难时解决问题，那么本地安装应该对您而言是正确的。然而，至少我会强烈建议安装到本地的:: lib，以便您可以在安装更新之前备份旧的本地lib，以便在遇到困扰时有一个回滚点。 / p>
- [1] （要小心，还在发展中）
- [2]
- [3]
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
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:
- It is time consuming to keep building RPMs as versions get bumped across the CPAN.
- Tying yourself to the system perl means that you are at the mercy of your distribution to make or break your perl ( in Centos 5 we have a max perl version of 5.8.8 ! ).
- If you have multiple applications deployed to the same host, having a single perl library for all applications means that upgrading dependencies can be dangerous without retesting every application of the host. We deploy quite a lot of separate distributions all with varying degrees of maintenance attention, so this is a big deal for us.
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.
- [1] https://metacpan.org/module/Carton (Be careful; it is still under heavy development )
- [2] https://metacpan.org/module/local::lib
- [3] https://metacpan.org/module/perlbrew
这篇关于部署Perl应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！