[Catalyst] Catalyst and Puppet

[Tomas Doran]

On 9 Nov 2011, at 16:23, Nick wrote:

> On 09/11/11 10:20, Tomas Doran wrote:
>> Not specifically, as the place I use puppet does everything  
>> with .deb packages.
>
> Noted. Indeed, it's useful simply to know what other people's  
> strategies are.

We pin the packages for applications in production to the officially  
'blessed' version, and our staging installs whatever's latest (and  
does the right thing to restart services etc).

I run almost all the apps as fastcgis, and I have a set of modules  
which work with either apache or nginx and can generate you a  
(trivial) vhost by just saying catalyst::app { ... stuff ... }

Can share some of the pp code as an example if you want. It's not  
entirely nice enough to be reuseable, (e.g. as it has a chunk of per- 
company specific things in the templates it uses), but it works for me  
and could give you some ideas :)

However this stuff isn't that awesome in a number of ways - everything  
is packaged and installed in system - meaning only one version of an  
app can be on a machine at once, and if you have two apps with  
conflicting dependency requirements - you're kinda screwed...

> (We're using Puppet because it's got a relatively big user-base.  If  
> there was a
> comparable Perl alternative we might be using that instead.  I am a  
> bit
> surprised not to find one, since sys-admin is supposed to be one of  
> Perl's
> traditional domains.)

There's cfengine if one wants to be traditional :)

>> However using local::lib is perfectly reasonable here... However,  
>> are you
>> planning to deploy from git / svn, or are you planning to build  
>> a .tgz file
>> (with make dist) and upload it into your own minicpan mirror?
>
> Not yet determined.  The current scheme in use is antiquated, CVS- 
> based, highly
> manual, and collapsing under its own weight, so the aim is  
> effectively to
> re-invent the entire approach with shiny new tools.
>
> Some combination of Git and CPAN distro deployment seems likely.   
> Some of our
> code is designed to work as CPAN distros already.  Some ain't.

Well with this idea you'd have a CPAN mirror, and all your dists would  
carry (and install in a ShareDir or something?) their local::libs with  
them. When you had a set of app / local::lib that goes with it that  
you're happy with, you say make disttest && make dist and generate a  
tarball..

Your CPAN mirror has all your custom dists injected into it, and then  
you have some puppet code to setup a CPAN client for your local CPAN,  
and to install stuff (you can make it put stuff not into the system  
site-perl directories at this point - and as your apps carry their  
local-libs with them, you can have multiple versions of the same app  
with different dependencies installed and running at the same time).

> What we're looking for is examples of development and deployment  
> processes which
> are known to work, which we can adapt and/or cherry-pick from (as  
> well as cite
> when we need to justify the approach taken)...

Both strategies here are 'known to work'. I'm sure other people have  
different strategies that also work (you can install .debs to a custom  
location, and there is nothing to doing the 'shove local::lib in a  
sharedir' thing from working in a .deb package, for example).

How much flexibility does your environment need with regards to  
deployment? As none of this stuff is rocket surgery, but the amount of  
flexibility you need will determine the amount of tool-building you're  
going to have to do to have a standard automated process :)

Cheers
t0m