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
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
