Skip to content

Run an Ansible Playbook (Automation)

The ⚙ Automation tab (admin-only) is a built-in Ansible playbook editor, runner, and live-log tailer — for one-off or recurring fleet operations that don't fit MFCloud's own API (e.g. a custom hardening pass, an ad-hoc package rollout).

Privileged feature

Running arbitrary Ansible against your infrastructure is equivalent to root/API access — the whole tab is gated on global_admin.

Quick steps

  1. ⚙ Automation → + New Playbook (or ⬆ Upload .yml an existing one).
  2. Name it and write/paste the YAML in the editor. 💾 Save.
  3. Pick an Executor:
  4. local — runs ansible-playbook directly from the master container.
  5. awx — hands the run to an external AWX/Ansible Automation Platform instance instead; requires an AWX Job Template name/ID (the editor's own YAML content is not sent to AWX — only extra_vars) and a working AWX connection under ⚙ Config.
  6. Set verbosity (-v through -vvvvv) and log format — live tail streams output as it runs, JSON only flushes at the end (no live tail, but structured).
  7. ▶ Run. Output streams into the Run Output panel; ⏹ Stop revokes a queued run or SIGTERMs an in-flight one.
  8. Recent runs dropdown recalls past output for the same playbook.

Run a playbook on a VM event (Triggers)

The Triggers card runs one of your playbooks automatically when something happens to a VM.

  1. + Add Trigger.
  2. When: pick the event: VM created, VM deleted, VM powered on, VM shut down or powered off, VM moved to another host or storage, or A VM backup finished.
  3. for: any VM, this VM (type its name), or VMs with the tag (type the tag).
  4. run: pick the playbook and its executor. Add.

The run gets these extra vars:

Variable Value
mfcloud_event The event, for example vm.created.
mfcloud_vm_name The VM's name.
mfcloud_vm_host The host it's on.
mfcloud_vm_ip Its IP address, if the console knows it.
mfcloud_vm_tags Its tags. Braces are removed, so a tag can't inject Jinja into the playbook.

Triggered runs show in run history and Recent Tasks, and ⏹ Stop works on them like any other run.

A trigger fires at most 10 times in 10 minutes. That stops a playbook that itself creates or powers on VMs from setting off an endless chain. Runs skipped by that limit are counted on the trigger's row. Every change to a trigger is written to the audit log.

Configuring AWX (optional)

⚙ Config stores the AWX base URL and API token, plus a Test Connection check — needed only if you plan to use the awx executor instead of running locally.

See also

  • The Automation tab's runs also show up in the global Recent Tasks drawer (as Playbook: <name>), same as any other MFCloud task.