Buildout-based deployment made safe and easy
Project description
Aja
Aja provides Fabric tasks for deploying buildouts from staging server to remote production servers:
it assumes buildout with absolute path (this is the buildout default)
it assumes that all the relevant paths (python, buildout, shared eggs, etc) are identical for the staging and production servers
bootstrap and buildout are always run on the staging server only
buildout is deployed by pushing its bin-, parts- and (local or shared) eggs-directories into the remote production server using rsync
Installation
Aja can be installed like any Python package:
$ pip install aja
But be aware that Aja comes with the following dependencies
Fabric
paramiko
zc.buildout
setuptools
ecdsa
pycrypto
and therefore, it’s recommended to use a dedicated virtualenv.
Aja doesn’t have it’s own executable, but is executed using Fabric’s fab command. Of course, it is possible to symlink that as aja.
Configuration
Aja is configured with a fabfile, e.g. fabfile.py:
import fabric.api
fabric.api.env.update({
'buildout_directory_prefix': '', # optional
'buildout_extends_prefix': '', # optional
})
from aja.tasks import *
buildout_directory_prefix provides optional convenience when creating new buildouts or when looking for buildouts for the other commands.
buildout_extends_prefix provides optional convenience when creating new buildout.
Usage
Aja maps Fabric’s hosts into buildouts so that for each buildout, it fills fabric.api.env with variables from [aja] part in the buildout (this is quite similar to collective.hostout). The rest of the resolved buildout file can be found at fabric.api.env.buildout.
An example [aja] part could look like:
[aja]
executable = /usr/local/python/bin/python
host_string = buildout@production
key_filename = /home/buildout/.ssh/id_rsa
This part would configure Aja tasks to use particular Python virtualenv for running the buildout and push the results into server production by performing rsync using the given key file.
Example Aja usage could look like:
$ fab create:/var/buildout/plone,/vagrant/plone-4.3.cfg
$ fab -H /var/buildout/plone buildout push
And with the following convenience configuration in fabfile:
import fabric.api
fabric.api.env.update({
'buildout_directory_prefix': '/var/buildout',
'buildout_extends_prefix': '/vagrant',
})
from aja.tasks import *
The previous example usage could look like:
$ fab create:plone,plone-4.3.cfg
$ fab -H plone buildout push
Extending
Aja provides only the most basic fabric tasks, but it provides a custom task class aja.tasks.AjaTask, which provides resolved buildout at fabric.api.env.buildout. This makes it easy to define custom tasks in your fabfile, e.g.
from fabric import api
from fabric.operations import run
from aja.tasks import AjaTask
@task(task_class=AjaTask)
def purge():
buildout_bin = api.env.buildout['buildout'].get('bin-directory')
buildout_parts = api.env.buildout['buildout'].get('parts-directory')
run('rm -rf {0:s}'.format(buildout_bin))
run('rm -rf {0:s}'.format(buildout_parts))
purge.__doc__ = \
"""Clean bin- and parts-directories (e.g. before push)
"""
Changelog
0.9.2 (2017-05-10)
Add support for bootstrap cmd to read setuptools and zc.buildout versions from buildout [datakurre]
0.9.1 (2016-04-26)
Add aja-alias for fabric as a console script [datakurre]
0.9.0 (2015-01-14)
First release.
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.