Ansible with a Dynamic NetBox Inventory and ServiceNow Record

Keep configuration management driven by your source of truth instead of hand-maintained host files. This blueprint queries NetBox for the devices that match a site and role, generates an Ansible inventory from that live result, runs a playbook against those hosts, then stamps the ServiceNow CMDB so the configuration item reflects when it was last configured. NetBox decides what exists, Ansible enforces the desired state, and ServiceNow records what happened, closing the loop between inventory, automation, and the CMDB.

How it works

1. list_devices (io.kestra.plugin.ee.netbox.device.List) pulls active devices from NetBox filtered by site and role, returning the name field with fetchType: FETCH.
2. run_playbook (io.kestra.plugin.ansible.cli.AnsibleCLI) on the io.kestra.plugin.core.runner.Process runner writes an inventory.ini from the NetBox rows and a site.yml playbook, then runs ansible-playbook -i inventory.ini site.yml.
3. record_run (io.kestra.plugin.servicenow.Update) updates the cmdb_ci_server table for the given sysId, writing u_last_config_run and a work_notes summary of how many hosts were configured.
4. A disabled daily_config Schedule trigger (io.kestra.plugin.core.trigger.Schedule, cron 0 5 * * *) is ready to rebuild and reconfigure on a cadence once enabled.

What you get

• An always-current inventory generated from NetBox rather than a static file.
• A repeatable playbook run scoped to exactly the hosts NetBox reports.
• A CMDB that records the last configuration run and host count automatically.
• A schedulable, auditable pipeline you can extend without rewriting tooling.

Who it's for

• Infrastructure and platform engineers running Ansible at scale.
• Network and DevOps teams using NetBox as the system of record.
• IT operations teams that must keep ServiceNow CMDB data trustworthy.

Why orchestrate this with Kestra

Ansible has no native scheduler, retry policy, or lineage across systems. Kestra wires NetBox, Ansible, and ServiceNow into one declarative YAML flow, passing the device list between tasks, adding event or schedule triggers, retries, and full execution history. The same run that configures hosts also updates the CMDB, something the Ansible CLI alone cannot coordinate.

Prerequisites

• Ansible installed on the worker that runs the Process runner.
• A reachable NetBox instance with devices tagged by site and role.
• A ServiceNow configuration item (sys_id) to stamp.

Secrets

• NETBOX_URL: NetBox base URL.
• NETBOX_API_TOKEN: NetBox API token.
• SN_DOMAIN: ServiceNow instance domain.
• SN_USERNAME: ServiceNow username.
• SN_PASSWORD: ServiceNow password.

Quick start

1. Add the secrets above to your Kestra namespace.
2. Set the site and role inputs and supply the cmdb_sys_id of the CI to update.
3. Replace the sample site.yml ping task with your real configuration tasks.
4. Run the flow, then enable the daily_config trigger for scheduled runs.

How to extend

• Point ansible_host at a DNS name or IP from NetBox instead of the device name.
• Add more NetBox filters or fields to scope or enrich the inventory.
• Expand data in record_run to write additional CMDB attributes.
• Add a Slack or email notification on success or failure.

Links

• https://kestra.io/plugins/plugin-ee-netbox
• https://kestra.io/plugins/plugin-ansible
• https://kestra.io/plugins/plugin-servicenow
• https://kestra.io/orchestration/netbox
• https://kestra.io/orchestration/ansible
• https://kestra.io/orchestration/servicenow