Everyone loves open source :)

Why? `cause it’s free. It’s helpful. It’s flexible. And sometimes it’s the only thing that works, simply because the community that developed open source solutions has already run up against a problem that you have just encountered and many great minds have come together using the power of open source to create a great tailored solution.

In this blog post, I’m going to discuss one specific open source tool which not a lot of techies know about, called “Script-Server” by Bugy.

What Is It?

Script-Server is a smart Web-UI (can also be run via command line) in which you can expose scripts/Ansible Playbooks in a user-friendly set-up. No script modifications are needed from your end — You add configuration for each script to the Script-Server and it takes care of proper UI, validation, execution, etc. Meaning- EVERYONE can use it and run the scripts (See Demo), without needing any technical knowledge, nor any permissions since the script run with permissions set on the backend, not related to the end user permissions.

Who Is This For?

If you have scripts, Ansible playbooks, etc., and you wish to have them accessible for non-techies in your company, thus reducing their dependency on your IT/System/DevOps team — THIS TOOL IS FOR YOU.

How Did I Start Using It?

A co-worker from the non-technical team (let’s call her Betty) has a monthly task (not on a fixed date) to download zip files from an external location, unzip them on a specific server, analyze statistics and hashes on the files and send a report back to Betty.

As a DevOps Engineer, one of my mantras is automate the easy stuff. I identified Betty’s recurring task as a great candidate for automation and created an Ansible playbook to perform this flow.

But every month Betty opened a Jira ticket, asking my team to run it because she didn’t have the access permissions to run the Ansible playbook on her end.

Around that time, a team member shared he had worked with “Script-Server”, a tool to expose services for non-technical personnel; I quickly realized that this tool might be a great way to empower Betty to get her report independently and reduce the unnecessary dependency on my team.

As part of the solution, I provided Betty with a link to the Script-Server (hosted on a server on my end), and granted her login access which gave her the independence she needed to run this process (and minimized the amount of Jira tickets she opened, while at it 😉).

Here is a screenshot of what Betty saw after login and entering the specific script she needed (Output below is after clicking on “Execute”) -

So…What Makes This Tool so Great?

Undoubtedly, the main value of the Script-Server is that it wraps a script/playbook in a tailored way, that allows exposure of variables/arguments drop-downs, checkboxes, text, etc. (Extra vars in Ansible, arguments in regular scripts). User experience-wise, it means that on the fly, the script arguments/variables are requested in the UI (Thus eliminating the need to go over the script itself to see which arguments it expects to get).

For example, the screenshot above shows a variable called “batch_date” (2019–04). The “batch_date” is actually an extra var that was defined in the Ansible playbook “playbook.yml” and linked to Script-Server by a map definition of the variable name in Ansible to the variable name in the UI with a configuration script.

To illustrate an example of how this works, see this script below:


{
“name”: “Very parameterized”,
“script\_path”: “scripts/parameterized.sh”,
“working\_directory”: “./samples”,
“description”: “This script does nothing except accepting a lot of parameters and printing them”,
“allowed\_users”: [
“\*”
],
“include”: “${Simple Text}.json”,
“parameters”: [
{
“name”: “Simple Int”,
“param”: “ — simple\_int”,
“type”: “int”
},
{
“name”: “Simple Boolean”,
“param”: “ — simple\_bool”,
“no\_value”: true,
“description”: “Boolean One”
},
{
“name”: “Multiple selection”,
“param”: “ — multiselect”,
“type”: “multiselect”,
“description”: “Multiselect list”,
“values”: [
“Black cat”,
“Brown dog”,
“Green parrot”,
“Red fox”
]
}
]
}


In this example we have a configuration script which is calling the execution script “scripts/parameterized.sh”, the configuration script is defining the arguments and variables for the execution script.

By nature the way Script-Server works is that if your execution script requires arguments you have to run it with a configuration script — if it is just executing a command without any parameters you can run it straight from Script-Server (in the demo site the “colortest” is an example for this).

A full file can be found here.

Which Scripts Are Supported by the Script-Server?

The Script-Server is language agnostic — It can run scripts in any language from Perl, to PHP to Python; Ansible playbooks can be ran as well (need to wrap it a bit but it’s a small price to pay for the benefits). It supports multiple types of inputs or “arguments” (lists/free text/hardcoded), which you define in the configuration script, to allow flexibility of the scripts’ usage (Whatever arguments are needed via a command line — They can be provided via the Script-Server UI).

User Management

Script-Server also supports authentication (Gmail SAML) and authorization, by defining which users/groups can access each “Domain” (Domain is the area in which you run the script- It can be a single script or entire folder of ansible-playbooks if you’d like). Example from the Demo - Define user X to have the ability to run “Calculator” but not “Tic-Tac-Toe”.

In-Session Execution

Running the Script-Server session in a browser is bulletproof- It’s based on the end user’s session, so even if the end-user closed the browser and re-open it- He/She will see that the session remains intact and the run hasn’t been aborted.

The Power of Script-Server as Open Source

Even if you haven’t figured out how this tool can be used in your company, or you encountered some limitations when implementing it on your end, the creator of the tool is very responsive, so you can open a GitHub issue and you’ll get a fast and efficient response ( I can attest from personal experience that several times when I missed a specific functionality, I opened an issue on the GitHub Script-Server repository and Bugy was responsive to my questions and even acted on my suggestions adding features/functionality I requested). You can also contribute to this project and make this tool even more powerful and relatable for more use-cases.

To Sum Up

The Open Source community is growing. Even Big Blue recognized the power of open source in its recent acquisition of Red Hat. The growth only makes open source projects better and more secure — as more people are testing and fixing code. The growth of the open source community positively affects our professional careers on a technical level — by offering a variety of solutions to implement and on a personal level by providing a way to give back to the community.

Script-Server is a very powerful and flexible tool to allow running scripts and playbooks from a central location, in an “easy on the eye” kind of look and without the need for permissions or pre-knowledge of how the scripts work, and I highly recommend to check it out.