descriptionTools for creating deployable scripts/programs
last changeWed, 13 Jul 2016 16:28:45 +0000 (13 18:28 +0200)
content tags


deployable is a suite of programs that help easing the system administrator life.

It is based upon the following workflow to distribute changes in a molteplicity of servers:

  • first of all, produce a self-contained script that, once executed in each target server, will make all the needed changes;
  • secondly, transfer the given script in each server and execute it.

For the first issue, you'll probably have various files/scripts/programs that you will need to perform a given activity. The deployable script helps you select all the needed components that you need in the target server, and bundles them all inside a single, self-contained script that is ready to be run in the target machine. In this way, you'll only have to worry about taking one single file. Think about making an archive, but adding some logic to make it executable and instruct it to execute some specific programs.

For the second issue, it's mainly a matter of handling the transfer of the deploy script to the target servers, and execute them. This is obviously only a matter of sftp/ssh, but if you have more than 2 servers you'll quickly get tired of writing shell commands and passwords. To ease your life in this field, deploy is your friend: just tell it which is the script, and the list of target servers.


The deployable project contains the following files:

deployable (the script)
generates self-contained scripts with all the files that you want to ship as part of your deployment task;
helps you distribute and execute the deploy script generated with deployable above in all the relevant servers;
bundles Perl modules inside a Perl script, in order to ensure that those modules will be available in the target system (works only for Pure Perl modules);
script that is used by deployable to generate the self-contained scripts that can be distributed like advanced tarballs;
support file for embedding Archive::Tar inside remote


In a typical usage, you check some upgrade procedure in a staging environment, and come up with:

  • files that have to be installed in certain locations;
  • scripts that have to be executed;
  • support files needed by the scripts in bullet 2.

Suppose that you come up with the following situation:

  # files that must be simply installed under "/", after stripping
  # the initial "/project/target-root/" part
  # scripts to be executed in the target directory, set as executable
  # files to support scripts, not set as executable

In order to put all this stuff into a single executable perl file you use deployable. In particular, you can instruct this program about where you would like to put all the relevant stuff:

  cd /project
  deployable --all-exec -o --root target-root *.sh userlist

This command produces the script that is compound of two parts:

  • the Perl code in the remote contained in the distribution;
  • (immediately after __END__) a tarball containing all the files you want to ship.

The tarball is organised as follows:

  • stuff that must be installed at fixed paths is put inside the root directory;
  • scripts to be executed and support files are put inside the here directory;
  • a configuration file is put inside the deployable/ file.

In the example above, all the suff in target-root is placed under root; all the other files (the three scripts and the support file) are put inside the here directory:


The first part of the produced script is able to extract this tarball from itself and figure out where the different pieces have to be put. In particular, stuff under the root directory will be installed in /, and the other files in a temporary directory for further processing.

After the extraction is completed, the produced script checks if any program should be executed. Having passed the --all-exec, all executable files in the temporary directory will be executed; the order will be that resulting froma lexicographical sorting of the file names, so it's a good idea to put a leading number in order to control the execution closely.

Once you have this single script containing all what you need, plus the logic to start the deploy process in the target machine, you can put it in the target and execute it. If it's a matter of one-two servers, you can upload it, login and execute it. If you have more servers, you can use deploy:

   deploy -s host1 host2 host3

Calling this program will initially ask you for a password if you pass an empty password on the command line. If you're relying on SSH certificates, just hit return. After this, it will begin uploading and executing in all the given servers.

Thus, in a matter of two commands, you can pack all your stuff and deploy it!

2016-07-13 Flavio PolettiIgnore remote-at in gitmaster
2016-07-13 Flavio PolettiAdded missing module in remote-at build
2016-02-12 Flavio Polettiregenerated bundled version
2016-02-12 Flavio Polettiadded --xform
2016-01-19 Flavio Polettiprettier, Archive::Tar in bundled version
2016-01-04 Flavio Polettipre-pending include dirs, not appending
2015-10-15 Flavio Polettigot rid of extra underscore in file marker
2015-10-15 Flavio Polettiremoved stray trailing spaces
2015-10-15 Flavio Polettisupporting nodules (modules without __END__)
2015-10-15 Flavio Polettisorted modules and file markers
2015-10-14 Flavio Polettiadded one marker comment for easy addition of files
2015-04-26 Flavio Polettiadded bundled version for ease of downloading
2015-04-26 Flavio Polettibundle is in, swap files are out
2015-02-19 Flavio Polettisaving starting pwd() in OLD_PWD
2015-02-16 Flavio Polettiadded alias --in-root
2015-02-16 Flavio Polettifixed documentation bug
3 months ago master
3 years ago generic-remote
3 years ago better-tar