Ansible Playbook Generator

Assemble an Ansible playbook in YAML: Nginx, Docker, PostgreSQL and users with SSH keys.

Secure (SSL)

Client-Side Processing

100% Free

Go to tool

Instructions

1

Enter data
Enter content, paste text or load a file from disk.
2

Click the button
The tool will immediately process your data in the browser.
3

Get the result
Copy the finished text or save the file to your device.

                                                function runTool() {

                                                  return "Result ready in 0.1s";

                                                }

Playbook name

Host group (hosts)

Tasks

Nginx

Docker

PostgreSQL

Users and SSH keys

Options

Use sudo (become)

Gather facts

Handlers

Tasks: 6

---
- name: Konfiguracja serwera
  hosts: webservers
  become: true
  gather_facts: true
  tasks:
    - name: Install Nginx
      ansible.builtin.apt:
        name: nginx
        state: present
      notify: Restart Nginx
    - name: Deploy Nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/sites-available/default
      notify: Restart Nginx
    - name: Install Docker
      ansible.builtin.apt:
        name: docker.io
        state: present
    - name: Enable the Docker service
      ansible.builtin.service:
        name: docker
        state: started
        enabled: true
    - name: Create the deploy user
      ansible.builtin.user:
        name: deploy
        groups: sudo
        shell: /bin/bash
    - name: Add the SSH key
      ansible.posix.authorized_key:
        user: deploy
        key: "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
  handlers:
    - name: Restart Nginx
      ansible.builtin.service:
        name: nginx
        state: restarted

An Ansible playbook is a YAML file that describes the desired state of a server. Every task uses a module (such as apt, service or user) and is idempotent, so running it again does not break the system. The handlers section fires only when a task reports a change, for example a Nginx restart after its configuration changes.

Rate this tool:

Related tools

Other tools you may find useful

Ansible playbook generator - server configuration described in YAML

The Ansible playbook generator assembles a ready YAML file in which a single play describes the desired state of a server: the host group, the become mode, a list of tasks and a handlers section. You tick which roles to deploy - Nginx, Docker, PostgreSQL, users with SSH keys - and the tool produces a complete playbook.yml you run with ansible-playbook.

What a playbook is and what this tool does

Ansible manages servers without an agent: it connects over SSH and runs Python modules on the remote machine. A playbook is a YAML file that describes the target state, not a sequence of commands. You give a playbook name and a host group from inventory, pick tasks, and get the structure: - name, hosts, become, gather_facts, tasks and, when needed, handlers. The host group is required: without a hosts entry Ansible does not know what to run the play against, so the tool reports an error instead of creating an incomplete file.

A playbook is one of the three pillars of a deployment. Inventory describes the list of servers, the application image is built in the Dockerfile generator, and if you deploy to a cluster, the manifest is prepared in the Kubernetes deployment generator.

Presets: web server, Docker host, database

Three quick-start buttons set the name, host group and task set for typical roles. Web server is Nginx plus users in the webservers group. Docker installs and starts the Docker service for the dockers group. Database sets up PostgreSQL along with a deploy account for the databases group. A preset is a starting point - after clicking it you can freely add or remove tasks.

Tasks in the generated playbook

Task	Modules and what it sets up
Nginx	Install via `apt` and deploy config via `template` from `nginx.conf.j2`
Docker	Install `docker.io` and enable and start the service via `service`
PostgreSQL	Install `postgresql` and start the service with `enabled: true`
Users	A `deploy` account in the `sudo` group and adding a key via `authorized_key`

Tasks always go into the file in a fixed order (Nginx, Docker, PostgreSQL, users), regardless of the order in which you tick them. An empty selection is an error - tasks cannot be an empty section, because Ansible rejects a play with no tasks.

Idempotence - why you can run it repeatedly

Each module checks the current state and acts only when needed. state: present installs a package if it is missing and changes nothing on the next run. As a result you can run the same playbook many times without breaking the server or flipping it "the other way". That is the fundamental difference from a shell script, which on a repeat often duplicates entries or fails on resources that already exist.

Handlers - restart only after a real change

The handlers section holds actions triggered only when a task reports a change through notify. The classic example is restarting Nginx after swapping a config file: if the config did not change, the handler does not fire and the service keeps running. The tool keeps this consistent: the Restart Nginx handler and the notify pointing at it appear only together and only with the Nginx task. Unticking the handlers option removes both entries at once, so the file never keeps a notify pointing at a missing handler - and that exact scenario ends with the error The requested handler was not found.

How to run the playbook

Save the result as playbook.yml.
Prepare an inventory file with hosts, e.g. a [webservers] group matching the "host group" field.
Do a dry run: ansible-playbook -i inventory.ini playbook.yml --check --diff shows the planned changes without applying them.
Run it for real: ansible-playbook -i inventory.ini playbook.yml.
Check the YAML syntax - indentation in Ansible is significant - in the YAML validator.

The "Users" task reads the public key from ~/.ssh/id_rsa.pub on the control machine through lookup('file', ...). Make sure that file exists and holds the right key before you run the playbook - otherwise the deploy account is created with no SSH access.

become, gather_facts and the host group

The become option raises privileges to root (the equivalent of sudo) and is needed to install packages or manage services. gather_facts enables collecting information about the remote machine (system, versions, interfaces) that you can use in templates and conditions; for simple playbooks you can turn it off for a faster start. The host group ties the playbook to inventory - if you build playbooks for many roles, keep consistent group names (webservers, dockers, databases) and mirror the same names in the inventory file.

Frequently asked questions

What is inventory and where does the "host group" come from?

Inventory is a file listing servers grouped into sections, e.g. [webservers]. The value from the "host group" field goes into the playbook's hosts key and must match a group name in inventory. Inventory can be static (an INI/YAML file) or dynamic (a script returning a host list from the cloud).

Does Ansible need an agent on the server?

No. Ansible connects over SSH and uses the Python present on the remote machine. You install no service on the target - all the logic runs from the control machine.

How do I safely test a playbook before deploying?

Run it with --check (a dry run, no changes) and --diff to see what would change. It is also worth checking the YAML syntax in a validator - a wrong indent can change the meaning of the whole file.

Why did removing handlers also drop the notify entries?

Because a notify without a matching handler aborts execution with a "handler not found" error. The tool treats a handler and the notify pointing at it as a pair: they appear and disappear together, and only with the Nginx task that calls the handler.

What does "idempotent" mean for Ansible?

That running the same playbook repeatedly yields the same server state. A module first checks whether a change is needed and acts only if it is. That is why a playbook can be run over and over with no risk of duplicating configuration.