安装 Perl Web 应用程序的最佳系统是什么？

Question

It seems that most of the installers for Perl are centered around installing Perl modules, not applications. Things like ExtUtils::MakeMaker and Module::Build are very well suited for modules, but require some additional work for Web Apps.

Ideally it would be nice to be able to do the following after checking out the source from the repository:

• Have missing dependencies detected
• Download and install dependencies from CPAN
• Run a command to "Build" the source into a final state (perform any source parsing or configuration necessary for the local environment).
• Run a command to install the built files into the appropriate locations. Not only the perl modules, but also things like template (.tt) files, and CGI scripts, JS and image files that should be web-accessible.
• Make sure proper permissions are set on installed files (and SELinux context if necessary).

Right now we have a system based on Module::Build that does most of this. The work was done by done by my co-worker who was learning to use Module::Build at the time, and we'd like some advice on generalizing our solution, since it's fairly app-specific right now. In particular, our system requires us to install dependencies by hand (although it does detect them).

Is there any particular system you've used that's been particularly successful? Do you have to write an installer based on Module::Build or ExtUtils::MakeMaker that's particular to your application, or is something more general available?

EDIT: To answer brian's questions below:

• We can log into the machines
• We do not have root access to the machines
• The machines are all (ostensibly) identical builds of RHEL5 with SELinux enabled
• Currently, the people installing the machines are only programmers from our group, and our source is not available to the general public. However, it's conceivable our source could eventually be installed on someone else's machines in our organization, to be installed by their programmers or systems people.
• We install by checking out from the repository, though we'd like to have the option of using a distributed archive (see above).

Answer 1

The answer suggesting RPM is definitely a good one. Using your system's package manager can definitely make your life easier. However, it might mean you also need to package up a bunch of other Perl modules.

You might also take a look at Shipwright . This is a Perl-based tool for packaging up an app and all its Perl module dependencies. It's early days yet, but it looks promising.

As far as installing dependencies, it wouldn't be hard to simply package up a bunch of tarballs and then have you Module::Build-based solution install them. You should take a look at pip , which makes installing a module from a tarball quite trivial. You could package this with your code base and simply call it from your own installer to handle the deps.

I question whether relying on CPAN is a good idea. The CPAN shell always fetches the latest version of a distro, rather than a specific version. If you're interested in ensuring repeatable installs, it's not the right tool.

Answer 2

What are your limitations for installing web apps? Can you log into the machine? Are all of the machines running the same thing? Are the people installing the web apps co-workers or random people from the general public? Are the people installing this sysadmins, programmers, web managers, or something else? Do you install by distributed an archive or checking out from source control?

For most of my stuff, which involves sysadmins familiar with Perl installing in control environments, I just use MakeMaker . It's easy to get it to do all the things you listed if you know a little about MakeMaker . If you want to know more about that, ask a another question. ;) Module::Build is just as easy, though, and the way to go if you don't already like using MakeMaker .

Module::Build would be a good way to go to handle lots of different situations if the people are moderately clueful about the command line and installing software. You'll have a lot of flexibility with Module::Build , but also a bit more work. And, the cpan tool (which comes with Perl), can install from the current directory and handle dependencies for you. Just tell it to install the current directory:

 $ cpan .

If you only have to install on a single platorm, you'll probably have an easier time making a package in the native format. You could even have Module::Build make that package for you so the developers have the flexibility of Module::Build , but the installers have the ease of the native process. Sticking with Module::Build also means that you could create different packages for different platforms from a single build tool.

If the people installing the web application really have no idea about command lines, CPAN, and other things, you'll probably want to use a packager and installer that doesn't scare them or make them think about what is going on, and can accurately report problems to you automatically.

As Dave points out, using a real CPAN mirror always gets you the latest version of a module, but you can also make your own "fake" CPAN mirror with exactly the distributions you want and have the normal CPAN tools install from that. For our customers, we make "CPAN on a CD" (although thumb drives are good now too). With a simple "run me" script everything gets installed in exactly the versions they need. See, for instance, my Making my own CPAN talk if you're interested in that. Again, consider the audience when you think about that. It's not something you'd hand to the general public.

Good luck, :)

Answer 3

I'd recommend seriously considering a package system such as RPM to do this. Even if you're running on Windows I'd consider RPM and cygwin to do the installation. You could even set up a yum or apt repository to deliver the packages to remote systems.

If you're looking for a general installer for customers running any number of OSes and distros, then the problem becomes much harder.

Answer 4

Take a look at PAR .

Jonathan Rockway as a small section on using this with Catalyst in his book.