Glossary

The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation.

Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resourceto check your knowledge of Ansible’s components and understand how they fit together. It’s something you might wish to read for review orwhen a term comes up on the mailing list.

  • Action
  • An action is a part of a task that specifies which of the modules torun and which arguments to pass to that module. Each task can haveonly one action, but it may also have other parameters.
  • Ad Hoc
  • Refers to running Ansible to perform some quick command, using/usr/bin/ansible, rather than the orchestrationlanguage, which is /usr/bin/ansible-playbook. An exampleof an ad hoc command might be rebooting 50 machines in yourinfrastructure. Anything you can do ad hoc can be accomplished bywriting a playbook and playbooks can also gluelots of other operations together.
  • Async
  • Refers to a task that is configured to run in the background ratherthan waiting for completion. If you have a long process that wouldrun longer than the SSH timeout, it would make sense to launch thattask in async mode. Async modes can poll for completion every so manyseconds or can be configured to “fire and forget”, in which caseAnsible will not even check on the task again; it will just kick itoff and proceed to future steps. Async modes work with both/usr/bin/ansible and /usr/bin/ansible-playbook.
  • Callback Plugin
  • Refers to some user-written code that can intercept results fromAnsible and do something with them. Some supplied examples in theGitHub project perform custom logging, send email, or even play soundeffects.
  • Check Mode
  • Refers to running Ansible with the —check option, which does notmake any changes on the remote systems, but only outputs the changesthat might occur if the command ran without this flag. This isanalogous to so-called “dry run” modes in other systems, though theuser should be warned that this does not take into account unexpectedcommand failures or cascade effects (which is true of similar modes inother systems). Use this to get an idea of what might happen, but donot substitute it for a good staging environment.
  • Connection Plugin
  • By default, Ansible talks to remote machines through pluggablelibraries. Ansible supports native OpenSSH (SSH (Native)) ora Python implementation called paramiko. OpenSSH is preferredif you are using a recent version, and also enables some features likeKerberos and jump hosts. This is covered in the gettingstarted section. There are alsoother connection types like accelerate mode, which must bebootstrapped over one of the SSH-based connection types but is veryfast, and local mode, which acts on the local system. Users can alsowrite their own connection plugins.
  • Conditionals
  • A conditional is an expression that evaluates to true or false thatdecides whether a given task is executed on a given machine or not.Ansible’s conditionals are powered by the ‘when’ statement, which arediscussed in the Working With Playbooks.
  • Declarative
  • An approach to achieving a task that uses a description of thefinal state rather than a description of the sequence of stepsnecessary to achieve that state. For a real world example, adeclarative specification of a task would be: “put me in California”.Depending on your current location, the sequence of steps to get you toCalifornia may vary, and if you are already in California, nothingat all needs to be done. Ansible’s Resources are declarative; itfigures out the steps needed to achieve the final state. It also letsyou know whether or not any steps needed to be taken to get to thefinal state.
  • Diff Mode
  • A —diff flag can be passed to Ansible to show what changed onmodules that support it. You can combine it with —check to get agood ‘dry run’. File diffs are normally in unified diff format.
  • Executor
  • A core software component of Ansible that is the power behind/usr/bin/ansible directly – and corresponds to theinvocation of each task in a playbook. TheExecutor is something Ansible developers may talk about, but it’s notreally user land vocabulary.
  • Facts
  • Facts are simply things that are discovered about remote nodes. Whilethey can be used in playbooks and templates just likevariables, facts are things that are inferred, rather than set. Factsare automatically discovered by Ansible when running plays byexecuting the internal setup module on the remote nodes. Younever have to call the setup module explicitly, it just runs, but itcan be disabled to save time if it is not needed or you can tellansible to collect only a subset of the full facts via thegather_subset: option. For the convenience of users who areswitching from other configuration management systems, the fact modulewill also pull in facts from the ohai and factertools if they are installed. These are fact libraries from Chef andPuppet, respectively. (These may also be disabled viagather_subset:)
  • Filter Plugin
  • A filter plugin is something that most users will never need tounderstand. These allow for the creation of new Jinja2filters, which are more or less only of use to people who know whatJinja2 filters are. If you need them, you can learn how to write themin the API docs section.
  • Forks
  • Ansible talks to remote nodes in parallel and the level of parallelismcan be set either by passing —forks or editing the default ina configuration file. The default is a very conservative five (5)forks, though if you have a lot of RAM, you can easily set this toa value like 50 for increased parallelism.
  • Gather Facts (Boolean)
  • Facts are mentioned above. Sometimes when running a multi-playplaybook, it is desirable to have some plays thatdon’t bother with fact computation if they aren’t going to need toutilize any of these values. Setting gather_facts: False ona playbook allows this implicit fact gathering to be skipped.
  • Globbing
  • Globbing is a way to select lots of hosts based on wildcards, ratherthan the name of the host specifically, or the name of the group theyare in. For instance, it is possible to select ww to match allhosts starting with www. This concept is pulled directly from*Func, one of Michael DeHaan’s (an Ansible Founder) earlierprojects. In addition to basic globbing, various set operations arealso possible, such as ‘hosts in this group and not in another group’,and so on.
  • Group
  • A group consists of several hosts assigned to a pool that can beconveniently targeted together, as well as given variables that theyshare in common.
  • Group Vars
  • The group_vars/ files are files that live in a directoryalongside an inventory file, with an optional filename named aftereach group. This is a convenient place to put variables that areprovided to a given group, especially complex data structures, so thatthese variables do not have to be embedded in the inventoryfile or playbook.
  • Handlers
  • Handlers are just like regular tasks in an Ansibleplaybook (see Tasks) but are only run ifthe Task contains a notify directive and also indicates that itchanged something. For example, if a config file is changed, then thetask referencing the config file templating operation may notifya service restart handler. This means services can be bounced only ifthey need to be restarted. Handlers can be used for things other thanservice restarts, but service restarts are the most common usage.
  • Host
  • A host is simply a remote machine that Ansible manages. They can haveindividual variables assigned to them, and can also be organized ingroups. All hosts have a name they can be reached at (which is eitheran IP address or a domain name) and, optionally, a port number, if theyare not to be accessed on the default SSH port.
  • Host Specifier
  • Each Play in Ansible maps a series of tasks (which define the role,purpose, or orders of a system) to a set of systems.

This hosts: directive in each play is often called the hosts specifier.

It may select one system, many systems, one or more groups, or evensome hosts that are in one group and explicitly not in another.

  • Host Vars
  • Just like Group Vars, a directory alongside the inventory file namedhost_vars/ can contain a file named after each hostname in theinventory file, in YAML format. This provides a convenient place toassign variables to the host without having to embed them in theinventory file. The Host Vars file can also be used to define complexdata structures that can’t be represented in the inventory file.
  • Idempotency
  • An operation is idempotent if the result of performing it once isexactly the same as the result of performing it repeatedly withoutany intervening actions.
  • Includes
  • The idea that playbook files (which are nothingmore than lists of plays) can include other lists of plays,and task lists can externalize lists of tasks in other files,and similarly with handlers. Includes can be parameterized,which means that the loaded file can pass variables. For instance, anincluded play for setting up a WordPress blog may take a parametercalled user and that play could be included more than once tocreate a blog for both alice and bob.
  • Inventory
  • A file (by default, Ansible uses a simple INI format) that describesHosts and Groups in Ansible. Inventorycan also be provided via an Inventory Script (sometimes calledan “External Inventory Script”).
  • Inventory Script
  • A very simple program (or a complicated one) that looks uphosts, group membership for hosts, and variableinformation from an external resource – whether that be a SQLdatabase, a CMDB solution, or something like LDAP. This concept wasadapted from Puppet (where it is called an “External NodesClassifier”) and works more or less exactly the same way.
  • Jinja2
  • Jinja2 is the preferred templating language of Ansible’s templatemodule. It is a very simple Python template language that isgenerally readable and easy to write.
  • JSON
  • Ansible uses JSON for return data from remote modules. This allowsmodules to be written in any language, not just Python.
  • Lazy Evaluation
  • In general, Ansible evaluates any variables inplaybook content at the last possible second,which means that if you define a data structure that data structureitself can define variable values within it, and everything “justworks” as you would expect. This also means variable strings caninclude other variables inside of those strings.
  • Library
  • A collection of modules made available to /usr/bin/ansibleor an Ansible playbook.
  • Limit Groups
  • By passing —limit somegroup to ansible oransible-playbook, the commands can be limited to a subsetof hosts. For instance, this can be used to runa playbook that normally targets an entire set ofservers to one particular server.
  • Local Action
  • A local_action directive in a playbook targetingremote machines means that the given step will actually occur on thelocal machine, but that the variable {{ ansible_hostname }} can bepassed in to reference the remote hostname being referred to in thatstep. This can be used to trigger, for example, an rsync operation.
  • Local Connection
  • By using connection: local in a playbook, orpassing -c local to /usr/bin/ansible, this indicatesthat we are managing the local host and not a remote machine.
  • Lookup Plugin
  • A lookup plugin is a way to get data into Ansible from the outside world.Lookup plugins are an extension of Jinja2 and can be accessed in templates, e.g.,{{ lookup('file','/path/to/file') }}.These are how such things as with_items, are implemented.There are also lookup plugins like file which loads data froma file and ones for querying environment variables, DNS text records,or key value stores.
  • Loops
  • Generally, Ansible is not a programming language. It prefers to bemore declarative, though various constructs like loop allowa particular task to be repeated for multiple items in a list.Certain modules, like yum and apt, actually takelists directly, and can install all packages given in those listswithin a single transaction, dramatically speeding up total time toconfiguration, so they can be used without loops.
  • Modules
  • Modules are the units of work that Ansible ships out to remotemachines. Modules are kicked off by either/usr/bin/ansible or /usr/bin/ansible-playbook(where multiple tasks use lots of different modules in conjunction).Modules can be implemented in any language, including Perl, Bash, orRuby – but can leverage some useful communal library code if writtenin Python. Modules just have to return JSON. Once modules areexecuted on remote machines, they are removed, so no long runningdaemons are used. Ansible refers to the collection of availablemodules as a library.
  • Multi-Tier
  • The concept that IT systems are not managed one system at a time, butby interactions between multiple systems and groups of systems inwell defined orders. For instance, a web server may need to beupdated before a database server and pieces on the web server mayneed to be updated after THAT database server and various loadbalancers and monitoring servers may need to be contacted. Ansiblemodels entire IT topologies and workflows rather than looking atconfiguration from a “one system at a time” perspective.
  • Notify
  • The act of a task registering a change event andinforming a handler task that anotheraction needs to be run at the end of the play. Ifa handler is notified by multiple tasks, it will still be run onlyonce. Handlers are run in the order they are listed, not in the orderthat they are notified.
  • Orchestration
  • Many software automation systems use this word to mean differentthings. Ansible uses it as a conductor would conduct an orchestra.A datacenter or cloud architecture is full of many systems, playingmany parts – web servers, database servers, maybe load balancers,monitoring systems, continuous integration systems, etc. Inperforming any process, it is necessary to touch systems in particularorders, often to simulate rolling updates or to deploy softwarecorrectly. Some system may perform some steps, then others, thenprevious systems already processed may need to perform more steps.Along the way, emails may need to be sent or web services contacted.Ansible orchestration is all about modeling that kind of process.
  • paramiko
  • By default, Ansible manages machines over SSH. The library thatAnsible uses by default to do this is a Python-powered library calledparamiko. The paramiko library is generally fast and easy to manage,though users desiring Kerberos or Jump Host support may wish to switchto a native SSH binary such as OpenSSH by specifying the connectiontype in their playbooks, or using the -c ssh flag.
  • Playbooks
  • Playbooks are the language by which Ansible orchestrates, configures,administers, or deploys systems. They are called playbooks partiallybecause it’s a sports analogy, and it’s supposed to be fun using them.They aren’t workbooks :)
  • Plays
  • A playbook is a list of plays. A play isminimally a mapping between a set of hosts selected by a hostspecifier (usually chosen by groups but sometimes byhostname globs) and the tasks which run on thosehosts to define the role that those systems will perform. There can beone or many plays in a playbook.
  • Pull Mode
  • By default, Ansible runs in push mode, which allows it veryfine-grained control over when it talks to each system. Pull mode isprovided for when you would rather have nodes check in every N minuteson a particular schedule. It uses a program calledansible-pull and can also be set up (or reconfigured) usinga push-mode playbook. Most Ansible users use pushmode, but pull mode is included for variety and the sake of havingchoices.

ansible-pull works by checking configuration orders out ofgit on a crontab and then managing the machine locally, using thelocal connection plugin.

  • Push Mode
  • Push mode is the default mode of Ansible. In fact, it’s not reallya mode at all – it’s just how Ansible works when you aren’t thinkingabout it. Push mode allows Ansible to be fine-grained and conductnodes through complex orchestration processes without waiting for themto check in.
  • Register Variable
  • The result of running any task in Ansible can bestored in a variable for use in a template or a conditional statement.The keyword used to define the variable is called register, takingits name from the idea of registers in assembly programming (thoughAnsible will never feel like assembly programming). There are aninfinite number of variable names you can use for registration.
  • Resource Model
  • Ansible modules work in terms of resources. For instance, thefile module will select a particular file and ensurethat the attributes of that resource match a particular model. As anexample, we might wish to change the owner of /etc/motd toroot if it is not already set to root, or set its mode to0644 if it is not already set to 0644. The resource modelsare idempotent meaning change commands are notrun unless needed, and Ansible will bring the system back to a desiredstate regardless of the actual state – rather than you having to tellit how to get to the state.
  • Roles
  • Roles are units of organization in Ansible. Assigning a role toa group of hosts (or a set of groups,or host patterns, etc.) implies that they shouldimplement a specific behavior. A role may include applying certainvariable values, certain tasks, and certain handlers– or just one or more of these things. Because of the file structureassociated with a role, roles become redistributable units that allowyou to share behavior among playbooks – or even with other users.
  • Rolling Update
  • The act of addressing a number of nodes in a group N at a time toavoid updating them all at once and bringing the system offline. Forinstance, in a web topology of 500 nodes handling very large volume,it may be reasonable to update 10 or 20 machines at a time, moving onto the next 10 or 20 when done. The serial: keyword in an Ansibleplaybooks control the size of the rolling update pool. Thedefault is to address the batch size all at once, so this is somethingthat you must opt-in to. OS configuration (such as making sure configfiles are correct) does not typically have to use the rolling updatemodel, but can do so if desired.
  • Serial

See also

Rolling Update

  • Sudo
  • Ansible does not require root logins, and since it’s daemonless,definitely does not require root level daemons (which can bea security concern in sensitive environments). Ansible can log in andperform many operations wrapped in a sudo command, and can work withboth password-less and password-based sudo. Some operations thatdon’t normally work with sudo (like scp file transfer) can be achievedwith Ansible’s copy, template, andfetch modules while running in sudo mode.
  • SSH (Native)
  • Native OpenSSH as an Ansible transport is specified with -c ssh(or a config file, or a directive in the playbook)and can be useful if wanting to login via Kerberized SSH or using SSHjump hosts, etc. In 1.2.1, ssh will be used by default if theOpenSSH binary on the control machine is sufficiently new.Previously, Ansible selected paramiko as a default. Usinga client that supports ControlMaster and ControlPersist isrecommended for maximum performance – if you don’t have that anddon’t need Kerberos, jump hosts, or other features, paramiko isa good choice. Ansible will warn you if it doesn’t detectControlMaster/ControlPersist capability.
  • Tags
  • Ansible allows tagging resources in a playbookwith arbitrary keywords, and then running only the parts of theplaybook that correspond to those keywords. For instance, it ispossible to have an entire OS configuration, and have certain stepslabeled ntp, and then run just the ntp steps to reconfigurethe time server information on a remote host.
  • Task
  • Playbooks exist to run tasks. Tasks combine an action(a module and its arguments) with a name and optionally some otherkeywords (like looping directives). Handlersare also tasks, but they are a special kind of task that do not rununless they are notified by name when a task reports an underlyingchange on a remote system.
  • Tasks
  • A list of Task.
  • Templates
  • Ansible can easily transfer files to remote systems but often it isdesirable to substitute variables in other files. Variables may comefrom the inventory file, Host Vars, GroupVars, or Facts. Templates use the Jinja2 templateengine and can also include logical constructs like loops and ifstatements.
  • Transport
  • Ansible uses :term:Connection Plugins to define types of availabletransports. These are simply how Ansible will reach out to managedsystems. Transports included are paramiko,ssh (using OpenSSH), andlocal.
  • When
  • An optional conditional statement attached to a task that is used todetermine if the task should run or not. If the expression followingthe when: keyword evaluates to false, the task will be ignored.
  • Vars (Variables)
  • As opposed to Facts, variables are names of values (they canbe simple scalar values – integers, booleans, strings) or complexones (dictionaries/hashes, lists) that can be used in templates andplaybooks. They are declared things, not things that areinferred from the remote system’s current state or nature (which iswhat Facts are).
  • YAML
  • Ansible does not want to force people to write programming languagecode to automate infrastructure, so Ansible uses YAML to defineplaybook configuration languages and also variablefiles. YAML is nice because it has a minimum of syntax and is veryclean and easy for people to skim. It is a good data format forconfiguration files and humans, but also machine readable. Ansible’susage of YAML stemmed from Michael DeHaan’s first use of it inside ofCobbler around 2006. YAML is fairly popular in the dynamic languagecommunity and the format has libraries available for serialization inmany languages (Python, Perl, Ruby, etc.).

See also