home / skills / sigridjineth / hello-ansible-skills / ansible-interactive

ansible-interactive skill

/skills/ansible-interactive

This skill guides you through interactive Ansible development with incremental validation, setup, and hands-on playbook creation.

npx playbooks add skill sigridjineth/hello-ansible-skills --skill ansible-interactive

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.3 KB
---
name: ansible-interactive
description: Use when guiding someone through Ansible setup step-by-step. Use when starting a new Ansible project from scratch. Use when teaching Ansible through hands-on development.
---

# Interactive Ansible Development

## Overview

Interactive development builds automation incrementally with continuous validation. Each component is tested before adding the next. This catches errors early when they're easy to diagnose.

## When to Use

- Setting up Ansible for a new environment
- Teaching someone Ansible hands-on
- Building playbooks incrementally with validation
- Troubleshooting connectivity before automation

## Development Phases

### Phase 1: Environment Analysis

Gather before writing any code:

| Question | Why It Matters |
|----------|----------------|
| How many servers? | Affects inventory organization |
| IP addresses/hostnames? | Required for inventory |
| SSH user and key location? | Connection configuration |
| Password or key auth? | Determines SSH setup |
| Sudo with or without password? | Privilege escalation config |
| Server roles (web, db, app)? | Inventory grouping |
| Operating systems? | Module selection (apt vs yum) |

Verify Ansible is installed: `ansible --version`

### Phase 2: Project Setup

Create minimal structure:

```bash
mkdir ansible-project && cd ansible-project
```

**ansible.cfg:**
```ini
[defaults]
inventory = ./inventory
host_key_checking = False
stdout_callback = yaml

[privilege_escalation]
become = True
become_method = sudo
```

**inventory:**
```ini
[webservers]
web1 ansible_host=192.168.1.10 ansible_user=admin ansible_ssh_private_key_file=~/.ssh/id_rsa

[dbservers]
db1 ansible_host=192.168.1.20 ansible_user=admin ansible_ssh_private_key_file=~/.ssh/id_rsa
```

### Phase 3: Connectivity Test

**Always test before writing playbooks:**

```bash
ansible all -m ping
```

| Result | Action |
|--------|--------|
| SUCCESS | Proceed to playbooks |
| UNREACHABLE | Check `ssh -v user@host` |
| Permission denied | Verify key path, permissions (600) |
| Sudo password required | Add `--ask-become-pass` or configure NOPASSWD |

### Phase 4: Incremental Playbook Development

Start simple, add one task at a time:

```yaml
# playbook.yml - start with facts
---
- hosts: all
  tasks:
    - name: Show OS info
      ansible.builtin.debug:
        msg: "{{ ansible_distribution }} {{ ansible_distribution_version }}"
```

Run: `ansible-playbook playbook.yml`

Then add tasks one by one, testing after each:

```yaml
    - name: Ensure nginx installed
      ansible.builtin.package:
        name: nginx
        state: present
```

Run again. Fix any errors before adding more.

### Phase 5: Validation Cycle

After each change:

1. `ansible-playbook --syntax-check playbook.yml`
2. `ansible-playbook --check --diff playbook.yml`
3. `ansible-playbook playbook.yml`
4. Run again—verify `changed=0` (idempotency)

## Red Flags - Stop and Debug

- Adding multiple untested tasks at once
- Skipping `--check` before real runs
- Ignoring "changed" on second run
- Not testing SSH before writing playbooks

## Communication Pattern

When guiding users:
- Explain what will happen before running commands
- After completion, summarize what was done
- When multiple approaches exist, present options with tradeoffs
- Acknowledge progress at milestones

Overview

This skill guides users through hands-on, incremental Ansible development and troubleshooting. It focuses on setting up a minimal project, validating connectivity, building playbooks one task at a time, and enforcing a repeatable validation cycle. The approach reduces debugging time by catching issues early and promoting idempotent automation.

How this skill works

The skill walks through five practical phases: environment analysis, project scaffolding, connectivity testing, incremental playbook development, and validation. It provides concrete commands and file examples (ansible.cfg, inventory, basic playbook snippets) and enforces a check-run-apply workflow using syntax-check and --check runs before real execution. Guidance includes SSH troubleshooting, privilege escalation setup, and methods to confirm idempotency.

When to use it

  • Starting a new Ansible project from scratch and needing a reproducible structure
  • Teaching or mentoring someone with step-by-step, hands-on Ansible exercises
  • Validating connectivity and SSH configuration before writing playbooks
  • Building playbooks incrementally to reduce regression and debugging time
  • Troubleshooting why playbooks are not idempotent or failing on hosts

Best practices

  • Collect host details and auth info before writing inventory or playbooks
  • Create a minimal ansible.cfg and simple inventory to avoid surprises
  • Always run ansible all -m ping to confirm connectivity first
  • Add one task at a time and test after each change to isolate failures
  • Use ansible-playbook --syntax-check and --check --diff before applying
  • Confirm idempotency by re-running and expecting changed=0

Example use cases

  • Walk a new team member through configuring SSH keys, inventory, and a first playbook
  • Bootstrap a small environment: install nginx on web servers with single-task iterations
  • Diagnose unreachable hosts by comparing ansible ping results to ssh -v output
  • Convert manual shell steps into atomic Ansible tasks and validate each step
  • Teach privilege escalation patterns and how to handle sudo with or without passwords

FAQ

What if ansible all -m ping shows UNREACHABLE?

Run ssh -v to inspect the SSH handshake, verify the host, IP, user, and key permissions (600), and confirm ansible_host and ansible_user in inventory.

How do I handle sudo that asks for a password?

Either run ansible-playbook with --ask-become-pass or configure NOPASSWD for the user; ensure ansible.cfg has become=True and correct become_method.