Master YAML and Ansible: From Basics to Playbook Automation

YAML Introduction

YAML is a human‑readable data‑serialization format that draws inspiration from XML, C, Python, Perl, and RFC2822 email syntax. It was first published by Clark Evans in 2001, with Ingy döt Net and Oren Ben‑Kiki as co‑designers. The name stands for “YAML Ain’t Markup Language”, though it originally meant “Yet Another Markup Language”.

Key characteristics of YAML include:

High readability

Good interaction with scripting languages

Use of native data types of the implementation language

A consistent information model

Ease of implementation

Stream‑based processing

Strong expressive power and extensibility

YAML Syntax

YAML’s syntax resembles other high‑level languages and can represent lists, maps, and scalars. Structure is indicated by indentation, list items start with “-”, and map entries are separated by “:”. Files typically use the .yaml or .yml extension.

Example:

List example (each element prefixed with “-”):

Dictionary example (key‑value pairs separated by “:”):

Inline map syntax using braces:

Variables in YAML (Ansible)

Variable names may contain letters, numbers, and underscores, and must start with a letter.

Facts are information gathered from remote hosts and stored as Ansible variables. Retrieve all facts with: # ansible hostname -m setup Custom variables can be defined using the vars keyword in a playbook:

Variable references are shown below:

Loops (iteration) can be performed with with_items:

Example adding two users using a variable:

Variable‑based loop:

Iterating over a list of hashes:

Inventory File Format

An inventory file follows the INI style; sections in square brackets denote groups. A host can belong to multiple groups, and a non‑default SSH port can be specified with host:port.

If host names follow a pattern, they can be expressed with a list syntax:

Host variables can be defined directly in the inventory for use in playbooks:

Group variables apply to all hosts in a group:

Groups can be nested, and nested groups can also have variables (usable only inside playbooks):

Common inventory parameters for SSH connections are shown below:

Playbooks

A playbook consists of one or more plays, each targeting a set of hosts and executing a list of tasks. A task essentially invokes an Ansible module, and modules are idempotent.

Hosts and Users : Each play specifies the target hosts (by name or group) and the remote user (via remote_user or sudo_user for privilege escalation).

Task List and Action : Tasks are executed sequentially on all specified hosts. Each task should have a name for readable output. Tasks are defined using the “module: options” syntax; the older “action: module options” form is also supported.

Only the command and shell modules accept a simple list without key‑value pairs.

If a command returns a non‑zero exit code, you can use ignore_errors or handle the failure explicitly:

Handlers : Defined like tasks, handlers are triggered by the notify action when a task reports a change, allowing a single execution after all changes are made.

Tags : Tags let users run or skip specific parts of a playbook. Because Ansible is idempotent, unchanged tasks are automatically skipped, but tags can be used to explicitly limit execution.

Example workflow for deploying a web service:

Provide an inventory file.

Create the playbook.

Prepare configuration files (e.g., src=/root/httpd.conf).

Run the playbook to perform the deployment.

After deployment, verify the service port:

If configuration changes, re‑run the playbook to apply updates.