Windmill.dev for Network Automation Scripting

Over the last half a year I have been experimenting and learning how to use Windmill. It is designed to be a central place that a team can run and develop scripts. It has the ability to be complex and powerful but I just want somewhere that network automation scripts could live and run.

It works with all kinds of scripts as you can see from the below which comes from the ‘new script’ screen.

It has a web front end that allows the scripts to be viewed and edited. Every run of a script is recorded meaning that automated things can be checked for health. When someone reports the thing stopped working during the last week you can look at the history and find exactly the time and any error messages.

As well as running scripts you can store variables. I use this to store API keys (in the secret mode) which means that any script needing it points to it. One place to update, fewer typos etc. It is similar to using an environmental variable on a command line but here the variable can have security permissions and validation.

Scripts can be scheduled. Like a cron job (probably is back end) but with added benefits of an easy GUI to set it up, advanced permissions/abilities like what to do upon failure, a little bar chart showing past runs….

Code versioning is implicit within the GUI allowing the normal of diff’s between versions. A deployment of a script is like a git commit.

I suspect a lot of people stop there and I probably will too. A professional way to store and ensure a team’s scripts are running well and empowering collaboration by making it easy to steal each other’s code. Windmill has two more tricks up it’s sleeves:

Firstly there are Flows. Here you can string inputs, scripts, triggers, approvals. Kind of like a flow chart. This means you can link code chunks together with scripts run or not, based on the output from a previous one. For example, if a script that checks for new devices finds one that could invoke a loop in the flow that onboards the device into netbox. Or you can send a message on Slack asking someone to approve a change. Flows allow you to build an application while still retaining the small building blocks of code and logic.

The final fun part of Windmill is apps. These are web apps that link visual things like buttons and outputs to the scripts you’ve created. You can then publish them to run on the Windmill server. This could be a game changer because it opens up the use of a script to not technical colleagues. You design the app in the WYSIWYG builder. I see this is a critical part of automation because if the entry point to performing some network task programmatically is for a colleague to send an email to the engineer who then manually runs a script, you’ve missed the point. Let the admin team invoke the decommission of a circuit by filling out a little web form or doing something in Salesforce that sends an API.

To be honest I’ve found it a challenge to learn how to progress with apps as it isn’t intuitive. I haven’t found great online resources to get help. I’ll be posting more on here as a result. It is easy to get to the point where a button invokes a script and the result is presented in text or a spreadsheet style table. If the basics are interesting for you please comment and I’ll expedite a post on that.

I’ll be posting more in Windmill soon including why the open-source/community version is more restrictive than at first glance.

Find out more on this platform here: https://www.windmill.dev/

Leave a comment

Create a website or blog at WordPress.com

Up ↑

Design a site like this with WordPress.com
Get started