Executing an operation in detail

This chapter explains how the control node prepares and executes operations on managed nodes.

Overview

The command to execute an operation is “run”. The tool has other commands, see “Tooling” section.

Execution channels (shell/SSH/Wireguard)

“automation-cli” can use two channels to execute operations on a server, either directly in a console (localhost) or via SSH, which can be encapsulated in a WireGuard VPN.

The choice is automatic and determined by the target host:

• If the host is “localhost ‘ or ’127.0.0.1”, operations are performed in a local console, with your user account. You can add the prefix “sudo”, which will allow operations reserved for the “root” account to be performed on the control node.
• In the other case, there will be an SSH connection, which can be encapsulated in a Wireguard VPN tunnel. All operations performed through an SSH connection are executed with the root account, although sudo is supported.

ssh key

The ssh key and its password can be supplied via the switches: sshpk and sshpass, or via an inventory file. When this information is not specified, try to use your private SSH key, located in your “home directory” (`ls ~/.ssh).

Managed node

This node receives a bash script and execution environment from the control node. Once on the managed node, the prepared environment will be added to the system environment (root account environment), then finally used in the bash script execution process.

Control node

The roles of this node are :

• Read the description of an operation to prepare :
  • The execution environment.
  • The bash script.

• Send to managed node :
  • Execution environment.
  • The bash script.
  • Resources associated with an operation: templates, binaries, etc.
  • Execution order.

• Retrieve, when the administered node performs an operation :
  • standard and error output (stdOut/stdErr)
  • Exit code.

• Building the post-execution report

Preparing the runtime environment

The aim of this preparation is to provide managed nodes with a runtime environment with finite values.

To build these, you can use the control node’s system environment and/or an inventory file.

The control node does not send its system environment to the managed nodes. Only required, optional variables (specified in manifests) and any “register ” are sent to managed nodes.

If you stipulate the ‘-e’ switch (‘-e[VAR]=“value”’) with a variable name not specified in the manifest, this variable will not be injected into the runtime environment, you are working in a controlled environment.

On the other hand, you can use this non-referenced variable to prepare the runtime environment for the administered node. Please refer to the examples in the Self-training chapter.

The final execution environment for the administered node will be :

• Required variables (parameters.required) with a mandatory value.
• Optional variables (parameters.optional) with or without a value. The important thing for this type of variable is that it be declared for bash (use “set -u” for execution). Optional means: “a variable declared with or without a value”.

Preparing the bash script

How to build a bash script :

• Removing the “Shebang”.
• Recovery of the internal template.
• Concatenation of operation shells.

The shell is self-destructing at runtime; you can see the entire shell executed in execution logs.

Pre-run report

Executing an operation on a server can lead to serious malfunctions. A pre-execution report is systematically presented so that you can confirm execution on the desired hosts.

You can override this display by using the “-y” switch

Post-execution report

Post-execution reports always show the association ‘host requested by user’ and ‘host used for SSH connection’.

If you do not wish to display this report, for example when running a scheduled task (cron), use the “-s” switch (silent mode).