FAB(1) | General Commands Manual | FAB(1) |
fab - Simple Pythonic remote deployment tool
fab [commands ...]
The most common method for utilizing Fabric is via its command-line tool, fab, which should have been placed on your shell's executable path when Fabric was installed. fab tries hard to be a good Unix citizen, using a standard style of command-line switches, help output, and so forth.
In its most simple form, fab may be called with no options at all, and with one or more arguments, which should be task names, e.g.:
$ fab task1 task2
This will run task1 followed by task2, assuming that Fabric was able to find a fabfile nearby containing Python functions with those names.
However, it's possible to expand this simple usage into something more flexible, by using the provided options and/or passing arguments to individual tasks.
New in version 0.9.2.
Fabric leverages a lesser-known command line convention and may be called in the following manner:
$ fab [options] -- [shell command]
where everything after the -- is turned into a temporary run call, and is not parsed for fab options. If you've defined a host list at the module level or on the command line, this usage will act like a one-line anonymous task.
For example, let's say you just wanted to get the kernel info for a bunch of systems; you could do this:
$ fab -H system1,system2,system3 -- uname -a
which would be literally equivalent to the following fabfile:
from fabric.api import run def anonymous():
run("uname -a")
as if it were executed thusly:
$ fab -H system1,system2,system3 anonymous
Most of the time you will want to just write out the task in your fabfile (anything you use once, you're likely to use again) but this feature provides a handy, fast way to quickly dash off an SSH-borne command while leveraging your fabfile's connection settings.
A quick overview of all possible command line options can be found via fab --help. If you're looking for details on a specific option, we go into detail below.
NOTE:
New in version 0.9.1.
New in version 1.4.
New in version 1.1.
SEE ALSO:
New in version 1.4.
SEE ALSO:
New in version 1.1.
SEE ALSO:
New in version 1.5.
New in version 1.1.
This is useful for fire-and-forget runs (especially parallel sessions, in which runtime input is not possible) when setting the password via --password or by setting env.password in your fabfile, is undesirable.
NOTE:
SEE ALSO:
New in version 0.9.1.
New in version 1.1.
New in version 1.3.
Changed in version 0.9.1: Added docstring to output.
SEE ALSO:
SEE ALSO:
New in version 1.3.
SEE ALSO:
New in version 1.0.
fab --set password=foo --password=bar
will result in env.password = 'bar', not 'foo'
Multiple KEY=VALUE pairs may be comma-separated, e.g. fab --set var1=val1,var2=val2.
Other than basic string values, you may also set env vars to True by omitting the =VALUE (e.g. fab --set KEY), and you may set values to the empty string (and thus a False-equivalent value) by keeping the equals sign, but omitting VALUE (e.g. fab --set KEY=.)
New in version 1.4.
New in version 0.9.2.
SEE ALSO:
SEE ALSO:
New in version 1.4.
SEE ALSO:
SEE ALSO:
New in version 1.4.
SEE ALSO:
New in version 1.6.
New in version 1.3.
SEE ALSO:
The options given in command-line-options apply to the invocation of fab as a whole; even if the order is mixed around, options still apply to all given tasks equally. Additionally, since tasks are just Python functions, it's often desirable to pass in arguments to them at runtime.
Answering both these needs is the concept of "per-task arguments", which is a special syntax you can tack onto the end of any task name:
Additionally, since this process involves string parsing, all values will end up as Python strings, so plan accordingly. (We hope to improve upon this in future versions of Fabric, provided an intuitive syntax can be found.)
For example, a "create a new user" task might be defined like so (omitting most of the actual logic for brevity):
def new_user(username, admin='no', comment="No comment provided"):
print("New User (%s): %s" % (username, comment))
pass
You can specify just the username:
$ fab new_user:myusername
Or treat it as an explicit keyword argument:
$ fab new_user:username=myusername
If both args are given, you can again give them as positional args:
$ fab new_user:myusername,yes
Or mix and match, just like in Python:
$ fab new_user:myusername,admin=yes
The print call above is useful for illustrating escaped commas, like so:
$ fab new_user:myusername,admin=no,comment='Gary\, new developer (starts Monday)'
NOTE:
All of the above are translated into the expected Python function calls. For example, the last call above would become:
>>> new_user('myusername', admin='yes', comment='Gary, new developer (starts Monday)')
As mentioned in the section on task execution, there are a handful of per-task keyword arguments (host, hosts, role and roles) which do not actually map to the task functions themselves, but are used for setting per-task host and/or role lists.
These special kwargs are removed from the args/kwargs sent to the task function itself; this is so that you don't run into TypeErrors if your task doesn't define the kwargs in question. (It also means that if you do define arguments with these names, you won't be able to specify them in this manner -- a regrettable but necessary sacrifice.)
NOTE:
When using the plural form of these arguments, one must use semicolons (;) since commas are already being used to separate arguments from one another. Furthermore, since your shell is likely to consider semicolons a special character, you'll want to quote the host list string to prevent shell interpretation, e.g.:
$ fab new_user:myusername,hosts="host1;host2"
Again, since the hosts kwarg is removed from the argument list sent to the new_user task function, the actual Python invocation would be new_user('myusername'), and the function would be executed on a host list of ['host1', 'host2'].
Fabric currently honors a simple user settings file, or fabricrc (think bashrc but for fab) which should contain one or more key-value pairs, one per line. These lines will be subject to string.split('='), and thus can currently only be used to specify string settings. Any such key-value pairs will be used to update env when fab runs, and is loaded prior to the loading of any fabfile.
By default, Fabric looks for ~/.fabricrc, and this may be overridden by specifying the -c flag to fab.
For example, if your typical SSH login username differs from your workstation username, and you don't want to modify env.user in a project's fabfile (possibly because you expect others to use it as well) you could write a fabricrc file like so:
user = ssh_user_name
Then, when running fab, your fabfile would load up with env.user set to 'ssh_user_name'. Other users of that fabfile could do the same, allowing the fabfile itself to be cleanly agnostic regarding the default username.
Fabric was written by Christian Vest Hansen <karmazilla@gmail.com>.
This manual was generated based on Fabric's documentation by Andrew Starr-Bochicchio <asb@debian.org> for the Debian project (but may be used by others).
September 15, 2015 |