houston 0.1.0

Application deployment on CoreOS clusters using fleetd and Consul

Easy docker stack deployment to CoreOS clusters using Fleet and Consul.

Houston installs as a command-line application and is meant to be used for automated deployment of Dockerized application stacks.

Houston deployments allow for files to be placed onto the host OS, the deployment of dependency containers, confirmed startup of a container using Consul, and teardown of previous container versions in a single run.

Installation

Houston may be installed via the Python package index with the tool of your choice:

pip install houston

Documentation

Documentation is available on ReadTheDocs.

There is also an example configuration directory.

Usage Example

Example of deploying a full stack application:

houston -c config -e test-us-east-1 example 7b7d061b
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     Deploying [e-mail]
INFO     [e-mail] has started
INFO     Validated service is running with Consul
INFO     Destroying [e-mail]
INFO     Deployment of example 7b7d061b and its dependencies successful.
INFO     Eagle, looking great. You're Go.

When executed, houston creates a tarball of files from the service’s file manifest and uploads it to Consul’s KV database. It then deploys a dynamically created systemd unit to fleet, which pulls the tarball from Consul and extracts the files to the CoreOS filesystem.

In thge next step, it iterates through the dependency containers specified in the manifest, submitting and starting each unit, waiting until a unit is listed as active in systemd for all nodes, and then moves on to the next.

One the dependency containers have started, it starts the example service, waiting for systemd to report it as active. It then queries Consul for the version of the service that has started, ensuring that it is running on all the expected nodes that fleet says it has deployed it to.

Once a deployment has been confirmed, it looks at all units submitted to fleet, checking to see if there are other versions of containers running than what it deployed. If so, it will destroy those other containers with fleet.

Finally it will check to see if any other file archive versions exist in Consu for the service, removing them if so.

One of the more interesting parts for managing stack deployment is the namespacing of the shared stack elements in fleet, so that updating one stack does not impact another. For example, in the configuration, a service may be referred to as only pgbouncer:f20fb494, but when deployed it will be prefixed and versioned appropriately as example-pgbouncer@f20fb494 if the service name is example.

Version History

Available at https://houston.readthedocs.org/en/latest/history.html