Executor Operator
The Executor Operator can be used to execute a shell command on a target machine using SSH.
Operator arguments
Name | Type | Values restrictions | Required | Default | Description |
---|---|---|---|---|---|
| String | yes | The shell command to be executed on the remote machine | ||
| Object | See structure documented below | no | Information relative to the target machine onto which the command has to be executed using SSH | |
| String | It should match the name of an existing Component of the System under test | no | The name of the Component whose properties can be used as arguments of the operator | |
| Boolean | no |
| The execution mode of the shell command.
Default ( |
Host
structure and arguments
Host
structure and argumentsHere follows the structure of the host
argument:
with its arguments:
Name | Type | Value Retrictions | Required | Default | Description |
---|---|---|---|---|---|
| String | should be a valid SSH host address | no, if the Component whose name is defined in | SSH endpoint | |
| String | no, if the Component whose name is defined in | SSH login username | ||
| String | cannot be set if | no, if the Component whose name is defined in | SSH login password | |
| Number | 1≤ | no | 22 | SSH port |
| String | cannot be set if | no, if the Component whose name is defined in | SSH login key. Either provide directly the key value or specify the path of the file (local to the cli executing the create command) to read the key from. The operator supports RSA and DSA Keys. |
Get operator arguments from component
component
The component
argument can refer to a component by name and use its properties as the arguments of the operator (see mapping here below). In case the mapped arguments are already provided to the operator, there is no override.
Component property to operator argument mapping
Component Property | Operator Argument |
---|---|
|
|
|
|
|
|
|
|
|
|
Examples
Let's assume you want to run a script on a remote host and expect the script to be executed successfully within 30 seconds but might fail occasionally.
Launch a script, wait for its completion, and in case of failures or timeout retry 3 times by waiting 10 seconds between retries:
Execute a uname command with explicit host information (explicit SSH key)
Execute a uname command with explicit host information (imported SSH key)
Execute a uname command with host information taken from a Component
Start a load-testing script and keep it running in the background during the workflow
Troubleshooting
Troubles in running sh scripts remotely
Due to the stderr configuration, it could happen that invoking a bash script on a server has a different result than running the same script from Akamas Executor Operator. This is quite common with Tomcat startup scripts like $HOME/tomcat/apache-tomcat_1299/bin/startup.sh
.
To avoid this issue simply create a wrapper bash file on the target server adding the set -m instruction before the sh command, eg:
and then configure the Executor Operator to run the wrapper script like:
You can run the following to emulate the same behavior of Akamas running scripts over SSH:
Troubles in keeping a script running in the background
There are cases in which you would like to keep a script running for the whole duration of the test. Some examples could be:
A script applying load to your system for the duration of the workflow
The manual start of an application to be tested
The setup of a listener that gathers logs, metrics, or data
In all the instances where you need to keep a task running beyond the task that started it, you must use the detach: true
property.
Note that a detached executor task returns immediately, so you should run only the background task in detached mode.
Remember to keep all tasks requiring synchronous (standard) behavior out of the detached task.
Example:
Library references
The library used to execute scripts remotely is Fabric, a high-level Python library designed to execute shell commands remotely over SSH, yielding useful Python objects in return.
The Fabric library uses a connection object to execute scripts remotely (see connection — Fabric documentation). The option of a dedicated detach
mode comes from implementing the more robust disown
property from the Invoke Runner underlying the Connection (see runners — Invoke documentation). This is the reason you should rely on detach
whenever possible instead of running the background processes straight into the script.
In the Frequently Asked/Answered Questions (FAQ) — Fabric documentation you may find some further information about the typical problems and solutions due to hanging problems for background processes.
Last updated