Deployment Framework Overview

This page tries to answer the questions:

• Briefly, what is "server config management" and why should you care?
• What exactly is Rattail's "deployment framework" and why does it exist?
• How is the framework implemented and how does one get started using it?

Configuration Management

The term configuration management transcends the Rattail project certainly, and there is little doubt that it is better explained elsewhere on the web. When the term is used within the Rattail project, the following are assumed:

• There is (at least) one source code repository involved, which contains configuration (install/config logic and data) for one or more servers.
• Each supported server has a separate "bundle" containing its configuration (logic and data).
• A server bundle may be executed in such a way that the target server becomes fully operational.

So, why is this important? Again others have surely written at length about that, but here are some good reasons to bother with this:

• Working Docs - Instead of maintaining docs on how to configure a server, maintain the code needed to actually configure it. This code can/should be essentially self-documenting, serving both purposes.
• Living History - This implies a version control system of course. Ever wonder why that one server has a weird service installed and who did that? It doesn't have to be a total mystery... Plus with an issue tracker you can cross-reference config changes to tickets, improving the audit trail even more.
• Upgrade with Confidence - After all these are "working docs" right? Upgrading, and even swapping out a live server should be easy and not cause an ulcer.
• Bus Factor - Every business should appreciate having the critical knowledge of how their servers are configured, encoded in an imminently-usable format versus stuck in "your head".
• Vacations! - Take 'em without concern. And sleep well in between too.

There are a handful of very well-known config management systems out there (e.g. Chef, Puppet, Ansible). Rattail doesn't use any of these, but has "sort of" rolled its own instead, which is based on Fabric. Read on for more about that.

Rattail's Deployment Framework

Rattail offers a custom "deployment framework" which is essentially a config management system. More precisely, Rattail tries to offer two things to help with the config management problem:

• First, a custom/convenience API for installing and configuring software on a target server.
• Second, a set of "opinions" regarding the pattern with which this API should be used.

The API is built atop Python and Fabric, and resides in the rattail_fabric2 package. Since it uses Fabric, the underlying communication/transport protocol is SSH.

As for the "opinions" part, it is hoped that these docs will satisfy the goal to some extent. In practice the opinions are perpetually under development and are therefore probably best understood by looking at actual server bundles in the wild. One option there is the rattail-fabdemo source code. (See also the deployment demo docs.)

So, why not use one of the other wildly-popular config management systems? In one sense it's purely an artifact of chance, based on the author's familiarity with the tools in question at the time of initial development effort, as well as other serendipitous reasons. In the end, the framework produced was (IMHO) quite simple and convenient to use, and with practically no overhead from extra dependencies etc.

Features

Some of the nicer things about using Fabric under the hood include:

• Uses SSH, and even leverages ~/.ssh/config and friends.

• Server bundle code is imperative instead of declarative. That means instead of "describing" what you want to do, your code does what you want to do. That may not sound like a big deal, but in practice the declarative approach usually means there is a limit to what you can even "describe" (unless you jump through some typically-painful hoops). Having imperative code means you are directly wielding the full power of Python, and can e.g. structure things however you like.

• The Fabric APIs do quite a bit to help keep the code "pretty" despite its being imperative. (The declarative approach often does make for cleaner end code, but code which leverages Fabric tends to be pretty clean too.)

Some features with which the Rattail deployment framework was designed include:

• Keep passwords out of the source repo. This is accomplished by a simple mechanism, where a single file (per server) must be maintained within the control environment. This file will contain all passwords, secrets, and other config settings for the server. This file is never to be committed to the source repo.
• Keep secure files out of the source repo. Same idea as the passwords, except whole files can be ignored from the repo while still being technically part of the deployment bundle. This requires a local copy of each secure file to be present in the control environment.

Getting Started

The general structure of the idea is as follows. For the sake of example let's say you have 3 Linux servers which you need to maintain, each of which runs various software apps etc.

• You set up your control environment.

• You create a source repo to contain all your server bundles.
• Within the repo, you create a bundle for each server.
• You maintain the bundles going forward, and use them to help with managing your servers.

This is obviously a general outline, the devil is in the details. For more of that, see the Technical Overview.