Introduction
Whether you are a beginner exploring automation or a seasoned pro seeking clarity, this glossary is your definitive guide.
Streamline your understanding of Ansible concepts and master the language of automation with streamlined definitions and explanations.
Ansible Terms
A
Action: When it comes to tasks, an action represents a single step that involves selecting a module to execute and providing it with specific arguments. It's important to note that each task can only include one action, but it may also contain other parameters.
Ad Hoc: When you run Ansible for executing a brief command using /usr/bin/ansible instead of the orchestration language /usr/bin/ansible-playbook, it is referred to as an ad hoc command. For instance, rebooting 50 machines in your infrastructure is an example of an ad hoc command. Anything achievable through ad hoc commands can also be done by creating playbooks, which can combine multiple operations seamlessly.
Ansible (the package): Ansible is available as a software package that includes ansible-core and a specific set of collections, such as Python, deb, and rpm. The package for Ansible 2.10 will still support playbooks that were compatible with Ansible 2.9. To find out which collections are included in a particular Ansible release, you can refer to the ansible-<version>.build file in the release-specific directory at ansible-build-data, which also specifies the version of ansible-core that is included.
ansible-base: The installable package for Ansible 2.10, which can be obtained from the ansible/ansible repository in the form of an RPM, Python, or Deb package, is used exclusively for this version of Ansible.
ansible-core: Starting from version 2.11, the name for the installable package (RPM/Python/Deb package) derived from the ansible/ansible repository has been changed. This package comprises command-line tools and fundamental functionalities like the copy module code for managed nodes. The ansible-core package comes with a set of modules and plugins, and additional ones can be added by installing collections.
Ansible Galaxy: A platform on the internet where users can discover and exchange Ansible community resources, often known as Community Galaxy. It also serves as a command-line tool enabling users to install specific Ansible Collections, like executing ansible-galaxy collection install community.crypto.
Async:A task that is set up to operate in the background instead of waiting for completion is referred to as an asynchronous task. If you have a long-running process that would exceed the SSH timeout, it would be sensible to launch it in asynchronous mode. Asynchronous modes can be configured to check for completion at regular intervals or set up to "fire and forget," where Ansible will initiate the task without checking on it again. Asynchronous modes are compatible with both /usr/bin/ansible and /usr/bin/ansible-playbook.
C
Callback Plugin: This term describes custom code created by users to capture results from Ansible and take specific actions based on them. Examples provided in the GitHub project include custom logging, email notifications, and even playing sound effects.
Check Mode: Running Ansible with the --check option is referred to as a "dry run" mode, which does not apply any changes to remote systems but only displays potential changes that could occur if the command were executed without this flag. This mode is similar to the "dry run" modes in other systems, but users should be aware that it does not account for unexpected command failures or cascading effects, which is also true for similar modes in other systems. This mode can provide an idea of what might happen, but it should not replace a well-configured staging environment.
Collection: Ansible content, such as plugins, roles, modules, and more, can be bundled and distributed using a packaging format called Collections. Collections have the advantage of being released independently from other collections or ansible-core, allowing features to become available to users more quickly. Some collections are included in the Ansible package (version 2.10 or later), while others can be installed using the command ansible-galaxy collection install <namespace.collection>. This enables users to install different collections or versions of collections as needed.
Collection name: The latter segment of a Fully Qualified Collection Name represents the collection name, which separates the collection namespace and typically indicates the purpose of the collection content. For instance, within the cisco namespace, you may find collections like cisco.ios, cisco.aci, and cisco.nxos, each tailored to manage various network devices offered by Cisco.
community.general (collection): An exclusive collection overseen by the Ansible Community Team that encompasses all the modules and plugins included in Ansible 2.9 without individual dedicated Collections. You can explore community.general on Galaxy to access these components.
community.network (collection): Similar to community.general, the collection community.network on Galaxy specializes in network-related content.
Connection Plugin: By default, Ansible communicates with remote machines using pluggable libraries. It utilizes either native OpenSSH (SSH (Native)) or a Python implementation known as paramiko. OpenSSH is the recommended choice, especially with recent versions, as it offers additional features like Kerberos support and jump hosts. This information is detailed in the getting started section. Other connection types include accelerate mode, which requires bootstrapping over an SSH-based connection but provides high speed, and local mode, which operates on the local system. Users also have the option to develop their own connection plugins.
Conditionals: A conditional is a statement that assesses whether it evaluates to true or false, determining if a specific task is executed on a particular machine. Ansible's conditionals are driven by the 'when' statement, which is covered in the Working with playbooks section.
D
Declarative: Achieving a task through a declarative approach involves specifying the desired end state rather than the sequence of steps required to reach it. For instance, a declarative description of a task might be: "transport me to California". Depending on your current location, the sequence of steps to reach California may differ, and if you're already in California, no action is needed. Ansible's Resources follow a declarative approach, determining the necessary steps to achieve the final state and notifying you if any actions were taken to reach that state.
Diff Mode: When using Ansible, you can include the --diff flag to display module changes for modules that support it. This flag can be paired with --check for a comprehensive 'dry run'. Typically, file differentials are presented in unified diff format.
Distribution server: A server, such as Ansible Galaxy or Red Hat Automation Hub, serves as a platform for sharing your collections and enabling others to access them. For a list of distribution server types, refer to Distributing collections. Certain Ansible features are exclusively available on specific distribution servers.
E
Executor: An essential software element within Ansible that drives /usr/bin/ansible directly and aligns with the execution of each task in a playbook. While the Executor is a term used by Ansible developers, it is not commonly used in user-facing discussions.
F
Facts: Facts in Ansible refer to information discovered about remote nodes. Unlike variables, facts are deduced rather than explicitly defined. Ansible automatically uncovers facts by executing the internal setup module on remote nodes during play runs. The setup module runs without the need for explicit invocation, but it can be disabled to save time if unnecessary, or users can specify a subset of facts to gather using the gather_subset: option. For users transitioning from other configuration management systems, the fact module can also retrieve facts from tools like ohai and facter if installed, which are fact libraries from Chef and Puppet, respectively. These additional sources can be disabled using gather_subset: as well.
Filter Plugin: Filter plugins are typically not essential for most users to understand. They facilitate the creation of new Jinja2 filters, which are primarily useful for those familiar with Jinja2 filters. If required, users can refer to the API docs section for instructions on writing filter plugins.
Forks: Ansible communicates with remote nodes concurrently, and the degree of parallelism can be adjusted by specifying --forks or modifying the default setting in a configuration file. By default, Ansible uses a conservative value of five (5) forks, but if your system has sufficient RAM, you can increase this value to, for example, 50 to enhance parallelism.
Fully Qualified Collection Name (FQCN): A Fully Qualified Collection Name (FQCN) represents the complete definition of a module, plugin, or role within a collection, in the format <namespace.collection.content_name>. This naming convention enables a Playbook to explicitly reference a specific module or plugin from a particular source, such as community.grafana.grafana_dashboard, ensuring no ambiguity. The FQCN is necessary when specifying the exact source of a plugin, especially when multiple collections contain a module plugin with the same name. For instance, if multiple collections include a plugin called user, the FQCN specifies which one to use for a given task. When multiple collections are installed, the FQCN serves as the explicit and authoritative indicator for identifying the correct plugin for each task within the desired collection.
G
Gather Facts (Boolean): Facts were previously discussed. When executing a multi-play playbook, there may be instances where some plays do not require fact computation, especially if they won't need to utilize any of the fact values. By setting gather_facts: False within a playbook, you can skip this implicit fact gathering, enhancing performance and efficiency.
Globbing: Globbing is a method for selecting multiple hosts based on wildcards, instead of specifying the host name or the group name directly. For instance, you can use ww* to match all hosts starting with www. This concept is derived from Func, an earlier project by Michael DeHaan, one of Ansible's founders. In addition to basic globbing, various set operations are also supported, such as selecting hosts within one group but not in another.
Group:A group refers to a collection of hosts assigned to a single pool, allowing for easy targeting as a unit and sharing common variables.
Group Vars: The group_vars/ directory contains files that reside alongside an inventory file, with optional filenames corresponding to each group. This directory serves as a convenient location for storing variables intended for a specific group, particularly complex data structures, to avoid embedding them directly in the inventory file or playbook.
H
Handlers: Handlers in Ansible playbooks resemble regular tasks (refer to Tasks for more information) but are executed only when a task includes a notify keyword and reports a change. For instance, if a configuration file is modified, a task referencing the file templating operation may notify a service restart handler. This approach ensures that services are restarted only when necessary. While handlers have various applications, service restarts are the most common use case.
Host:A host represents a remote machine managed by Ansible. Each host can have unique variables and can be categorized into groups. Every host has a name, which can be an IP address or a domain name, and an optional port number for accessing it through a non-default SSH port.
Host Specifier:In Ansible, each Play associates a sequence of tasks (defining the role, purpose, or instructions of a system) with a set of systems. The hosts: keyword in each play, also known as the hosts specifier, can target a single system, multiple systems, one or more groups, or even a combination of hosts from one group and explicitly excluding others.
Host Vars: Similar to Group Vars, a directory called host_vars/ can be placed alongside the inventory file, containing files named after each hostname in the inventory file, in YAML format. This arrangement offers a convenient method for assigning variables to a host without embedding them directly in the inventory file. The Host Vars file can also be utilized to define complex data structures that cannot be represented in the inventory file.
I
Idempotency: An operation is considered idempotent if executing it once produces the same result as performing it multiple times without any actions in between.
Includes: The concept of playbook files, which are essentially collections of plays, allows for the inclusion of other play lists. Task lists can also externalize tasks into separate files, as can handlers. These inclusions can be parameterized, enabling the loaded file to pass variables. For instance, a play included for setting up a WordPress blog could accept a parameter like user, allowing the play to be included multiple times to create blogs for different users, such as alice and bob.
Inventory: An inventory file, using a default INI format, outlines the Hosts and Groups in Ansible. This inventory can also be supplied through an Inventory Script, which is sometimes referred to as an "External Inventory Script".
Inventory Script: A straightforward or complex tool that retrieves host information, group associations, and variable details from an external source, such as a SQL database, a CMDB solution, or LDAP. This concept, inspired by Puppet's "External Nodes Classifier," functions in a similar manner.
J
Jinja2: Jinja2 is the preferred templating language for Ansible's template module, characterized by its simplicity and ease of use. It is a Python template language that is generally comprehensible and straightforward to write.
JSON: Ansible employs JSON for data transmission from remote modules, enabling modules to be developed in various languages, not limited to Python.
K
Keyword:The primary components that constitute Ansible, which apply to playbook objects (Play, Block, Role, and Task). For instance, the 'vars:' keyword allows for defining variables within the scope of the playbook object to which it is applied.
L
Lazy Evaluation: Typically, Ansible processes variables in playbook content at the final moment, allowing for data structures to define variable values within themselves. This seamless interaction ensures that everything functions as anticipated. Additionally, variable strings can contain other variables within them.
Library: A set of modules accessible to /usr/bin/ansible or an Ansible playbook.
Limit Groups: Using --limit somegroup with ansible or ansible-playbook allows restricting commands to a specific subset of hosts. This feature enables running a playbook that typically targets a full set of servers on just one particular server.
Local Action: This keyword serves as a substitute for delegate_to: localhost, employed when redirecting an action from the remote host to execute on the control node.
Local Connection: By incorporating connection: local in a playbook or using -c local with /usr/bin/ansible, this signifies executing a local fork rather than operating on the remote machine. However, this modification only affects the connection and does not alter any other execution context. For a more comprehensive change, consider using local_action or delegate_to: localhost.
Lookup Plugin: A lookup plugin serves as a method to bring external data into Ansible. These plugins, an extension of Jinja2, can be utilized within templates. For instance, you can access them using syntax like {{ lookup('file','/path/to/file') }}. Lookup plugins are instrumental in implementing functionalities like with_items. They encompass various types, such as the file plugin for loading data from files, as well as plugins for retrieving information from environment variables, DNS text records, or key-value stores.
Loops: Primarily, Ansible is not a programming language, favoring a more declarative approach. Although constructs like loop enable repeating a specific task for multiple items in a list, certain modules, such as yum and apt, can directly accept lists and install all packages within a single transaction. This feature significantly accelerates the overall configuration time, making it feasible to use these modules without loops.
M
Modules: Modules represent the fundamental units of work that Ansible distributes to remote machines. These modules can be initiated by either /usr/bin/ansible or /usr/bin/ansible-playbook, with multiple tasks employing various modules in conjunction. Modules can be developed in languages like Perl, Bash, or Ruby, but they can leverage shared library code if written in Python. Regardless of the language, modules must return JSON. After execution on remote machines, modules are removed, ensuring no long-running daemons are utilized. Ansible refers to the collection of available modules as a library.
Multi-Tier: In IT management, systems are not handled individually but through interactions among multiple systems and groups in defined sequences. For instance, updating a web server may precede updating a database server, followed by updating components on the web server after the database server. Additionally, load balancers and monitoring servers may require interaction. Ansible approaches IT management by modeling complete IT topologies and workflows, rather than focusing on configurations one system at a time.
N
Namespace: The initial component of a fully qualified collection name, the namespace typically mirrors a functional content category. For example, in cisco.ios.ios_config, cisco serves as the namespace. Namespaces are reserved and allocated by Red Hat, following their discretion. While many namespaces align with vendor names, not all of them do.
Notify: When a task triggers a change event and signals a handler task to execute another action at the play's conclusion, this process is known as handler notification. Even if multiple tasks notify a handler, it will only be executed once. Handlers are executed in the sequence they are listed, not based on the order of notification.
O
Orchestration: In software automation, the term "orchestration" holds diverse meanings. Ansible employs it to denote a conductor leading an orchestra. A data center or cloud architecture comprises numerous systems, each playing various roles, such as web servers, database servers, load balancers, monitoring systems, continuous integration systems, and so on. To execute any process, it is essential to engage systems in specific orders, often to replicate rolling updates or deploy software accurately. Some systems may carry out certain steps, followed by others, with previously processed systems potentially requiring additional steps. During this process, emails may need to be sent or web services contacted. Ansible orchestration focuses on modeling such processes.
P
paramiko: Ansible typically handles machine management via SSH by default, utilizing a Python-based library named paramiko. While paramiko is known for its speed and ease of use, users seeking to utilize Kerberos or Jump Hosts may opt to switch to a native SSH binary like OpenSSH. This can be achieved by specifying the connection type in their playbooks or utilizing the -c ssh flag.
Playbooks: Playbooks serve as Ansible's language for orchestrating, configuring, managing, or deploying systems. They are named playbooks partly due to their sports analogy, aiming to make the process enjoyable. It is important to note that they are not workbooks.
Plays: A playbook consists of plays, with each play minimally associating a set of hosts, selected by a host specifier (typically based on groups but occasionally by hostname patterns), with the tasks to be executed on those hosts. These tasks determine the role of the systems. A playbook can include one or multiple plays.
Pull Mode: By default, Ansible operates in push mode, granting precise control over when it communicates with each system. Pull mode is available for scenarios where nodes are preferred to check in at specific intervals, such as every N minutes on a set schedule. Pull mode utilizes a tool called ansible-pull and can be established or adjusted using a push-mode playbook. While push mode is the preferred choice for most Ansible users, pull mode offers an alternative for those seeking variety and flexibility.
ansible-pull: This system functions by retrieving configuration orders from git via crontab and subsequently managing the machine locally, employing the local connection plugin.
Pulp 3 Galaxy: A self-hosted distribution server, built on the GalaxyNG codebase and Pulp version 3, serves to discover and distribute your personally curated content. This server enables you to access your content using the ansible-galaxy collection command.
Push Mode: Push mode represents the default operation of Ansible, which is not a distinct mode but rather its standard behavior when not explicitly considered. Push mode empowers Ansible to execute tasks with precision and guide nodes through intricate orchestration processes without relying on their check-in intervals.
R
Register Variable: Upon executing any Ansible task, the outcome can be stored in a variable for use in templates or conditional statements. The keyword responsible for defining the variable is named register, inspired by the concept of registers in assembly programming. Ansible's user-friendly interface distinguishes it from assembly programming, allowing for an infinite range of variable names during registration.
Resource Model: Ansible modules operate based on resources, such as the file module managing a specific file and ensuring its attributes align with a defined model. For instance, you might desire changing the owner of /etc/motd to root if not already set, or setting its mode to 0644 if it deviates from this value. Resource models in Ansible are idempotent, meaning change commands are executed only when necessary. Ansible restores the system to the desired state, irrespective of the current state, eliminating the need to specify the exact steps to reach that state.
Roles: Roles serve as organizational units within Ansible, defining a particular behavior for a group of hosts (which can include multiple groups or host patterns). A role may involve applying specific variable values, tasks, and handlers, or a subset of these elements. Due to the file structure associated with roles, they become reusable units, enabling behavior sharing across playbooks and with other users.
Rolling Update: Implementing a rolling update strategy involves managing a group N of nodes in smaller batches, updating them gradually to prevent bringing the entire system offline simultaneously. For example, in a high-volume web topology with 500 nodes, updating 10-20 machines at a time before proceeding to the next batch could be a reasonable approach. Ansible's serial: keyword in playbooks controls the rolling update pool size. By default, all nodes are addressed at once, so the rolling update model must be explicitly enabled. While not typically required for OS configuration, such as ensuring correct config files, the rolling update model can be employed if desired.
S
Sudo: Ansible operates without the necessity of root logins and, being daemonless, does not rely on root-level daemons, which can pose security risks in sensitive environments. Ansible can execute various operations within a sudo command, supporting both password-less and password-based sudo configurations. Even tasks that typically do not function with sudo, such as scp file transfers, can be accomplished using Ansible's copy, template, and fetch modules while operating in sudo mode.
SSH (Native): To specify native OpenSSH as an Ansible transport, use the -c ssh flag, a config file, or a keyword in the playbook. This approach is beneficial when utilizing Kerberized SSH or SSH jump hosts, among other scenarios. In version 1.2.1, OpenSSH becomes the default transport if the control machine's OpenSSH binary is sufficiently up-to-date. Earlier, Ansible defaulted to paramiko. For optimal performance, employ a client supporting ControlMaster and ControlPersist. If these capabilities are unavailable and Kerberos, jump hosts, or other features are not required, paramiko remains a suitable choice. Ansible will issue a warning if it does not detect ControlMaster/ControlPersist capability.
T
Tags: In Ansible, you can assign arbitrary keywords to resources in a playbook through tagging, enabling the selective execution of specific sections based on these tags. For instance, you could label certain steps within an OS configuration playbook as ntp and then exclusively run the steps related to configuring the time server information on a remote host by specifying the corresponding tag.
Task: Playbooks are designed to execute tasks, which consist of an action (a module and its arguments) along with a name and potentially additional keywords like looping directives. Handlers, while also tasks, hold a unique role as they are triggered only when specifically named in response to a task signaling a change on a remote system.
Tasks: A list of Task.
Templates: Ansible facilitates file transfers to remote systems, and it often becomes necessary to insert variables within these files. Variables can originate from inventory files, Host Vars, Group Vars, or Facts. Ansible employs the Jinja2 template engine to manage templates, which supports logical constructs such as loops and conditional statements for inserting variables.
Transport: In Ansible, :term:Connection Plugins determine the various transport options available. These plugins dictate how Ansible establishes connections with managed systems. The available transports encompass paramiko, ssh (utilizing OpenSSH), and local connections.
W
When: A discretionary conditional statement linked to a task, used to ascertain whether the task should be executed or not. If the expression following the when: keyword evaluates to false, the task will be disregarded.
V
Vars (Variables): In contrast to Facts, variables represent the names of values, which can be basic scalar values (integers, booleans, strings) or complex ones (dictionaries/hashes, lists). Variables are explicitly declared, unlike Facts, which are inferred from the current state or characteristics of the remote system. Variables can be utilized in templates and playbooks.
Y
YAML: Ansible aims to simplify infrastructure automation without requiring users to write programming code. To achieve this, Ansible utilizes YAML for defining playbook configurations and variable files. YAML is favored for its minimal syntax, readability, and ease of comprehension. It serves as an excellent data format for both human-readable configuration files and machine interpretation. The adoption of YAML in Ansible traces back to Michael DeHaan's initial implementation within Cobbler circa 2006. YAML enjoys popularity within the dynamic language community, with libraries available for serialization in various languages like Python, Perl, Ruby, and more.
Guide to Install Ansible
Ready to dive into using Ansible? Ensure you have it installed correctly by following these detailed installation guides tailored to different distros.
With these installation guides, you'll be up and running with Ansible in no time!