Préparation de l'environnement d'exécution

Pré-requis

Suivre le pré-requis global.

Valeur finie des variables dans l’environnement d’exécution

Le nœud administré va utiliser l’environnement préparé par le nœud de contrôle. Les valeurs doivent être déterminées avec exactitude. Il n’y a pas de sens d’envoyer une variable faisant référence à une autre sur un nœud administré, vous indiquerez le nom de cette référénce directement dans le script : Exécuter MYVAR="$HOME" echo "$MYVAR" ne fait que complexifier le processus, écrivez directement echo "$HOME".

Cette présentation se déroule en étape, le but de l’opération est d’afficher le contenu d’un fichier situé sur un nœud administré.

L’opération “prepareenvironment” est constituée d’un manifeste et d’un seul script.

Utilisation du commutateur “-e”

Le script de l’opération est :

#!/usr/bin/env bash

echo "File to read: ${MYFILE}"
cat "${MYFILE}"

Le nœud administré ne connaît pas la valeur de ”${MYFILE}”, cette valeur sera définie dans l’environnement fourni par le nœud de contrôle et défini dans le manifeste :

[...]
parameters:
  required:
    MYFILE:
      type: string
      comment: "file name"

À partir d’un nœud de contrôle, j’exécute la commande :

automation-cli run -op "prepareenvironment" -h "localhost" -e MYFILE="/etc/cron.d/e2scrub_all"

Le nœud de contrôle, après préparation, envoi l’ordre d’exécution au nœud administré sous cette forme :

MYFILE="/etc/cron.d/e2scrub_all" bash [script name]

Le fichier lu sera “/etc/cron.d/e2scrub_all”.

Vous avez constater que démarrer une opération passe toujours par la présentation de ce qui va être exécuté et la liste des hôtes impactés. Si vous souhaitez passer outre cette confirmation, ajouter le commutateur “-y” dans votre commande.

ATTENTION : Exécuter une opération sur un serveur peut entraîner de graves dysfonctionnements.

Valeur par défaut - manifeste “operation”

Les manifestes peuvent stipuler des valeurs par défaut pour les deux types de paramètre : “required” et “optional”.

En reprenant l’étape précédente, effectuer une copie de l’opération en la nommant “prepareenvironmentdefault”, dans le manifeste, ajouter l’attribut “default” avec une valeur fixe :

[...]
parameters:
  required:
    MYFILE:
      type: string
      comment: "file name"
      default: "/etc/cron.d/e2scrub_all"

À partir d’un nœud de contrôle, sans spécifier le commutateur ‘-e’, j’exécute la commande :

automation-cli run -op "prepareenvironmentdefault" -h "localhost"

Le fichier lu sera “/etc/cron.d/e2scrub_all”.

Surcharge de la valeur par défaut par le commutateur ‘-e’

Le commutateur “-e” est prioritaire aux valeurs par défaut, définies dans les manifestes d’opération. Par conséquent, sa valeur surcharge la valeur par défaut.

En reprenant l’étape précédente, le manifeste contient une valeur par default pour la variable “MYFILE” :

[...]
parameters:
  required:
    MYFILE:
      type: string
      comment: "file name"
      default: "/etc/cron.d/e2scrub_all"

automation-cli run -op "prepareenvironmentdefault" -h "localhost" -e MYFILE="/etc/debian_version"

Le fichier lu sera “/etc/debian_version” et non pas la valeur fixée par défaut dans l’opération.

Surcharge de la valeur par défaut par operationBook

Quand vous avez plusieurs étapes dans une opération à réaliser, vous utilisez “operationBook”, l’environnement de “operationBook” pour une opération est prioritaire aux valeurs par défaut, définies dans les manifestes d’opération.

En reprenant l’étape précédente, ajout du manifeste “operationBook” :

operations:
  - operation: "prepareenvironmentdefault"
    environment:
      MYFILE: "/etc/debian_version"

automation-cli run -ob "prepareenvironmentdefault" -h "localhost"

Le fichier lu sera “/etc/debian_version” et non pas la valeur fixée par défaut dans l’opération.

Surcharge de la valeur définie dans operationBook par le commutateur ‘-e’

En reprenant l’étape précédente, nous disposons pour la variable “MYFILE” de deux valeurs explicites dans :

Le manifeste “operation” (default) : “/etc/cron.d/e2scrub_all”
Le manifeste “operationBook” : “/etc/debian_version”

À partir de cette information, exécutez la commande :

automation-cli run -ob "prepareenvironmentdefault" -h "localhost" -e MYFILE="/etc/hosts"

Le fichier lu sera “/etc/hosts” le commutateur “-e” est prioritaire dans toutes les exécutions d’opérations.

Utilisation des valeurs de l’inventaire

L’environnement d’exécution peut aussi être préparé au moyen de valeurs lues dans un fichier d’inventaire.

Dans ce cas, les variables utilisées dans les opérations doivent commencer par ‘#inv.’, suivi du chemin vers la valeur souhaité. Le chemin se construit en parcourant les attributs d’un inventaire. Un inventaire est représenté par un objet construit à partir d’une structure “YAML”.

À partir d’un fichier d’inventaire créé avec la commande : automation-cli cinv "$OPS/inventory.yaml, ajoutez l’attribut “myfile” avec la valeur “/etc/hosts” :

sshpk: ""
sshpass: ""
serverGroups:
  all:
    - localhost
  controlnode:
    - localhost
  localhost: 127.0.0.1
myfile: /etc/group

Exécuter la commande :

automation-cli run -op "prepareenvironmentdefault" -i "$OPS/inventory.yaml" -h "localhost" -e MYFILE="#inv.myfile"

Le fichier lu sera “/etc/group”.

Notez : La variable “MYFILE” dans le manifeste “operation” est requise, par conséquent sa valeur finale ne peut être vide. Si le fichier d’inventaire ne propose pas l’attribut “myfile”, l’opération échouera.

Utilisation plus complexe : Mixons l’environnement du noeud de contrôle et les valeurs de l’inventaire

“automation-cli” peut lire récupérer des valeurs d’inventaire, fonction de la valeur d’une variable de son environnement (noeud de contrôle).

À partir d’un fichier d’inventaire créé avec la commande : automation-cli cinv "$OPS/inventoryEnv.yaml, ajoutez les attributs comme suit :

sshpk: ""
sshpass: ""
serverGroups:
  all:
    - localhost
  controlnode:
    - localhost
  localhost: 127.0.0.1
myfile:
  group: /etc/group
  hosts: /etc/hosts

FILETOREAD="group" automation-cli run -op "prepareenvironmentdefault" -i "$OPS/inventoryEnv.yaml" -h "localhost" -e MYFILE="#inv.myfile.\$FILETOREAD"

Le fichier lu sera “/etc/group”.

FILETOREAD="hosts" automation-cli run -op "prepareenvironmentdefault" -i "$OPS/inventoryEnv.yaml" -h "localhost" -e MYFILE="#inv.myfile.\$FILETOREAD"

Le fichier lu sera “/etc/host”.

Comment çà marche ?

La variable “FILETOREAD” est injectée dans l’environnement du nœud de contrôle, avant exécution de “automation-cli”, par conséquent le processus dispose de cette valeur. Lors de la préparation, le processus essaie de convertir tout ce qui ressemble à une variable d’environnement avant de déterminer sa valeur finale.

“#inv.myfile.$FILETOREAD” est transformé en “#inv.myfile.[valeur de $FILETOREAD] (#inv.myfile.group ou #inv.myfile.hosts selon la valeur de FILETOREAD), et tente de lire ce chemin dans le fichier d’inventaire.

**Explication concernant le ”\” devant “$FILETOREAD” :

Le caractère ”$” est protégé par ”\” pour que bash n’opère pas de susbstitution au moment de son exécution.

“Bash” est un processus à part entière, et chargé d’exécuter la commande qui suit son prompt. FILETOREAD=“hosts” ne sera diponible que dans le processus “automation-cli” démarré par “bash”. “bash” ne connaît pas la valeur de FILETOREAD, il la substitue par "", au final “automation-cli” disposera de la variable d’environnement : ‘-e FILETOREAD=“#inv.myfile.”’ (FILETOREAD ayant été substitué par bash avec la valeur ""). Pour que bash connaisse cette valeur avant exécution de la commande il faudrait d’abord exécuter : export FILETOREAD="hosts".

Pour ne pas manipuler la protection de variable bash, vous pouvez encadrer la valeur de la variable du commutateur “-e” avec des apostrophes au lieu d’utiliser des guillemets (-e MYFILE=‘#inv.myfile.$FILETOREAD’)

Autre possibilité pour enrichir l’environnement du noeud de contrôle

Au lieu d’injecter la variable FILETOREAD dans l’environnement d’exécution “automation-cli”, indiquez la variable dans l’environnement de l’opération. Bien que cette variable puisse être utilisé par le noeud de contrôle, et n’étant pas spécifié dans le manifeste de l’opération “prepareenvironmentdefault”, elle ne fera pas partie de l’environnement d’exécution sur le noeud administré.

Basé sur l’étape précédente, exécutez :

automation-cli run -op "prepareenvironmentdefault" -i "$OPS/inventoryEnv.yaml" -h "localhost" -e MYFILE="#inv.myfile.\$FILETOREAD" -e FILETOREAD="group"

Le fichier lu sera “/etc/group”.

Ordre de priorité des surcharges

Valeur du commutateur ‘-e’ (plus haut niveau).
Valeur de l’environnement dans un manifeste “operationBook”.
Valeur par défaut dans un manifeste “operation”.

Il est important de bien mémoriser cet ordre.

ATTENTION : La méthode “register”, selon le nom des variables utilisées, peut surcharger l’environnement préparé et entraîner de gros effets de bord.

Surcharges d’une variable

Exemple, une opération démarrée par “operationBook”, doit communiquer la variable KEY au shell qui sera exécuté sur le noeud administré.

Fourni par l’utilisateur ‘-e’ :

Fourni par operationBook, appelant operation :

Fourni pas operationBook, appelant operationBook, puis operation :

Fourni pas operation (attribut “default”) :

Effets de bord avec register

Il s’agit d’une mauvaise pratique, vous insérez une opération incluant le mode “register”, que vous avez nommé ‘KEY’. Pour éviter ce cas, je vous conseille de préfixer ce type variable par ‘REG’. Ce type de programmation peut entraîner des erreurs graves.

Réutilisation d’une variable existante avec “register” :

La valeur de MYFILE a changé.

Avec la variable utilisée pour le mode register préfixée par ‘REG’

La valeur de MYFILE n’a pas été modifiée.

Il est envisagé d’inclure un contrôle plus stricte sur le nom de ce type de variable.