This content originally appeared on DEV Community and was authored by Doug Bell
I hate runbooks. I've been an SRE from since we were called webmasters. In all this time, the least helpful part of my job has been the lists of commands to run when there's a problem. Often out-of-date, frequently lacking in context, and altogether useless when production is burning around you and clients and banging on the door. I'm a programmer. I don't perform tedious tasks, I automate them. Why, then, should I like documenting tedious tasks?
I hate Jenkins. No, that's not quite true. I'm disappointed in Jenkins. Parameterized builds could be such a useful tool, but the input forms they provide the end-user is ugly at best, incomprehensible at worst. Jenkins's pipeline syntax opens the door to some truly amazing abilities, but there's no way for me to package those abilities in a way I can simply give to someone without training them on how to navigate Jenkins's UI.
To solve these problems, I wrote Zapp. In Zapp, I can create a plan as a series of tasks, like a Jenkins build. Plans can have input fields, like a Jenkins parameterized build. Users can then run the plan and see the output.
Zapp tasks can be more than a shell command or script. Zapp tasks have their own configuration, so I can provide a friendly form for the user to control what the task will do. Additionally, tasks output typed data that can be used as input to subsequent tasks. When the task executes, it can render its own output to show the end-user what is happening.
So, I can create a plan that asks a user to input their credentials.
Then, the plan can fetch an authentication token from using those credentials.
Finally, with this authentication token, I can perform my request.
Then when I want to run the plan, I can input my credentials and hit a button.
As the job runs, it updates the job page. If any errors occur, the job stops and the failing task shows an error message. I can choose to re-play the job, or I can go back and fix whatever problem there is.
Zapp isn't limited to automating runbooks. Zapp provides webhook triggers to perform plans automatically. Build your software after a commit is pushed to Github, respond to Slack commands, or (when a future version adds scheduled tasks) run a nightly SQL report. Not only are these tasks automated, but they are easy to configure so that users can support themselves.
Finally, if Zapp can't do what you want, you can write your own task classes to perform tasks, type classes to accept input from users, and trigger classes to run plans automatically in response to events. Zapp is written in modern Perl using the Mojolicious web framework and the Minion task runner.
With Zapp, I can make tedious support processes into a single web form, or even a single click. As needs change, processes can be tweaked using a friendly UI. And new types of tasks can be created to provide ever more options for your users.
Zapp is very much Alpha-grade software right now: I use it personally, but there are bugs and missing features yet. The plugin APIs are pretty solid, though, so you can write your own tasks, types, and triggers. There are a lot of features that Minion provides that Zapp does not yet take advantage of, so there's plenty of possibilities for future development. If you have any questions, suggestions, issues, or want to know if Zapp can work for you, feel free to let me know at doug@preaction.me or on irc.libera.chat in #mojo-yancy.
This content originally appeared on DEV Community and was authored by Doug Bell
Doug Bell | Sciencx (2021-07-29T00:08:12+00:00) Zapp: Runbook Automation. Retrieved from https://www.scien.cx/2021/07/29/zapp-runbook-automation/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.