After testing my Catalyst application and deciding to deploy it I would like to package it up so I can easily pull it in on the staging and live servers, manage dependencies and easily roll-back via the flexibility of package versioning. As my production OS is Ubuntu I figured packaging it as a deb package would make most sense.
I am predicting I will have to create a second package of all my perl module dependencies as many are not provided by my distribution, or package them independently - though that may be a lot of work.
Does anyone have any experience of doing this - or a sane, similar alternative?
To build your own Debian packages out of CPAN packages:
Install Debian helper scripts
sudo apt-get install dh-make-perl
Download MODULE from CPAN and build Debian package
cpan2deb MODULE
dh-make-perl is actually the right tool to put CPAN modules into Debian packages. Together with apt-file it can even prepare proper dependencies for you.
About being able to "easily roll-back" though requires special attention to versioning or workflows. There are several approaches that might get your job done here:
If you can force-downgrade packages you have won already most of the time unless you have very specific maintainer scripts that do jobs on package upgrades - then you will have to make them able to handle the downgrade, too
If you have to go the regular upgrade-path, using approaches like using "< newversion>+rollback< oldversion>" or similar might be something to consider.
Dependency-packages are always a good idea for deployments to make sure no required package actually is missing. Also, you might want to invest some time in management frameworks like puppet, they might come handy here, too.
Related
Sorry if this is very newb question, I promise I did try this on my own.
As I develop a perl prototype I keep installing new CPAN modules I wish to use for the prototype to my local perl. I want to ensure when this program is deployed all these CPAN modules I'm using are installed on the production box as well.
I don't want to keep track of every new CPAN module I install during development and manually install each on production, I want to run a command and have all the appropriate modules loaded. In java world I would use something like Maven to list these dependencies and trust maven to handle fetching and ensuring my libraries are available. Does Perl have the equivalent?
I would kind of expect I can point cpan to my program and it could infer which modules are needed with basic static analysis and install them on the fly, but I haven't found the program or syntax to do so. can anyone point me to
The easiest way to do this is to load Webmin, which will report both native cpan modules, and modules loaded via yum or apt-get. Deploying the install is another discussion.
I am just starting to organize some stuff on the cluster and would like some advice on it. I posted a recent question How to organize Perl modules and got some good answers about what I was doing incorrectly. I was trying to install each perl module independently by setting the PREFIX for Makefile.PL each time to /path/to/lib/module-name/module-version/installation happens here.
For e.g. for a module JSON, I installed it like this:
perl Makefile.PL --PREFIX=/path/to/lib/perl5/5.22.1/JSON/2.53
make
make test
make install
For module Data-UUID, I did it like this:
perl Makefile.PL --PREFIX=/path/to/lib/perl5/5.22.1/Data-UUID/1.221
make
make test
make install
So it made a directory JSON/2.53 in /path/to/lib/perl5/5.22.1 and that's where it installed the package. But because I change the PREFIX for each individual module, I have to set the PATH in the bash_profile accordingly, which is kind of messy.
My main goal to do this was for version control. In a hypothetical scenario where different versions work for two of your teammates, say JSON/2.52 works for X and JSON/2.53 works for Y, how do you control for versions without having to ask them to install their versions locally? In another scenario, what if a version worked for you 3 months back and the updated version doesn't work for you anymore? How do you keep track of versions if you install everything in one directory?
I also have more questions on the module local::lib but I will post it as another question.
Thanks!
Maintaining concurrent versions of CPAN modules is asking for grief. I would suggest instead - don't, use docker for anything that's got any sort of deployment. That way you can have local installation of stuff + deps in an isolated container.
It's a bit like early days yet on docker, but they're a significant amount of enthusiasm and support for it from some very big names.
Personally I'm just using it to bundle up "mojolicious" perl webapps behind a reverse proxy, and maintain their dependencies as a self contained installation (which I can run/test/deploy autonomously)
I'm working on a Perl app that's intended to be deployed using Module::Build. I've need to install a number of modules through CPAN because they weren't available through Ubuntu's package manager—or, more correctly, the internal apt-get mirror all our servers use. While this is all well and good on our development server, IT is (understandably) reluctant to run code on production machines that isn't cached or otherwise controlled in-house.
As we don't currently have a CPAN mirror, this basically means that I need to get all of these non-Ubuntu modules into one place so they can be archived and/or committed to version control. The ideal solution would be to check the utility out from source control, change a couple config variables for databases and such, maybe run a build/install command, and be done. Fortunately, the development server is a clone of the production server, so modules using XS or other architecture-specific features shouldn't cause an issue.
I think the cleanest way to handle this would be checking in source tarballs for the modules I need and setting Module::Build to use those to resolve its dependencies instead of looking to CPAN, but I don't see an option for that. Is this something that's doable, or is there another way to round up all the modules I need for an essentially offline deployment?
As mentioned in the comments above, Pinto may suit your needs as it creates your own CPAN repo.
Pinto has two primary goals. First, Pinto seeks to address the problem
of instability in the CPAN mirrors. Distribution archives are
constantly added and removed from the CPAN, so if you use it to build
a system or application, you may not get the same result twice.
Second, Pinto seeks to encourage developers to use the CPAN toolchain
for building, testing, and dependency management of their own local
software, even if they never plan to release it to the CPAN.
Pinto accomplishes these goals by providing tools for creating and
managing your own custom repositories of distribution archives. These
repositories can contain any distribution archives you like, and can
be used with the standard CPAN toolchain. The tools also support
various operations that enable you to deal with common problems that
arise during the development process.
Second Answer
Alternatively, if you are only going to deploy to Ubuntu, you can turn CPAN modules - and your own into Debian packages with dh-make-perl. You can then host them in your own repo with reprepro. The beauty of this is that you can update the packages and do a
apt-get update
apt-get upgrade
on the client machines, so long as they have your own repo as a source
Check out Stratopan and Carton.
Also see:
Deploying Perl Application
How can I manage Perl module dependencies?
I'm not sure how common it is, but I've been using perlbrew and Pinto together to solve some of the issues you are talking about.
With perlbrew, I'm not interacting with the "system" perl. There is an application perl and a system perl, and there is no risk of me installing a later version of a module that somehow interferes with something the system perl was doing.
With Pinto, I have archived versions of the CPAN modules that I know will work.
When I deploy, I build a perlbrew perl (with an alias like "prod" or something) and then I install all the necessary modules into that perlbrew perl using the Pinto repository. I currently facilitate this with a cpan bundle module (that module also goes into the Pinto repo) so you can just install the bundle from the repository and it automatically puts all your dependencies in.
I'm tasked with replicating a production environment to create many test/sit environments.
One of the things I need to do is build up Perl, with all the modules which have been installed (including internal and external modules) over the years. I could just use CPAN.pm autobundle, but this will result in the test environment having much newer versions of the external modules that production has.
What is the easiest/best way to get and install (a lot of) version specific Perl modules.
bdfoy has the best large scale solution, but if you just want to install a few modules you can ask the CPAN shell to install a specific distribution by referencing a path to a tarball (relative to the top of the CPAN tree).
cpan> install MSCHWERN/Test-Simple-0.62.tar.gz
Throw a URL to BackPAN into your URL list and you can install any older version.
cpan> o conf urllist push http://backpan.perl.org/
This is in the CPAN.pm FAQ under "how do I install a 'DEVELOPER RELEASE' of a module?"
cpan install App::cpanminus
cpanm Your::Module#1.23
(Carton, as referenced in other answers, uses cpanm underneath to resolve explicit version requirements.)
Make your own CPAN mirror with exactly what you want. Stratopan.com, a service, and Pinto, tools that's built on top of, can help you do that.
The CPAN tools only install the latest version of any distribution because PAUSE only indexes the latest version. However, you can create your own, private CPAN that has exactly the distributions that you want. Once you have your own CPAN mirror with only what you want, you point your CPAN tools at only that mirror so it only installs those versions. More on that in a minute.
Now, you want to have several versions of that. You can create as many mirrors as you like, and you can also put the mirrors in source control so you can check out any version of the mirror that you like.
Tools such as CPAN::Mini::Inject can help you set up your own CPAN. Check out my talks on Slideshare for the basic examples, and some of my videos on Vimeo for some of the demonstrations. Look at anything that has "CPAN" or "BackPAN" in the title. I think I might have some stuff about it in The Perl Review too, or should by the next issue. :)
Lately, I've been working on a program called dpan (for DarkPAN) that can look at random directories, find Perl distributions in them, and create the structure and index files that you need. You run dpan, you get a URL to point your CPAN client toward, and off you go. It's part of my MyCPAN-Indexer project, which is in Github. It's not quite ready for unsupervised public use because I mostly work with corporate clients to customize their setup. If you're interested in that, feel free to ask me questions though.
Also, I recently released CPAN::PackageDetails that can help you build the right index file. It's still a bit young too, but again, if you need something special, just ask.
[It's almost five years on and this is a well-asked and well-answered question that has had a lot of views. Since this page must still come up in Google searches, an update can't hurt.]
Carton is worth mentioning here. Carton is a relatively recent tool in the same style as App::cpanminus, App::cpanoutdated, perlbrew, et. al. The author (Miyagawa) calls it "alpha" quality, but even in its current state carton helps simplify the maintenance of multiple environments of version tuned modules across machines.
Pinto too is another recent tool relevant to some of the responses (in fact one of the respondents is a contributor).
Stratopan.com is another alternative. Stratopan provides private CPANs in the cloud. You can fill your Stratopan repository with specific versions of modules (and their dependencies) and then install them using the standard Perl tool chain. The repository changes only when you decide to change it, so you'll get always get the versions of the modules that you want.
Disclaimer: I operate Stratopan.
It seems that creating a cpanfile listing all your modules and desired versions (using the == <version> syntax to lock it to a specific release) could serve well here, too. That would mean using Carton or cpanm for installing the modules.
Doing this would have the benefit of being able to quickly/easily tweak the file to test upgrading specific modules in a dev or staging environment - something that a private CPAN mirror wouldn't let you do (without creating multiple mirrors).
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).
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.
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, :)
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.
Take a look at PAR.
Jonathan Rockway as a small section on using this with Catalyst in his book.