After reading through the rest of the documentation, it may be helpful to review some terms.
ansible – from science fiction, a device for communicating instanteously over large distances.
ansible – When speaking of /usr/bin/ansible, a tool for ad-hoc task execution on a group of hosts. This constrasts with /usr/bin/ansible-playbook, which is a full on configuration management and orchestration tool built on top of these fundamentals. Both come with ‘ansible’, the application.
action – the part of a task that specifies what module to run and what arguments to send it
async – the act of running a ansible task in the background, potentially polling it for completion. This is useful for kicking off tasks where the result is not important, or in executing tasks that would exceed the SSH timeout.
cobbler – a kickstart, mirroring, power management, and miscellaneous datacenter management tool that Michael wrote before Ansible, and is frequently used with it. See Cobbler
common module code – a facility in which Ansible modules written in Python can minimize boilerplate code for argument validation and returning values. This is not available to non-Python modules but modules can still be written in languages other than Python.
connection – how Ansible connects to and manages remote hosts. Paramiko and native ssh are the main options, though there is also a local connection mode.
cowsay – a special utility program that, if installed, greatly enhances the clarity of ansible-playbook output.
daisy chaining – comes up in development discussions. It’s how in Ansible one module (like copy or template) can use parameters supported by the file module by requesting the file module be run after the copy module. For example, if specifying a file be templated, we can also specify the mode and owner because the file module is automatically daisy-chained after the file module.
DSL – domain specific language. The idea of making a special “programming” language or a subset of a language to build a tool out of. Ansible doesn’t believe in these, and instead treats it’s playbook language as a data format.
env-setup – a very useful script in the “hacking” directory of an ansible checkout. Sourcing this script makes it very easy to run ansible from source without doing any installation.
external inventory script – the act of using an executable script in place of an ansible inventory file, so that ansible will invoke the script when needed to ask about what hosts it is managing and variables related to those hosts.
fact – a variable discovered about a remote host, rather than configured in a config file. Facts can include the system architecture, the hostname, the operating system version, and so on. facts can be used in configuration files.
forks – the level of parallelism used with a /usr/bin/ansible or /usr/bin/ansible-playbook command. Ansible executes multiple remote management commands in parallel to get things done faster.
func – an earlier ad-hoc execution tool that is the basis of some of the ideas in Ansible. Michael wrote Func with some colleagues from Red Hat, and a later tool called taboot built on Func helped inspire the playbooks language. Func didn’t have a configuration management language on top of it, nor did it use SSH, but it helped pave the way for several other tools.
handler – a special class of a task that is not run unless a given task registers a change event. Handlers are most frequently used for restarting services when the contents of configuration files change.
idempotent – when applied to configuration management, this means that running a given task twice does not produce an unexpected effect on the system. Mathematically, F(x) = F(F(x)). Ansible’s core modules all support this concept but Ansible does not force this upon you.
include – a playbook, handler, or variable data loaded from another file
infrastructure as code – the practice of treating configuration, management, and deployment of systems as a software project. Ansible doesn’t really believe in this and tries to simplify things by making a simpler language that is easier to write and audit, and is therefore easier to understand by all parties involved. More advanced takes on I.A.C. use actual programming languages to describe configurations.
inventory – ansible keeps track of what hosts you are managing, and allows them to be put in groups for easier selection. This file is by default in a simple INI format, but can be replaced with an ‘external inventory script’
Jinja2 – Ansible uses this as a templating language for the ‘template’ module.
JSON – the format Ansible modules use to return data over the wire. “Java Script Object Notation”
module – a reusable unit of logic that tells Ansible how to do things on remote machines. Ansible ships with many modules written in Python, but modules can be written in any language. Modules return structured data in JSON.
notify – what a task does when it detects that something has changed on the remote system. A task notifying a handler means it is sending a message to the handler that it needs to run at the end of a playbook execution.
paramiko – the default connection type for ansible uses a pure-Python SSH library called paramiko. It is generally easier to set up than native SSH but does not offer as many configuration options and does not support Kerberized SSH.
pattern – a selector that can match host or group names using wildcards. Patterns are used in plays or in ad-hoc executions of /usr/bin/ansible to target groups of hosts to manage.
play – a group of ansible tasks that are to be executed on the same set of hosts. A play is always run by the same user account and may optionally sudo to a particular user after connecting. In addition to a list of tasks, a play may also choose to define variables or include them from other files, all of which are shared with each task in the play.
playbook – a list of ansible plays grouped together in a single file, which are run top to bottom. Each play may select different hosts and have different tasks. A playbook is analogous to a Chef recipe, a Puppet manifest, a CFEngine “promise”. Playbooks can be broken up into more than one file using includes, in which case it’s still ok to call it a playbook.
pull – the act of a managed system phoning home to ask how it is configured. This is useful in large scale out scenarios or for periodic automatic system remediation.
push – the act of reaching out to systems you want to manage rather than them phoning home. This is Ansible’s default mode, but pull is also supported via the ‘ansible-pull’ script.
runner – comes up in development discussions. a core component of the ansible code that runs a single module/task against a given set of hosts. /usr/bin/ansible makes use of runner directly. Playbooks instantiate multiple instances of runner, one for each task in a playbook.
setup cache – comes up in development discussions. The setup cache is a mechanism of storing fact results from various systems and makes them available as variables in action lines and templates
SSH – secure shell. Ansible by default uses SSH to talk to remote hosts because it is already there and very secure. It does not require any additional daemons.
task – one of many ansible modules to execute on a given set of hosts, and the parameters to use when calling it. A task has a name, an ‘action’, and other optional variables. Making sure a package is installed, or a file is templated and transferred, is the example of a task.
template – the act of taking a file with variable placeholders in it and substituting variables to make a final file. Templating is frequently used to place configuration files.
test-module – a useful script in the “hacking” directory of an ansible checkout for running a module locally, without ansible’s core code in the way. Used when developing or debugging modules.
Van Halen – the great American Rock Band, known for great instrumental guitar work and also songs about Alien Abductions. All Ansible releases are code named after Van Halen songs. C’mon Dave, gimme a break.
YAML – the core language format for ansible playbooks and include files. Stands for “YAML Ain’t Markup Language”. YAML can be taken to extremes where it is difficult to write and read, but Ansible uses a relatively simple dialect and minimal levels of nesting.