become tells Ansible to escalate privileges, usually via sudo, before running a task. Installing packages and managing services needs root, so become true is set at the play level for those tasks.

Which modules does this use?

It uses the fully qualified ansible.builtin modules: apt or yum for packages, service for daemons, and copy for files. Fully qualified names avoid collection ambiguity in modern Ansible.

How do I target specific hosts?

The hosts value names a group from your inventory file. Use all to target every host, or a group name like webservers that you defined in your inventory hosts file.

Are the tasks idempotent?

Yes. The package, service, and copy modules are declarative and only make changes when the system differs from the desired state, so re-running the playbook is safe.

Variables you add appear under the play-level vars block and can be referenced in tasks with the double-brace Jinja syntax. They are a convenient place for ports, paths, or version numbers.

What is the Ansible Playbook Builder?

Creates an Ansible playbook with hosts, vars, become, and a task list covering common server setup steps like apt or yum packages, service management, and file copies — valid YAML ready to run with ansible-playbook. It runs free in your browser on Gera Tools, with nothing uploaded.

Ansible Playbook Builder

Name: Ansible Playbook Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Build an Ansible playbook without the YAML pitfalls

Ansible playbooks are powerful but unforgiving about indentation and module names. A single mis-indented task or a deprecated short module name can stop a run cold with a cryptic error. This builder assembles a clean, valid playbook from simple inputs so you can focus on what to provision rather than YAML syntax.

How it works

The output is a single-play playbook — a YAML list containing one mapping with the keys Ansible expects at the play level:

- name: <your play name>
  hosts: <target group>
  become: true
  vars:
    http_port: 80
  tasks:
    - name: Install packages
      ansible.builtin.apt:
        name:
          - nginx
          - git
        state: present
    - name: Enable and start nginx
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

Every task uses fully qualified ansible.builtin.* module names. Short names like apt or service still work but generate warnings in modern Ansible and will break if a collection with the same name is installed. The builder emits two-space indentation throughout, which is the YAML standard Ansible expects, and quotes string values only when YAML would otherwise misparse them.

What each generated task does

Package install — uses ansible.builtin.apt (Debian/Ubuntu) or ansible.builtin.yum (RHEL/CentOS) with state: present. Safe to re-run: if the package is already installed, Ansible does nothing.
Service management — uses ansible.builtin.service with state: started and enabled: true. This starts the service immediately and registers it to start on boot.
File copy — uses ansible.builtin.copy with a src (local file on the control machine) and dest (absolute path on the remote host). Specify mode in octal if you need non-default permissions.

Practical guidance

Save the result as site.yml and run it with:

ansible-playbook -i inventory site.yml

Or target a single host for testing:

ansible-playbook -i "192.168.1.10," site.yml

Note the trailing comma — it tells Ansible the inventory is an inline host list, not a file.

Common mistakes to avoid

Forgetting become: true when installing packages. Package managers need root and Ansible will silently fail with a permissions error unless escalation is enabled.
Mixing tabs and spaces. YAML rejects tabs. If your editor inserts tabs, the playbook will fail to parse. This builder uses spaces only.
Using the wrong package module for your distribution. Specify apt for Debian-family systems and yum or dnf for RHEL-family; the builder lets you choose.
Hardcoding paths and ports in tasks. Put variable values in the vars block and reference them with {{ variable_name }} so you can override them at runtime with -e or in group vars.