Deployment Control Environment

That's just a fancy way of saying, "the system from which you manage server configuration". This assumes of course that you're using the Rattail Deployment Framework.

The "control environment" really refers to two things. First it refers to the machine from which you manage server config. But more specifically it refers to the software environment on that machine, which must include Python/Fabric/etc.

In most cases you would just use your personal machine for running the control environment, since that is generally most convenient.

Setup

First, a caveat(s). While it may be perfectly possible, or even simple, to use Windows for your control environment, this doc won't touch that with a 10-foot pole. Every statement made will assume that your control environment runs on Linux. And that's not the only assumption; here's hopefully the full list:

• Linux (tested with Debian/Ubuntu)
• Python 2.7 (not Python 2.6, not Python 3.x)

pip

The pip tool is also required. I tend to prefer the latest stable version from PyPI for this, as opposed to the one from apt/dpkg. The "best" way I've found to get that installed is with something like (NOTE: this is from memory, not tested):

sudo apt-get --assume-yes install python-setuptools
sudo easy_install pip
sudo pip install --upgrade pip setuptools
sudo apt-get --assume-yes purge python-setuptools

virtualenv

The virtualenv tool is not technically required, but is so utterly helpful that these docs will assume it is installed. (If you insist on not using it then I'll assume you're smart enough to know how to go about that.) The virtualenvwrapper tool is highly recommended also, though technically optional. Effort will be made to keep the docs clean of virtualenvwrapper references, so that they work for everyone whether or not they have virtualenvwrapper installed.

However again, the presence of virtualenv is implicitly (and often explicitly) assumed throughout these docs. Rattail's convention is to use /srv/envs as the root path which contains the virtual environments (and setting WORKON_HOME to that path, if virtualenvwrapper is used). Since many commands etc. may require a virtual environment name for context, the name used in these docs will be "myfab", for example:

lance@control:~$ source /srv/envs/myfab/bin/activate
(myfab)lance@control:~$ cd ~/src/myfab/servers/myhost
(myfab)lance@control:~/src/myfab/servers/myhost$ fab --list

Source Repository

Here's where it gets a little tricky to document. These docs generally assume that you are working with a source repository, managed with a version control system. But where/how to obtain that source repository, and any related commit/push workflow, are left as an exercise for the reader. However there is a demo project which you can use if you just want to try things out.

If you look at the preceding shell snippet, you can see the path ~/src/myfab is used to imply a source repository. The docs will try to always use this path within examples, for consistency.

Note that in the example above, the names of the virtual environment and source repository matched. These names aren't required to match, but it's pretty typical that they would; and "myfab" is the name we're going with in these docs for both.