Some time ago I had to take care of the configuration of a bunch of Linux servers (more or less fifty of them so far), most of which have identical configuration apart some bits. These bits are typically the hostname, the IP address ecc., but also more specific and application-related info that I can't talk about.
I started using a lot of ssh and quickly realised that I had to make stuff as automatic as possible. This is probably what led me to the wheel-reinventer land once again (this was also the reason why I developed Template::Perlish, by the way). My idea of an ideal workflow for this type of activities is simple:
* figure out what has to be done in some test environment
* collect all the needed bits that need to be deployed and possibly executed in each server
* put these bits in place and execute what's needed.
While there's little to automatise for the first bullet, the second and the third have definitively space for letting me do more interesting things.
The second bullet boiled down to this: most of the times, I either had to deploy some new configuration files that were pretty the same for all the servers (or groups of them), or I had to execute some script in the target machine, where these scripts needed also some supporting data files.
What I wanted, in order to ease the third bullet, was a way to produce a single, self-contained script that was able to carry all the needed bits and do all the magic once executed. In other words, I needed some executable archive, which had to be able to hold all the files, figure out where they had to be installed depending on their "role", and execute all the "deployment" scripts. This led to a script - deployable - that is some specialised archiver that takes some lists of files/directories and produces a single script that is capable of all the magic in the remote server.
The produced script works with the least requirements, due to the fact that I wanted to change the target environment as little as possible. Thus, the underlying archiver of choice has been tar, and the remotely distributed script is capable of carrying Archive::Tar inside if it's not installed in the target machine; alternatively, it can rely upon system tar, if present.
The last part, i.e. the actual deployment, can be handled by another script - deploy. It basically does two things with a "deploy-script" produced by deployable: sftp-s it into each of the targets, then ssh-s and executes it. By default it works into a temporary directory that is created, from time to time, inside a base camp in /tmp/our-deploy, but it's all configurable.
If you want to take a look, or just comment harshly on how this is reinventing multiple wheels, feel free to do! You can find a git repository with the needed tools at http://repo.or.cz/w/deployable.git (you can take a plain old tarball going to http://repo.or.cz/w/deployable.git?a=shortlog and clicking on the first "snapshot" link you find in the list). Enjoy!
Re:What about native packaging?
polettix on 2008-08-11T02:10:06
This is actually something that I didn't investigate - simply didn't come to mind. Anyway, now that you tell me, I definitively remember some post-install scripts being executed after the package installation... so it seems to cover the requirement I had in mind for the "deployable" script.
The target system is SLES 10, while I work with debian and Mac OS X. debian probably has tools to produce rpm-s as well... Nice suggestion!
