40 key Ansible automation terms with practical definitions: playbooks, roles, modules, collections, handlers, facts, idempotency, become, vault, Jinja2, and more.
- Ad-Hoc Command
- A one-line Ansible command that performs a quick task on remote hosts without writing a playbook. Uses the `ansible` command directly, ideal for one-off operations like restarting a service or checking disk space.
- Ansible
- An open-source IT automation engine that automates provisioning, configuration management, application deployment, orchestration, and many other IT processes. It is agentless, using SSH (or WinRM for Windows) to communicate with managed nodes.
- Ansible Galaxy
- A community hub and command-line tool for finding, sharing, and downloading Ansible roles and collections. Galaxy makes it easy to reuse automation content created by other community members.
- Ansible Tower / AWX
- Ansible Tower (now Ansible Automation Platform) is Red Hat's enterprise framework for controlling, securing, and managing Ansible automation with a UI, RBAC, and REST API. AWX is the open-source upstream project.
- Ansible Vault
- A feature that allows you to encrypt sensitive data such as passwords, keys, and credentials within Ansible files. Vault uses AES256 encryption and can encrypt entire files or individual variables.
- ansible-core
- The core package containing the Ansible automation engine, built-in modules (ansible.builtin collection), and the command-line tools. Separate from the `ansible` package which includes additional community collections.
- ansible.cfg
- The Ansible configuration file that controls default behaviors. Searched in order: ANSIBLE_CONFIG env var, ./ansible.cfg (current directory), ~/.ansible.cfg (home), /etc/ansible/ansible.cfg. Settings include default inventory, remote user, forks, and more.
- Become (Privilege Escalation)
- Ansible's mechanism for executing tasks with elevated privileges (like sudo). Controlled with `become: yes`, `become_user`, and `become_method` directives in playbooks.
- Block
- A grouping mechanism for tasks that allows applying common directives (become, when, tags) to multiple tasks at once. Blocks also support `rescue` and `always` sections for error handling, similar to try/catch/finally.
- Callback Plugin
- A plugin that responds to events during playbook execution. Used for custom logging, notification, profiling task performance, or changing output format. Common examples include `timer`, `profile_tasks`, and `json`.
- Collection
- A distribution format for Ansible content that can include playbooks, roles, modules, and plugins. Collections are the standard way to distribute and consume Ansible content, typically installed via `ansible-galaxy collection install`.
- Conditional (when)
- The `when` statement in Ansible that controls whether a task executes based on a condition. Supports Jinja2 expressions, variable checks, registered variable results, and facts-based logic.
- Control Node
- The machine where Ansible is installed and from which automation is run. Can be any Unix-like machine with Python installed. Windows is not supported as a control node.
- Facts
- System information automatically gathered by Ansible from managed nodes at the beginning of each play. Facts include OS type, IP addresses, disk space, memory, and more. Access via `ansible_facts` or `setup` module.
- Filter
- A Jinja2 function used in Ansible to transform data. Common filters include `default`, `map`, `select`, `selectattr`, `regex_replace`, `to_json`, and `combine`. Filters are applied using the pipe `|` syntax.
- Forks
- The number of parallel processes Ansible uses to execute tasks across hosts. Default is 5. Increasing forks (e.g., to 20 or 50) can dramatically speed up execution for large inventories.
- Galaxy Role
- A reusable unit of Ansible automation shared via Ansible Galaxy. Roles bundle tasks, handlers, variables, templates, and files into a standardized directory structure for easy sharing and reuse.
- Gathering Facts
- The automatic process at the start of each play where Ansible collects system information from managed nodes using the `setup` module. Can be controlled with `gather_facts: false` to speed up execution.
- Handler
- A special task that only runs when notified by another task using the `notify` directive. Commonly used to restart services after configuration changes. Handlers run once at the end of a play, regardless of how many times they are notified.
- Idempotency
- The property that running the same operation multiple times produces the same result as running it once. Ansible modules are designed to be idempotent — applying a playbook repeatedly won't cause unintended side effects.
- Inventory
- A list of managed nodes (hosts) organized into groups. Can be a simple INI or YAML file, or dynamic inventory scripts/plugins that pull host lists from cloud providers, CMDB, or other sources.
- Jinja2
- The templating engine used by Ansible for dynamic expressions and variables. Jinja2 syntax uses `{{ }}` for variables, `{% %}` for logic (loops, conditionals), and `{# #}` for comments.
- Lookup Plugin
- A plugin that retrieves data from external sources like files, environment variables, databases, or APIs. Used with the `lookup()` function or `{{ query() }}` in Jinja2 templates.
- Loop
- Ansible's mechanism for repeating a task with different items. Modern syntax uses `loop` keyword with lists. Supports `with_items`, `with_dict`, `with_fileglob`, and other lookup-based iteration patterns.
- Managed Node
- A remote system that Ansible manages. No agent software needs to be installed on managed nodes — Ansible connects via SSH (Linux/Unix) or WinRM (Windows) from the control node.
- Module
- A unit of code that Ansible executes on managed nodes. Modules are the building blocks of tasks — examples include `apt`, `yum`, `copy`, `template`, `file`, `service`, `command`, and `shell`. Over 3,000 modules are available.
- Molecule
- A testing framework for Ansible roles. Molecule provides scaffolding for creating, testing, and verifying roles across different operating systems using containers or virtual machines.
- Pipelining
- An Ansible SSH optimization that reduces the number of SSH connections by executing multiple tasks over a single connection. Enabled in ansible.cfg with `pipelining = True`. Can significantly improve playbook performance.
- Play
- A mapping between a set of hosts and the tasks to run on them. A play defines which hosts to target, what variables to use, and what tasks to execute. Multiple plays make up a playbook.
- Playbook
- A YAML file containing one or more plays that define automation workflows. Playbooks describe the desired state of systems in a declarative, human-readable format and are the primary way to use Ansible for complex automation.
- Plugin
- Code that augments Ansible's core functionality. Types include connection plugins, callback plugins, lookup plugins, filter plugins, and inventory plugins. Plugins execute on the control node, unlike modules which run on managed nodes.
- Register
- A directive that captures the output of a task into a variable for later use. Registered variables contain return code, stdout, stderr, and module-specific data. Essential for conditional logic based on task results.
- Role
- A way to organize playbooks and related files into a reusable structure. A role includes directories for tasks, handlers, variables, defaults, files, templates, and meta information. Roles promote code reuse and modularity.
- SSH Key
- The recommended authentication method for Ansible to connect to managed nodes. SSH key-based authentication is more secure than password authentication and enables passwordless automation.
- Strategy
- Controls how Ansible executes tasks across hosts. `linear` (default) executes each task on all hosts before moving to the next. `free` allows each host to run through tasks independently at its own pace.
- Tags
- Labels applied to tasks, plays, or roles that allow selective execution. Run only tagged tasks with `--tags` or skip them with `--skip-tags`. Useful for running subsets of a large playbook.
- Task
- A single unit of action in Ansible. Each task calls a module with specific arguments and runs on the targeted hosts. Tasks execute sequentially within a play.
- Template
- A file processed through the Jinja2 templating engine before being deployed to managed nodes. Templates use the `.j2` extension and can include variables, loops, and conditionals for dynamic configuration files.
- Variable
- Named values used to customize automation. Variables can be defined in inventory, playbooks, roles, command line, or gathered as facts. Ansible has a well-defined variable precedence order with 22 levels.
- YAML
- YAML Ain't Markup Language — the human-readable data serialization format used by Ansible for playbooks, variables, and inventory files. YAML uses indentation for structure and is sensitive to whitespace.