home / skills / sigridjineth / hello-ansible-skills / ansible-convert

ansible-convert skill

/skills/ansible-convert

This skill helps convert shell scripts to Ansible playbooks by promoting idempotent, declarative tasks and appropriate module usage.

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

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

Files (1)
SKILL.md
3.6 KB
---
name: ansible-convert
description: Use when converting shell scripts to Ansible playbooks. Use when migrating bash automation, manual procedures, or Dockerfiles to idempotent Ansible tasks.
---

# Shell to Ansible Conversion

## Overview

Shell scripts execute commands imperatively; Ansible declares desired state. Conversion means rethinking operations as state declarations, not translating commands line-by-line. The goal is idempotency: running twice produces identical results.

## When to Use

- Converting existing shell scripts to playbooks
- Migrating manual server setup procedures
- Replacing bash automation with Ansible
- Converting Dockerfile RUN commands

## Core Principle

**Don't wrap shell commands in Ansible's `shell` module.** Find the module that achieves the same end state declaratively.

```bash
# Shell: imperative
mkdir -p /opt/app
chown app:app /opt/app
```

```yaml
# Ansible: declarative
- ansible.builtin.file:
    path: /opt/app
    state: directory
    owner: app
    group: app
    mode: '0755'
```

## Conversion Table

| Shell Command | Ansible Module | Notes |
|---------------|----------------|-------|
| `mkdir -p` | `ansible.builtin.file` | `state: directory` |
| `cp` | `ansible.builtin.copy` | Static files |
| `cp` with variables | `ansible.builtin.template` | Use `.j2` templates |
| `rm -rf` | `ansible.builtin.file` | `state: absent` |
| `ln -s` | `ansible.builtin.file` | `state: link` |
| `chmod`, `chown` | Include in file/copy/template | `mode`, `owner`, `group` params |
| `apt-get install` | `ansible.builtin.apt` | `update_cache: yes` |
| `yum install` | `ansible.builtin.yum` | Or use `package` for cross-platform |
| `pip install` | `ansible.builtin.pip` | Specify `executable` if needed |
| `useradd` | `ansible.builtin.user` | Handles home, shell, groups |
| `systemctl start` | `ansible.builtin.service` | `state: started` |
| `systemctl enable` | `ansible.builtin.service` | `enabled: yes` |
| `curl -O` | `ansible.builtin.get_url` | Use `checksum` for verification |
| `tar -xzf` | `ansible.builtin.unarchive` | `remote_src: yes` if already on target |
| `echo >> file` | `ansible.builtin.lineinfile` | Ensures line exists |
| `cat > file` | `ansible.builtin.copy` | `content:` parameter |

## Control Flow Conversion

### Conditionals

```bash
# Shell
if [ -f /etc/debian_version ]; then
    apt-get install nginx
fi
```

```yaml
# Ansible
- ansible.builtin.apt:
    name: nginx
  when: ansible_os_family == "Debian"
```

### Loops

```bash
# Shell
for user in alice bob; do
    useradd $user
done
```

```yaml
# Ansible
- ansible.builtin.user:
    name: "{{ item }}"
  loop:
    - alice
    - bob
```

## When Shell Module is Necessary

Use `command` or `shell` only when no module exists. Always add proper change detection:

```yaml
- name: Run custom installer
  ansible.builtin.shell: /opt/app/install.sh
  args:
    creates: /opt/app/.installed  # Skip if file exists
  register: install_result
  changed_when: "'Installed' in install_result.stdout"
  failed_when: install_result.rc != 0 and 'already installed' not in install_result.stderr
```

## Variable Extraction

Identify values to parameterize:
- Version numbers → `app_version: "1.2.3"`
- Paths → `app_dir: "/opt/app"`
- Usernames → `app_user: "appuser"`
- Ports → `app_port: 8080`

Place in `defaults/main.yml` for easy override.

## Conversion Workflow

1. Read entire script, identify major phases
2. Map each command to Ansible module
3. Extract hardcoded values as variables
4. Order tasks for dependencies (dirs before files)
5. Add handlers for service restarts
6. Test with `--check --diff`
7. Verify idempotency: second run shows no changes

Overview

This skill helps convert shell scripts, Dockerfile RUN steps, and manual bash procedures into idempotent Ansible playbooks. It focuses on mapping imperative commands to declarative Ansible modules, extracting variables, and structuring tasks for repeatable automation. The goal is reliable, testable playbooks that do not rely on shell wrappers except when absolutely necessary.

How this skill works

Inspect the shell script to identify commands, phases, and hardcoded values. For each command, recommend the corresponding Ansible module or a safe use of the shell/command module with change detection. Produce tasks in the correct order, add handlers, and extract variables into defaults for easy overrides. Emphasize testing with --check/--diff and validating idempotency.

When to use it

  • Migrating existing bash scripts to Ansible playbooks
  • Converting Dockerfile RUN commands into Ansible tasks
  • Replacing manual server setup steps with repeatable automation
  • Refactoring one-off install scripts into parameterized playbooks

Best practices

  • Prefer specific Ansible modules over shell/command to ensure idempotency
  • Extract versions, paths, users, and ports into variables in defaults/main.yml
  • Order tasks by dependency (create directories before copying files)
  • Use handlers for service restarts and register/changed_when for custom commands
  • Test with --check --diff and run a second apply to confirm no changes

Example use cases

  • Transform a bootstrap.sh that creates dirs, users, and installs packages into a playbook using file, user, and apt modules
  • Convert Dockerfile RUN steps that install packages and copy config into tasks with apt/yum, copy/template, and unarchive
  • Migrate a multi-step installer script by adding creates/changed_when around unavoidable shell calls
  • Parameterize an app install by moving hardcoded version and path values to defaults and group_vars

FAQ

When is it acceptable to keep a shell command?

Only when no module exists to express the desired state. Add args like creates, register results, and explicit changed_when/failed_when to enable change detection.

How do I ensure idempotency for custom installers?

Use file checks (creates), inspect output with register, and set changed_when/failed_when so subsequent runs skip or report correctly.