Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Application deploymentt

by Anonymous Monk
on Feb 07, 2012 at 13:05 UTC ( #952273=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hello Monks,

What is the best (and ideologicaly correct) way to deploy application dependencies. I want to meet following requirements:

- Fast deployment. No cpan? Maybe i should distribute app with local::lib and put there all deps?

- Some of dependencies should be of specific version - latest versions are not always good.

- I use DBIx::Class, and it would be really cool to have migrations like in Rails. Any advice what should I use?

- What possible problems I may encounter while doing this?

Thanks

Comment on Application deploymentt
Re: Application deploymentt
by JavaFan (Canon) on Feb 07, 2012 at 13:20 UTC
    What is the best (and ideologicaly correct) way to deploy application dependencies.
    First question: deploy where? A set of machines you have total control over? Some machines internal to the company? All identical machines? Random machines worldwide running random OSses?

    Second question: deploy when? Automatically when a new version is available? Pushed on demand? Pulled on demand? Does it get rolled out one-machine at the time? All machines? Some machines?

    Third question: have you exhausted all ready made tools and solutions already available? Why aren't they working for you? My "best" way usually does not mean "not using what's already there".

      Servers. Different OSes CentOS/Gento/Debian. Later I plan to use same os everywhere if it will be possible. Yep, total control, internal company

      Deployment when needed. When new feature is ready it pulled to server from git repo. Rarely - tgz. Different branches can be rolled out separately. Also test deployments

      I have encountered two problems: raid failure on one of prod servers where we had no backup. So it was pretty slow and painfull to install all deps and get box running asap.

      Second - during fresh install one of deps had memory leak in version that was automatically fetched from cpan. Took some time to get it working.

        ...raid failure on one of prod servers where we had no backup...

        Ok, really? That isn't a problem with CPAN or modules. That is just being cheap and getting burned by it.

        ...during fresh install one of deps had memory leak in version...

        At first glance I thought this was the more legitimate reason to avoid using CPAN but then again, how do you know that any shared library you are upgrading to on a production system isn't going to bring about a similar problem?

        Celebrate Intellectual Diversity

        CentOS, Gento, Debian are all flavours of the same OS in my book.

        Anyway, I'd use puppet or cfengine or something similar to that.

        I have encountered two problems: raid failure on one of prod servers where we had no backup. So it was pretty slow and painfull to install all deps and get box running asap.
        What can I say? Incompetence? First of all, not having backups should, IMO, be a firing offense. No second chances. Second, you ought to be able to clone a new production box in a matter of minutes. Automatically. You should have an install server in your maintenance network that just dumps a complete OS tailored to your needs on a freshly booted box.
Re: Application deploymentt
by chrestomanci (Priest) on Feb 07, 2012 at 16:19 UTC

    When I have done this in the past, I experemented with CPAN and creating a localy built debian package that contained everything before deciding on local::lib and checking the local lib into source control.

    The developers on the project would run CPAN against the local lib whenever they needed to add new libaries, or update existing ones. Deployment on the servers was a simple svn checkout of the relevant tag.

    In the main it worked well, but there where occasions where perl packages that compiled binary XS code would break things quite comprehensively for other platforms, while appearing to work fine for the platform it was compiled an tested on. If you have more than one OS or processor archetecture on your servers then take a look at node 942112 where I have described the problem in more detail.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://952273]
Approved by marto
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2014-07-26 14:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (178 votes), past polls