YAML Ansible

Ansible automates the setup of computers. Logging into ten servers to type the same commands ten times wastes effort. A YAML file describes the desired result, and Ansible makes every server match it. These files are called playbooks.

Key Terms in Plain Language

Term	Meaning
Control node	The computer where you run Ansible
Inventory	The list of machines to manage
Playbook	A YAML file describing the work
Play	A block that links machines to tasks
Task	A single action, such as installing software
Module	A ready-made tool that performs a task

The Big Picture

                 +-----------------+
                 |  Control node   |
                 |  playbook.yaml  |
                 +--------+--------+
                          |
         +----------------+----------------+
         v                v                v
    +---------+      +---------+      +---------+
    | Server1 |      | Server2 |      | Server3 |
    +---------+      +---------+      +---------+
     same tasks run on every server

Your First Playbook

---
- name: Prepare web servers
  hosts: webservers
  become: true

  tasks:
    - name: Install nginx
      ansible.builtin.package:
        name: nginx
        state: present

    - name: Start nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

A playbook is a list of plays, so the file begins with a dash. The play targets the group named webservers and uses elevated rights through become. Two tasks follow, each calling a module with its settings.

Desired State

The word present describes an outcome rather than a command. Ansible checks the server first. An existing nginx installation stays untouched. A missing one gets installed. Running the playbook ten times gives the same result as running it once, a property known as idempotence.

The Inventory File

The inventory can also use YAML:

all:
  children:
    webservers:
      hosts:
        web1.example.com:
        web2.example.com:
    databases:
      hosts:
        db1.example.com:

Groups contain hosts. A host key with nothing after the colon is a null value, which Ansible accepts.

Variables

Variables keep playbooks flexible. Define them under vars and read them with double curly braces.

- name: Greeting server
  hosts: all
  vars:
    app_name: Shop
    app_port: 8080
  tasks:
    - name: Show message
      ansible.builtin.debug:
        msg: "{{ app_name }} runs on port {{ app_port }}"

A value that starts with curly braces needs quotes, because YAML would otherwise read the braces as a flow mapping.

Conditions and Loops

- name: Install tools
  ansible.builtin.package:
    name: "{{ item }}"
    state: present
  loop:
    - git
    - curl
    - htop
  when: ansible_os_family == "Debian"

The task runs three times, once per tool, and only on Debian-style systems.

Running a Playbook

ansible-playbook -i inventory.yaml playbook.yaml

The output lists every task with a status such as ok, changed, or failed. Use the --check option for a safe rehearsal that reports planned changes without applying them.

Helpful Habits

• Name every task so the output reads like a story.
• Use the full module name, such as ansible.builtin.package.
• Store secrets in Ansible Vault instead of plain files.
• Run ansible-lint before sharing a playbook.

Handlers

A handler is a task that runs only when another task reports a change. Restarting a web server after a configuration update is the classic case.

tasks:
  - name: Update site config
    ansible.builtin.copy:
      src: site.conf
      dest: /etc/nginx/conf.d/site.conf
    notify: Restart nginx

handlers:
  - name: Restart nginx
    ansible.builtin.service:
      name: nginx
      state: restarted

The restart happens once at the end of the play, and only when the file actually changed.

Roles

Large projects split playbooks into roles. A role is a folder with a standard layout for tasks, variables, and files. A playbook then lists the roles it needs, and the same role works across many projects. Roles keep each YAML file short and focused on a single job.

Why YAML Suits Automation

Playbooks read almost like plain English, so teammates with different backgrounds understand them. Version control tracks every change, and reviewers see exactly which task moved or which value changed. A new server joins the inventory, and the same playbook prepares it within minutes.

Common Mistakes

• Leaving out the dash at the start of a play or task, which turns the list into a mapping.
• Forgetting quotes around a value that begins with curly braces.
• Misaligning keys inside a task so that a module setting lands at the wrong level.
• Naming two tasks identically, which makes the output confusing.

The command ansible-playbook --syntax-check playbook.yaml catches structural errors before any server is touched.

YAML skills transfer directly. Correct indentation, quoted braces, and careful lists decide whether a playbook runs smoothly.