What is the difference between a 'play', a 'task', and a 'handler' in an Ansible Playbook?

A Playbook is a file containing one or more plays. A Play is a core unit of a playbook that maps a group of hosts (defined in your inventory) to a set of tasks. A Task is a single action executed by an Ansible module, such as installing a package, copying a file, or starting a service. A Handler is a special type of task that only runs when notified by another task. It is typically used for actions that should only occur if a change was made, like restarting a service after its configuration file is updated.

Ansible Playbook

Q: What is the primary language used to write an Ansible Playbook?

Ansible Playbooks are written in YAML (YAML Ain't Markup Language). YAML is a human-readable data serialization language that is designed to be easy to read and write, making it ideal for defining configuration files and automation workflows.

Beginner

An Ansible Playbook is a file where you define a set of tasks and configurations to be executed on remote servers. Written in YAML, it acts as a blueprint for automation, describing the desired state of a system in a human-readable format. It is the core component for configuration management and application deployment in Ansible.

First used·2012

Definitions·1

Synonyms·3

Category·DevOps

Also known as

Ansible scriptConfiguration scriptAutomation recipe

Definitions

What it means.

01
Core Component of Ansible Automation
An Ansible Playbook is the central file where automation workflows are defined in Ansible. It is a text file written in YAML format that contains a series of 'plays' to configure and manage a set of remote machines, known as managed nodes.

Structure of a Playbook

A playbook is a list of one or more plays. Each play has several key components:

hosts: Specifies the target machines for the play. This can be a group name from an inventory file (e.g., webservers), a specific hostname, or a pattern.

tasks: A list of actions to be executed on the target hosts. Tasks are run sequentially. Each task calls an Ansible module to perform a specific action, like installing a package or starting a service.

vars: Defines variables for use within the play.

handlers: Special tasks that are triggered by a notify directive from another task. They are typically used for actions like restarting a service only when its configuration has changed.

become: A directive (yes/no) that tells Ansible to use privilege escalation (e.g., sudo) to execute tasks.

Key Concepts

Declarative: You define the desired state of the system, not the specific commands to get there. For example, you declare that a package should be present or a service should be started. Ansible determines if any action is needed.

Idempotent: A core principle of Ansible. Running the same playbook multiple times on the same system will not result in changes after the first successful run, unless the system's state has drifted. This makes playbooks safe and predictable.

Orchestration: Playbooks can orchestrate complex, multi-tier deployments. You can have one play that configures database servers, followed by another play that configures web servers which depend on the databases, all within a single Ansible Playbook.

Simple Example

This playbook ensures the Apache web server is installed and running on all hosts in the webservers group.

--- - name: Configure and start Apache web server hosts: webservers become: yes tasks: - name: Install httpd package ansible.builtin.yum: name: httpd state: present - name: Ensure httpd service is running and enabled ansible.builtin.service: name: httpd state: started enabled: yes

Origin

Where it comes from.

Etymology

The term 'playbook' is borrowed from sports, particularly American football, where a playbook contains a team's strategies and plays. In Ansible, a playbook similarly contains the 'plays'—a set of ordered tasks—to be executed to achieve a desired system configuration.

Historical context

Ansible was created by Michael DeHaan and first released in February 2012. The concept of the Ansible Playbook was a foundational element from the very beginning. It was designed to offer a simpler, more human-readable alternative to the complex, often Ruby-based DSLs (Domain-Specific Languages) used by other configuration management tools at the time, like Puppet and Chef.

The choice of YAML for playbooks was a key design decision, prioritizing simplicity and ease of use. This allowed system administrators and developers who weren't programmers to easily write and understand automation workflows. This focus on simplicity helped drive Ansible's rapid adoption.

In 2015, Ansible, Inc. was acquired by Red Hat. This acquisition significantly boosted its credibility and adoption in enterprise environments, solidifying the Ansible Playbook as a standard for IT automation. Over time, playbooks have evolved to support more complex structures like roles and collections, but the core principle of a simple, declarative automation recipe remains unchanged.

Usage

In context.

The DevOps engineer wrote an Ansible Playbook to automate the entire setup of the new web server cluster.
To ensure consistency across environments, we execute the same Ansible Playbook for development, staging, and production servers.
Instead of a complex shell script, he created a simple Ansible Playbook, a more readable and idempotent configuration script, to manage the application's dependencies.

FAQ

Common questions.

Ansible Playbooks are written in YAML (YAML Ain't Markup Language). YAML is a human-readable data serialization language that is designed to be easy to read and write, making it ideal for defining configuration files and automation workflows.

Taxonomy

What it means.

Core Component of Ansible Automation

Structure of a Playbook

Key Concepts

Simple Example

Where it comes from.

In context.

Common questions.

Filed under.