Reading an Ansible Playbook

Mental model

Cisco objective 5.8 says “Interpret the workflow being automated by an Ansible playbook (management packages, user management related to services, basic service configuration, and start/stop)”.

An Ansible playbook is YAML describing one or more plays. Each play says:

• hosts — which inventory group to run against.
• tasks — an ordered list of steps.
• Each task has a name (human description) and a module (what to do).

Read three things, in this order: hosts → task names → module names. The intent is usually obvious.

Worked example 1 — package install

- hosts: webservers
  become: yes
  tasks:
    - name: Install nginx
      apt:
        name: nginx
        state: present

    - name: Start nginx service
      service:
        name: nginx
        state: started
        enabled: yes

Answer

• Hosts: webservers group.
• Task 1: apt module → install the nginx package.
• Task 2: service module → start nginx and enable at boot.

Workflow: “Install nginx and make sure it starts on boot on every host in the webservers group.”

Worked example 2 — user management

- hosts: all
  become: yes
  tasks:
    - name: Create admin user
      user:
        name: admin
        groups: sudo
        shell: /bin/bash
        state: present

    - name: Deploy SSH public key for admin
      authorized_key:
        user: admin
        key: "{{ lookup('file', 'admin_rsa.pub') }}"

Answer

• Hosts: all (every host in inventory).
• Task 1: user module → create the admin user, in the sudo group.
• Task 2: authorized_key → push the admin’s SSH public key.

Workflow: “Create an admin account with sudo and SSH key access on every managed host”.

Worked example 3 — Cisco network config

- hosts: switches
  gather_facts: no
  connection: network_cli
  tasks:
    - name: Set NTP server
      cisco.ios.ios_ntp:
        server: 10.0.0.1
        state: present

    - name: Set syslog server
      cisco.ios.ios_logging:
        dest: host
        name: 10.0.0.2
        state: present

    - name: Save running config
      cisco.ios.ios_command:
        commands:
          - write memory

Answer

• Hosts: switches.
• connection: network_cli → SSH to each switch.
• Tasks: configure NTP, configure syslog, save config.

Workflow: “Push NTP (10.0.0.1) and syslog (10.0.0.2) config to every Cisco IOS switch and save”.

Worked example 4 — service rollout with vars

- hosts: web
  become: yes
  vars:
    http_port: 8080

  tasks:
    - name: Install Python app server
      pip:
        name: gunicorn

    - name: Push systemd unit for the app
      template:
        src: myapp.service.j2
        dest: /etc/systemd/system/myapp.service
      notify: restart myapp

    - name: Enable and start the service
      service:
        name: myapp
        state: started
        enabled: yes

  handlers:
    - name: restart myapp
      service:
        name: myapp
        state: restarted

Answer

• Hosts: web.
• Install Python package gunicorn.
• Render a systemd unit file from a Jinja2 template, store at /etc/systemd/system/myapp.service.
• notify: restart myapp → if the template changed, run the restart myapp handler at play end.
• Enable + start the service.

Workflow: “Deploy and start the Python app myapp on every web host, restarting it if the unit file changed”.

Common Ansible modules worth knowing by name

The pattern: module names are noun-first for configuration (cisco.ios.ios_ntp) and verb-first for one-off actions (debug, assert).

Variables, loops, conditionals (brief)

- name: Create VLANs
  cisco.ios.ios_vlans:
    config:
      - vlan_id: "{{ item.id }}"
        name: "{{ item.name }}"
  loop:
    - { id: 10, name: data }
    - { id: 20, name: voice }
    - { id: 99, name: management }
  when: ansible_distribution_version is version('17', '>=')

• {{ var }} interpolates a variable (Jinja2 syntax).
• loop: runs the task once per list item (item.id, item.name are the current entry).
• when: conditional; task runs only if the expression is true.

Reading tips

1. Jump to the first hosts: to see the target.
2. Scan tasks: names top to bottom — that is the English story.
3. Look at the modules only when a task name is unclear.
4. Ignore vars, handlers, tags on first read.

FAQ

What if the playbook uses roles? Each - role: nginx is a bundled set of tasks (and vars and templates). Read the role’s tasks/main.yml for the equivalent task list.

What is gather_facts? Ansible runs an implicit “collect info about the host” task first. On network devices without a Python interpreter, you disable it: gather_facts: no.

What does become: yes do? Run the tasks as root (via sudo). Required for installing packages, writing to /etc/, etc.

Why do some playbooks use delegate_to? Run a task on a different host than the current one in the loop. Common for “update DNS from a config change” style workflows.