Deployment Framework Overview

This page tries to answer the questions:

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:

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

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:

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:

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

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.

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

Deployment/Overview (last edited 2020-07-28 06:39:34 by LanceEdgar)