Ansible : Vocabulary and Cheat Sheet

Introduction

#

Ansible is an open-source automation tool that simplifies configuration management, application deployment, and system orchestration.
It’s part of the Infrastructure as Code (IaC) family of tools, meaning your infrastructure and configurations are written as code, version-controlled, and repeatable.

It’s agentless, meaning it doesn’t require any software installation on managed systems, only SSH access and Python.

Before diving into playbooks or automation workflows, it’s essential to understand Ansible’s vocabulary.

Vocabulary

#

Basic Concepts

#

• Control Node : The machine where Ansible is installed and from which automation is executed.
• Managed Node / Host : The remote system Ansible manages or configures.
• Inventory : A file listing managed nodes and their groupings.
• Host Group : A named set of hosts sharing common configurations or roles.
• Dynamic Inventory : Inventory that’s generated programmatically from an external source.
• Static Inventory : A manually defined inventory file (usually hosts.ini).
• Facts : System information automatically gathered from managed nodes.
• Facts Gathering : The process of collecting system data before executing tasks.

Playbooks and Tasks

#

• Playbook : A YAML file defining a series of plays to execute on hosts.
• Play : A mapping between a group of hosts and the tasks to run on them.
• Task : A single action (installing a package, copying a file) executed on a host.
• Module : A reusable unit of code that performs a specific task (apt, copy, user, etc.).
• Handler : A special task triggered by a “notify” event, typically for service restarts.
• Role : A structured way to organize playbook content into reusable components.
• Ad-Hoc Command : A one-time Ansible command run without a playbook.
• Tag : A label used to selectively run specific tasks or plays.
• Conditionals : Logic allowing tasks to run only when certain conditions are true.
• Loop : A mechanism to repeat a task multiple times with different inputs.
• When Statement : A conditional expression determining whether a task runs.
• Register Variable : A variable used to store the result/output of a task.
• Delegation : Running a task on a different host (delegate_to).
• Become (Privilege Escalation) : Allows running tasks with elevated privileges (sudo).
• Idempotence : Ensures tasks only make changes when necessary, avoiding repetition.

Variable and Templates

#

• Variable : A named value that can change depending on context (host, group, etc.).
• Defaults : The lowest-precedence variables defined in a role.
• Vars : Higher-precedence variables defined for roles or plays.
• Template : A text file (usually Jinja2-based) that supports variable substitution.
• Jinja2 : The templating engine Ansible uses to render dynamic content.

Plugins and Extensions

#

• Plugin : A piece of code extending Ansible’s functionality.
• Lookup Plugin : Retrieves data from external sources (files, environment variables).
• Filter Plugin : Modifies or transforms data inside templates or variables.
• Callback Plugin : Controls how Ansible outputs results and events.
• Connection Plugin : Defines how Ansible connects to managed nodes (SSH, local, etc.).
• Inventory Plugin : Loads inventory dynamically from cloud providers or APIs.
• Strategy Plugin : Determines the order and parallelism of task execution.

Directory Structure

#

• Roles Directory Structure : Standard layout for organizing roles.
• Tasks Directory : Contains task definitions (main.yml) for a role.
• Handlers Directory : Contains handler definitions for a role.
• Templates Directory : Contains Jinja2 templates used by the role.
• Files Directory : Contains static files to be transferred to hosts.
• Meta Directory : Contains metadata about a role (dependencies, author, etc.).

Configuration and Commands

#

• Ansible Config File : The configuration file controlling Ansible behavior.
• ansible.cfg : The main configuration file defining defaults and paths.
• Check Mode (Dry Run) : Simulates playbook execution without making changes.
• Local Action : A task executed on the control node instead of the managed node.
• Vault : Encrypts sensitive data within Ansible files.
• Collection : A package containing roles, modules, and plugins for distribution.
• Galaxy : Ansible’s repository for sharing and downloading collections and roles.

Common Commands

#

• ansible : Executes ad-hoc commands on managed nodes.
• ansible-playbook : Runs playbooks on the inventory.
• ansible-inventory : Displays, validates, or transforms inventory data.
• ansible-vault : Manages encryption and decryption of vault-protected files.
• ansible-galaxy : Manages installation and creation of roles and collections.
• ansible-pull : Runs playbooks in pull mode (nodes pull configuration from a repo).
• ansible-push : Experimental feature to push configurations automatically.

Prerequisites

#

Before running your first playbook, make sure the following requirements are met:

• Control Node: Ansible installed (usually on Linux or macOS).
• Managed Node: Accessible via SSH and running Python 3.
• SSH Access: Generate an SSH key on the control node and copy the public key to each managed node using:

  ssh-copy-id user@managed-node

Cheat Sheet

#

More Resources

#

• Ansible Documentation
• Ansible Galaxy
• Getting Started Guide