Foundations of Ansible

Explore essential Ansible concepts, terminology, and tools, then set up your environment to start writing  your first Ansible playbook.

Start your Ansible Automation Platform Trial

Now that we have basic understanding of Ansible, let's look at some more key concepts and terminology that you will need to know while using Ansible.

In this lesson, you will:

  • Learn about Ansible playbooks and inventory files. 
  • Learn about modules, collections, and frequently used Ansible terms.

Playbook Overview

Now that we’ve covered basic Ansible concepts, we’ll learn more about Ansible Playbooks. The following terms (shown in Figure 1) are necessary to understand before proceeding:

Task: A reference to a single module that defines the operations that Ansible performs. Tasks are executed in the order in which they are written. Each task calls an Ansible module.

Play: An ordered list of tasks that maps to managed nodes in an inventory. Each play executes part of the playbook's overall goal, running one or more tasks.

Playbook: An Ansible playbook is a list of tasks or instructions that automatically executes against a specified inventory or groups of hosts. One or more Ansible tasks can be combined to make a "play." A playbook can include one or more plays displayed in an ordered list and is executed top to bottom.

Roles: Roles provide a structured way to organize Ansible content such as tasks, templates, files, and variables into a reusable format.

Figure shows structure of Ansible playbook.
Figure 1: Ansible playbook overview.

Inventory

An inventory contains information about the managed nodes you want Ansible to orchestrate. Inventories can group nodes, allowing you to simultaneously run playbooks on multiple hosts. Inventories are commonly created in YAML or INI format.

The example below shows an INI inventory file with three managed nodes. The managed nodes are in the web inventory group:

[web]
node1.example.com
node2.example.com
node3.example.com

Example INI inventory file.

Modules

Modules are reusable, standalone scripts that Ansible runs on managed nodes. They are the basic units of code that Ansible executes. Each module has a specific task, such as installing packages or copying files, and is configurable using parameters.

Ansible modules are grouped in collections with a Fully Qualified Collection Name (FQCN) for each module. Tasks are executed by modules, each of which performs a specific task in a playbook. A module contains metadata that determines when and where a task is executed, as well as which user executes it.

- name: Copy the myfile.txt file to /tmp
  ansible.builtin.copy:
    src: myfile.txt
    dest: /tmp/
    mode: 0644

Ansible module example.

In the example above, the copymodule is called using the full FQCN ansible.builtin.copy.

Collections

Ansible Content Collections are a distribution format that contains various types of automation content, including modules, roles, playbooks, and more. It is portable and reusable, making it ideal for bundling and distributing automations designed to work together.

Collections are versioned and can be shared and discovered using automation hub for certified and supported collections or Ansible Galaxy for community collections, as shown below:

 - name: Enable https traffic through the firewall
     ansible.posix.firewalld:
       port: 443/tcp
       permanent: true
       state: enabled

Ansible collection example.

In the example above, we’re using the firewalld module from the ansible.posix Collection.

Related Ansible Terminology

Variables are used to execute tasks and playbooks across multiple systems with a single command. To account for variations among different systems, you can create variables using standard YAML syntax, including lists and dictionaries. You can define these variables in playbooks, inventory files, reusable files, or roles, and even create them during playbook runs by registering task return values as new variables.

Facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. These facts are automatically discovered by Ansible when it interacts with managed nodes. They are stored as variables and serve as essential information for making decisions during playbook execution and configuration management.

Templates allow you to create customized configuration files, scripts, or any other text-based content. They are used to generate output dynamically by replacing placeholders (variables) with actual values. These placeholders can be populated from variables, facts, or other data sources, making templates a powerful tool for creating reusable and flexible configurations in Ansible.

Automation execution environments are container images that make it possible to incorporate system-level dependencies and collection-based content. Each execution environment allows you to have a customized image to run jobs, and each of them contain only what you need when running the job.

Playbook Syntax

Playbooks are expressed in YAML format with a minimum amount of text. If you are not familiar with YAML, see the next learning path, YAML Essentials for Ansible Automation Platform. We also suggest using a text editor to help you write well-structured YAML in your playbooks.

- name: Network Getting Started First Playbook Extended
  connection: ansible.netcommon.network_cli
  gather_facts: false
  hosts: all
  
  tasks:
    - name: Get config for VyOS devices
      vyos.vyos.vyos_facts:
        gather_subset: all
        
    - name: Display the config
      debug:
        msg: "The hostname is {{ ansible_net_hostname }} and the OS is {{ ansible_net_version }}"

Playbook execution

A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple plays can orchestrate complex workflows, running one play on your web servers,  another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things:

  • The managed nodes to target using a pattern
  •  At least one task to execute

In the following example, the first play targets the web servers and the second play targets the database servers:

- name: Update web servers
  hosts: webservers
  
  tasks:
  - name: Ensure apache is at the latest version
    ansible.builtin.yum:
      name: httpd
      state: latest
      
- name: Update db servers
  hosts: databases
  
  tasks:
  - name: Ensure postgresql is at the latest version
    ansible.builtin.yum:
      name: postgresql
      state: latest

Additional resources:

Previous resource
Introduction to Ansible
Next resource
Introduction to Git and GitHub