To Package, and what to package
One of the open sessions last week (corr: last month) at Devopsdays 2010 Hamburg was the one on packaging software. It's always a big question on wether you package the software that runs in your infrastructure or not. And if you package it .. what do you package ..
The general consensus of the open space was pretty much that you always package the software you deploy, unless you have some very good reasons not to. Pretty much the way I've been doing for ages ..
Good reasons that were mentionned were the use of scripting languages that update extremely frequently, but certainly not for compiled code, compiling code on a production machine also is a big nono.
There also was a consensus that you DO NOT PUT CONFIGURATION inside a package. You can put in default templates, but you don't put in config files that should change frequently .. There's plenty of configuration mgmt systems out there do that kind of stuff for you.
The naysayers claimed that packaging brings way to much overhead ... and others claim it takes to much time... however I feel it
should just be a 1 time effort that brings devs and ops closer to eachother and from there on it should automated
New versions of software don't mean that the packaging effort needs to be done again..
Another topic that gathered lots of questions was if you should be capable of installing multiple versions of the same package , lots of people mentionned they didn't like fiddling with symlinks however the best comment in that discussion was that there is already a system out there , the alternatives setup .. provide by most operating systems that allow you to do so in a pretty clean way. I must admit I should look into alternatives more in depth too ..
The ever recurring question is wether one should package war files ? Sure as you then can also use the dependency models a package mgmt system brings to deploy the dependent libraries.
However when people ship products, rather than a live service they seem to package everything , mainly because the code in the product isn't changing as quickly as a live website, or internally used application.
The biggest problem however is the frustration people have with GEM or CPAN packages .. they add yet another layer of management to a system, most lots of CPAN packages are already packaged.. but when it comes to GEM's disaster strikes. There's a lot of work left for distributions to integrate GEM and CPAN style packages.
Comments
#1 Sarah Harris : Interesting post
Great question: to pack or not to pack? I'm on the side of packing. I think the point you made about not putting config files in is good to note. I also agree with Eric's comment about war files. I've always packed up the unzipped versions of the war files, it's just easier that way.
#2 Eve telecom news freak : Keep it packed...
Jus like Chris..I think unpacking .war files is a hassle we pick by ourselves...
There are many better containers available these days, and the same rule about keeping your .war files zipped applies to all of them.
I deal quite many with building deb packages and have used some tools available as well.
#3 Anonymous : >> compiling code on a
>> compiling code on a production machine also is a big nono.
unless the official package was not compiled with the options/libraries you need...assuming there is an official package...
>> The biggest problem however is the frustration
>> people have with GEM or CPAN packages .. they add >> yet another layer of management to a system
You sound like a naysayer now :)
The naysayers claimed that packaging brings way to much overhead ... and others claim it takes to much time... however I feel it
should just be a 1 time effort that brings devs and ops closer to eachother and from there on it should automated
New versions of software don't mean that the packaging effort needs to be done again.
( part of the reason CPAN and GEMS exist is because perl and ruby run on many platforms with many different packaging systems (or lack thereof) )
Truth be told, I mostly agree with everything you said, but be thankful if you have the luxury of doing things from scratch, instead of inheriting existing system(s).
#4 Kris Buytaert : compiling
Still if the official package wasn't compiled with the options you want .. you don't recompile / package on your production hosts but in your build environment.
And as for naysayer .. the argument isn't against the package overhead .. it's against yut another unintegrated package.
#5 Chris Read : Keep those .war files packed!
I've always found that unpacking .war files is just asking for trouble. In addition to the deployment pain that Tomcat especially has with it, it's a great temptation for people to just go and change a file in there to fix a small problem. That way the change gets lost in the next upgrade.
A much better option is make your application look for its configuration in a well known place on the filesystem path. With Tomcat specifically I've had good results getting my apps to load their config from a file in $CATALINA_HOME/conf/.
This in no way should be seen as me endorsing Tomcat though! There are far better containers available these days, and the same rule about keeping your .war files zipped applies to all of them.
If your argument is that you need to modify your web.xml or similar for each environment, then you're just doing it wrong...
#6 Eric Eisenhart : My 2 cents
1) war files: I've dealt with this before, and you can package a war file, but it's better to package up the unzipped version of the war file (tomcat already unzips it for you), so that it's easier for your configuration management system to muck around with the stuff inside the war that's more like configuration. (there's always something)
2) CPAN/GEM: there's tools to automate most of the work of making either into an RPM. For CPAN there's cpanspec, cpan2rpm and ovid. For GEM there's gem2rpm. I don't deal much with building deb packages but I'd assume there's similar tools available for building deb packages as well.