Run Ansible Against NetBox Devices by Role and Site

Drive network and infrastructure configuration management directly from your NetBox source of truth. This blueprint queries NetBox for active devices matching a given device role and site, loops over the result set, applies an Ansible playbook to each device in parallel, and reports the outcome to Slack. Because NetBox decides which hosts are in scope, your automation stays in sync with the inventory teams already trust, eliminating hand-maintained host lists and drift between documentation and reality.

How it works

1. The list_devices task (io.kestra.plugin.ee.netbox.device.List) calls the NetBox API with filters for site, role, and status: active, returning the name and status fields with fetchType: FETCH.
2. The configure_devices task (io.kestra.plugin.core.flow.ForEach) iterates over outputs.list_devices.rows with a concurrencyLimit of 5.
3. For each device, the nested ansible_apply task (io.kestra.plugin.ansible.cli.AnsibleCLI) on the io.kestra.plugin.core.runner.Process runner writes an inventory.ini and site.yml from inputFiles, then runs ansible-playbook -i inventory.ini site.yml.
4. The notify task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts how many devices were configured to a Slack webhook.
5. An optional daily Schedule trigger (daily_enforcement, cron 0 6 * * *, disabled by default) re-enforces the baseline.

What you get

• Inventory-driven runs: NetBox, not a static file, defines the target hosts.
• Bounded parallelism across the fleet via concurrencyLimit.
• A Slack summary on every run.
• A working scaffold you can point at real playbooks.

Who it's for

• Network and infrastructure engineers managing device fleets.
• Platform and DevOps teams standardizing config enforcement.
• SRE teams that treat NetBox as their source of truth.

Why orchestrate this with Kestra

Ansible and NetBox have no shared scheduler that reacts to inventory changes, retries failed hosts, and records lineage in one place. Kestra adds event and schedule triggers, automatic retries, full execution history per device, and declarative YAML you can version control. The ForEach fan-out with a concurrency cap is something a single ansible-playbook invocation cannot express cleanly, and you gain observability over which devices passed or failed.

Prerequisites

Ansible installed on the worker (the AnsibleCLI task uses the Process runner) with network and SSH reachability to the target devices.

Secrets

• NETBOX_URL: base URL of your NetBox instance (for example, https://netbox.example.com).
• NETBOX_API_TOKEN: NetBox API token used for authentication.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL for the summary message.

Quick start

1. Add the three secrets above to your Kestra namespace.
2. Execute the flow, setting the site and role inputs to target the devices you want.
3. Replace the sample site.yml playbook with your real configuration baseline.

How to extend

• Swap the ping playbook for full configuration roles (interfaces, NTP, ACLs).
• Resolve taskrun.value.name to DNS names or primary IPs from NetBox instead of the raw device name.
• Enable the Schedule trigger or add a webhook trigger fired by NetBox change events.
• Branch on per-device Ansible results and alert only on failures.

Links

• Plugin docs: NetBox
• NetBox orchestration with Kestra