Flavio Poletti

Many times I craft things that have to be installed in some place,
which means that an installer is a nice thing to have. Here’s one,
Perl-based.

The basic idea that probably anyone has for a poor man’s deployment
system is to pack stuff in a tarball, together with a deployment
script inside that has to be executed in the target machine. Without
too much fantasy, I figured that I could walk the extra mile and
make a package that behaves like a tarball with a twist - i.e. it
is capable of executing things after unpacking.

TL;DR

Put your stuff in a directory. The current directory is fine. Assume
it is exactly as you want it to appear when you unpack in the
destination. Include a deployment script, i.e. the one that you usually
include for starting the real deployment after unpacking –we’ll call
it deploy.sh– and make sure it’s executable. You should have
something like this in the directory:

deployable is a handful of tools to help you with remote management
of multiple servers. It was born when there was no Puppet or Chef in
town - not that I know of, at least - and worked pretty well for me.

In this post we’ll concentrate on the main script –named after the
bunch of tools– i.e. the one that allows you to generate smart
packages.

Before continuing, if you find it interesting, please note that you
will need to carry also the remote script with you, together with
installing dependencies. If you like compact packages - and you
probably do if you’re interested in packing thing smartly - you
can download the bundled version. Ensure to
put it in some place in PATH and to set its execution bits, this
is what we will assume in the rest of this post.

So what was your workflow before deployable? Let’s assume it was
something like this:

place all relevant files in a directory (possibly in a subdirectory)

add a deployment script to the directory

create a tarball of that directory

write instructions to unpack the tarball and execute the
deployment script inside the directory that is created

You actually don’t have to change your workflow that much. If you
want to stick to it, you can still put all your stuff in a directory,
like the first bullet above, and create a package with the whole
contents of that directory via deployable instead of the last step
in the example above:

You end up with /path/to/package.pl (you can omit the path to create it
in the current directory of course). At this point, you hardly have to
write any instructions: just tell your recipients to put the script in
the destination server with the execution bits turned on, and execute it.

So what does that command do? Easy:

option -o sets the output. If not set, the resulting script will
be printed on standard output, but if you provide a filename
deployable will make it executable

option -H (alias --heredir) tells deployable where your stuff
is (in terms of a directory). The contents of the directory will
be included in the package, but the initial path set with -H will
be stripped away. In the example above, file foobar/deploy.sh will
be included simply as deploy.sh (actually, as ./deploy.sh). This
is useful if you want to store all files/directories to be shipped
in one single place, but you don’t care about the containing
directory

option -d tells deployable that the specified file (i.e.
deploy.sh in our example) has to be executed. You can specify
whatever file you include, even multiple ones; only remember that
the path to the files that you include will be referred to their
position in the package, so in our example you have to specify it
as deploy.sh instead of foobar/deploy.sh because foobar is
stripped away.

Shortcuts?

Stuff in current directory

If you just want to ship some files in the current directory, you’re not
obliged to use -H at all, just tell deployable which files you want
to include. Remember that they will be recorded with the path you provide.

deployable -o p.pl file1 file2 ...

Execute multiple deployment programs

If you want to execute multiple programs, make sure they are all
executable and pass them with multiple -d options:

deployable -o p.pl -d exec1 -d exec2 exec1 exec2 file1 ...

If you want to execute all executable files inside the default current
directory, you can just pass the -X command line parameter. Beware that
it will execute whatever it finds, so make sure that this is what you
actually want:

deployable -o p.pl -X exec1 exec2 file1 ...

Install stuff in place

At the time that I needed it, chances where that I had to update
some system files in multiple machines at once. This meant that I
wanted the tarball to optionally extract things based on the
root directory (i.e. /) so that the files go in place.

While this is not hard to do with what explained above –it’s a
matter of crafting the deploy.sh script for this– it was too
handy to leave outside. You have two ways:

create a directory target-root and put all the stuff you want
to install like target-root were the root directory / of the
target system, or

include files/directories (presumably inside the current directory)
to be directly extracted in the root directory / of the target
system.