DYNAMIC COMMAND EXECUTOR
Traditional Way of Executing Commands:
Commands… We all have had our share of them, some love them, some hate them, but we just can’t live without them. The sheer elegance when it works, and the utter despair when it breaks are well known traits of CLI-based executions. But when you are working with multiple devices, you can’t afford the trial and error. How can you perform CLI at scale? At AppViewX, we think we found a solution using our own AppViewX AUTOMATION+ Platform.
Multi Command Execution via AppViewX:
To execute multiple commands, you simply launch Automation workflow, which is presented as a form. Here, you can choose your target devices, like 500 F5s, or 250 Palo Altos, or 500 switches, and paste the commands from any source, such as notes, spreadsheets, text files, etc. Then click submit and watch the magic unfold.
For example, you have an F5 device, and you want to configure a new DNS Server on all 500 of your F5s. Simply paste the list of commands and select all 500 from the AppViewX inventory.
The commands are executed on multiple devices in parallel. AppViewX fetches the device credentials from the AppViewX inventory, logs into each device, and identifies whether the device is currently in tmsh mode or bash mode. If the device is in bash mode, it changes the mode to tmsh and then executes the commands. Once the commands are executed, the response from the devices is captured by the workflow and displayed in a summary table, along with the device status list (success/failure). A summary mail is sent to the user to keep track of the command execution status on different devices.
But what about due diligence? When implementing a change on 500 devices, many things can go wrong. But AppViewX has you covered. Take a look at how our intelligent automation engine handles errors:
List of errors:
- Device connectivity issues
- Timeout issues
- Invalid syntax of commands
- File not found or missing issues
What’s Happening Under the Hood:
Python Packages Used:
- Paramiko: The Python paramiko model gives an abstraction of the SSHv2 protocol with both the client side and server side functionality. As a client, you can authenticate yourself using a password or key and as a server you can decide which users are allowed access and the channels you allow.
- Multiprocessing: that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads.