Outillage

“automation-cli” est équipé de plusieurs commandes pour faciliter le développement des opérations. Pour obtenir plus de détails sur l’utilisation d’une commande, exécutez : OPS="$(pwd)" automation-cli [command name] --help

Fonctions d’édition de manifestes et scripts

Pour les fonctions d’édition de fichiers, l’éditeur utilisé est celui défini par défaut dans votre environnement. Si vous souhaitez spécifier un éditeur en particulier par exemple “nano”, exécutez d’abord la commande : export EDITOR="nano" ou préfixez la commande “automation-cli” avec EDITOR="nano" automation-cli .... Par défaut “automation-cli” utilise “vi”.

|setupops| - Initialisation d’un dépôt d’opérations (OPSDirectory)

Cette commande permet de créer un dépôt qui rassemblera toutes vos opérations. Tous les détails ici

automation-cli setupops "[OPSDirectory name]"

|cop| - Créer une “operation” à partir du modèle

Une opération est stockée dans un répertoire à la racine du répertoire “[OPSDirectory]/operations/”. Le nom de l’opération supporte la notation “espace de noms” (namespace), pour permettre le découpage du cycle de vie d’un processus : Create, Read, Update, Delete (CRUD).

Commande : OPS="$(pwd)" automation-cli cop "[namespace]/[operation Name]" -c "comment for this operation"

Exemple, vous souhaitez gérer le service DNS (namespace “dns”) :

• Création du service.
• Lecture de la configuration.
• Modification de la configuration.
• Suppression du service.

/OPSDirectory
├── Infra server
│  ├──operationBooks
│  │  └──setup.yaml
│  └──operations
│     └── dns
│         ├── create
│         │   ├── ./run.sh
│         │   └── ./manifest.yaml
│         ├── read
│         │   ├── ./run.sh
│         │   └── ./manifest.yaml
│         ├── update
│         │   ├── ./run.sh
│         │   └── ./manifest.yaml
│         ├── delete
│         │   ├── ./run.sh
│         │   └── ./manifest.yaml

Les commandes pour créer ces opérations (notation “namespace”) seront :

OPS="$(pwd)" automation-cli cop "dns/create" -c "Create Dns service"
OPS="$(pwd)" automation-cli cop "dns/read" -c "Read Dns service configuration file"
OPS="$(pwd)" automation-cli cop "dns/update" -c "Update Dns service configuration file"
OPS="$(pwd)" automation-cli cop "dns/delete" -c "Delete Dns service"

|cob| - Créer un “operationBook” à partir du modèle

Un “operationBook” est un fichier au format “YAML”. Cette commmande à pour objectif de créer ce fichier dans le répertoire “operationBooks” de l‘“OPSDirectory”.

Commande : OPS="$(pwd)" automation-cli cob "[operationBook Name]"

Exemple :

OPS="$(pwd)" automation-cli cob "setup" # the .yaml extension is set automatically

/OPSDirectory
├── Infra server
│  ├──operationBooks
│  │  └──setup.yaml
│  └──operations
│     └── [...]

|obaddop| - Ajout une opération dans un OperationBook

La manipulation du format yaml peut s’avérer fastidieuse au quotidien. Cette commande permet d’insérer une opération de type “operation” dans un operationBook en spécifiant le nom de l’opération et le nom de l’operationBook (inutile d’ajouter l’extension yaml).

Le fichier ‘operationBook’ indiqué en paramètre est créé automatiquement s’il n’existe pas déjà.

OPS="$(pwd)" automation-cli obaddop -op "[namespace]/[operation name]" -ob "[operationBook name]"

|edit| - Edition operation/operationBook

“automation-cli” dispose de la commande “edit”, avec les options:

• “-edm” pour l’édition du manifeste
• “-eds” pour l’édition de script. Si l’opération spécifie plusieurs scripts, le programme présentera la liste des scripts :

Concernant le choix de l’éditeur voir ce chapitre

operation : avec “edit”

• Edition du manifeste

OPS="$(pwd)" automation-cli edit -op "operation name" -edm

• Edition du script

OPS="$(pwd)" automation-cli edit -op "operation name" -eds

operationBook : avec “edit”

“operationBook” est un manifeste, il n’est donc pas nécessaire de spécifier le type de fichier à éditer.

• Edition du manifeste :

OPS="$(pwd)" automation-cli edit -ob "operationBook name"

Bien que “-edm” soit plus adapté dans cette situation, par commodité j’ai laissé les deux possibilités -edm ou -eds.

Avec “run”

Pour des raisons pratiques, il est aussi possible d’éditer les fichiers avec la commande “run”.

Exemple, vous construisez l’opération “test” dotée de multiples paramètres, pour éviter de “jongler” entre les commandes “edit” et “run”, restez sur la commande “run”, puis ajouter le paramètre fonction du fichier à éditer :

Exemple avec cette commande d’exécution :

OPS="$(pwd)" automation-cli run -op "test" -e MYVAR1="test1" -e MYVAR2="test2"

L’exécution se passe mal.

Récupérer la commande, et ajouter “-eds” pour éditer le script ou bien “-edm” pour éditer le manifeste :

OPS="$(pwd)" automation-cli run -op "test" -e MYVAR1="test1" -e MYVAR2="test2" -eds

OPS="$(pwd)" automation-cli run -op "test" -e MYVAR1="test1" -e MYVAR2="test2" -edm

Vous pouvez aussi éditer l‘“operationBook” en suivant le même procédé :

OPS="$(pwd)" automation-cli run -ob "operationBooktest" -e MYVAR1="test1" -e MYVAR2="test2" -edm

Bien que “-edm” soit le plus adapté dans cette situation, par commodité j’ai laissé les deux possibilités “-edm” ou “-eds”.

|run| - Exécuter une opération

La commande d’exécution d’une opération est “run”, suivi de “sous-commandes” et/ou d’options d’exécution (commutateurs). Pour connaître les paramètres nécessaires, exécuter : automation-cli ou automation-cli run --help.

Par défault, le répertoire des opérations (OPSDirectory) est “/var/lib/automation-cli”.

Pour spécifier un répertoire différent, utilisez la variable d’environnement “OPS” en affectant la valeur d’un répertoire de manière relative ou absolue (préféré). Vous pouvez vous aider avec les commandes “pwd” ou “realpath” pour définir ce répertoire.

Cette variable doit être déclarée avant l’exécution d‘“automation-cli”. Soit :

• en exportant cette variable de manière globale : export OPS="/home/user/devops"
• ou bien en préfixant la commande “automation-cli” par la variable OPS : OPS="/home/user/devops" automation-cli run ....

La chemin courant de la console est déjà dans l‘“OPSDirectory” :

OPS="$(pwd)" automation-cli run ...` ou `OPS="$(realpath .)" automation-cli run ...

Ce chapitre détaille le déroulement complet d’une exécution.

Commutateur -h

Ce paramètre est obligation

La valeur est le/les noms hôtes ou la/les adressess IP des hôtes. Définisser cette liste en séparant chaque cible par un espace (“server1 server2 server3 192.168.1.1 …”). Une liste doit être encadrée par des guillemets ou apostrophes.

Commutateur -op | -ob | -c

Un de ces commutateurs est obligatoire.

ATTENTION: Le nom de l‘“operation” mentionné dans le paramètre “-op” est relatif au chemin OPS (OPSDirectory).

ATTENTION: Le nom de l‘“operationBook” mentionné dans le paramètre “-ob” est relatif au chemin OPS (OPSDirectory).

Commutateur -y

Ce paramètre est facultatif

Exécuter un automate sur un serveur peut entraîner de graves dysfonctionnements. C’est pourquoi “automation-cli” vous demandera toujours de confirmer l’exécution d’une opération. Cependant, vous savez ce que vous faîtes et souhaitez passer outre cette demande de confirmation, ajouter l’option “-y” : automation-cli run [...] -y

Commutateur -sshpk

Ce paramètre est facultatif

Dans un processus d’authentification par clé, le nœud de contrôle doit disposer d’une clé privée, le/les nœuds administrés doivent disposer de la clé publique correspondante à cette clé privée (user /root/.ssh/authorized_keys). Ceci permet de se connecter aux hôtes distants sans fournir de mot de passe. Pour plus d’information sur les authentifications SSH, veuillez vous référer à la documentation SSH.

Par défaut, automation-cli utilise votre clé privée, située dans votre “home directory” (`ls ~/.ssh)

Dans un contexte distribué, les clés d’accès sont référencées et stockées dans un environnement sécurisé. Fonction des droits de chacun, l’administrateur distribue les clés nécessaires. Ces clés sont disposées sur votre station et doivent être protégées. Pour les utiliser avec automation-cli, ajoutez le paramètre ‘-sshpk’ suivi de l’emplacement exact de cette clé : automation-cli -sshpk "[private key path]".

Si vous spécifier un fichier d’inventaire (“-i”), vous pouvez ajouter le chemin de la clé privée SSH à l’attribut “sshpk”. Dans ce cas n’utilisez plus le paramètre ‘-sshpk’, “automation-cli” tentera toujours de récupérer cette valeur dans l’inventaire spécifié.

Exemple de fichier d’inventaire :

sshpk: /mypath/sysadminKey

Vous pouvez indiquer un chemin relatif, dans ce cas la base de travail sera le chemin définit par la variable d’environnement “OPS” (OPSDirectory). Ceci permet d’embarquer des clé SSH dans dépôt d’opérations.

ATTENTION: Si votre dépôt d’opération comporte des clés SSH et intégré dans un dépôt Git, les clés privées devront être protégées par un mot de passe.

Commutateur -sshpass

Ce paramètre est facultatif

Il se peut que certaines clés privées SSH soient protégées par mot de passe. Pour passer cette valeur à SSH utiliser le paramètre -sshpass “supersecret”. Si vous spécifiez un fichier d’inventaire (“-i”), vous pouver ajouter ce mot de passe à l’attribut “sshpass”. Dans ce cas n’utiliser plus le paramètre ‘-sshpass’, “automation-cli” tentera de récuper ce secret dans l’inventaire spécifié.

Exemple de fichier d’inventaire :

sshpk: /mypath/sysadminKey
sshpass: "mysecret"

Passer des secrets sur la ligne de commande est une mauvaise pratique, car le secret est stocké dans l’historique des commandes exécutées (history). Plus de détails sur les secrets

Commutateur -edm

Ce paramètre est facultatif, fonctionne pour les deux types de manifestes (operation et operationBook).

Permet l’édition du manifeste de l’opération dans la console active,

Concernant le choix de l’éditeur voir ce chapitre

Commutateur -eds

Ce paramètre est facultatif

Permet l’édition du script dans la console active. Si l’opération spécifie plusieurs scripts, indiquer le nom derrière “-eds” (ex: -eds “run1.sh”).

Par défault, l’éditeur ouvre le premier script de l’attribut “scripts”.

Concernant le choix de l’éditeur voir ce chapitre

Commutateur -lh (-json)

Permet de lister les hôtes sur lesquels vont être exécutées les opérations, et sort immédiatement. Vous pouvez ajouter l’option “-json” pour obtenir un résultat sous forme d’objet JSON.

Exemple :

automation-cli run -c "ls -l" -h "localhost" -lh

Exemple avec une sortie au format JSON :

automation-cli run -c "ls -l" -h "localhost" -lh -json

[
  {
    "userInput": "localhost",
    "resolvedAs": "127.0.0.1"
  }
]

Commutateur -s (silent)

L’opération sera exécutée en mode silencieux : pas de sortie standard ni de rapport de post-exécution, seules les erreurs seront affichées.

Utiliser ce commutateur dans le cadre d’exécution par tâche ordonnancée (cron).

Lorsqu’une tâches est exéctutée par “cron”, les sorties sont automatiquement redirigées vers l’email du compte qui exécute cette tếche. Ceci évite l’envoi inutile d’ e-mails.

Commutateur -q (quiet)

L’opération sera exécutée en mode silencieux : pas de sortie erreurs ni de rapport de post-exécution, seules la sortie standard est affichées, excepté pour les opération utilisant le mode “register”.

Utiliser ce commutateur pour récupérer une valeur. Exemple, vous exécutez une opération qui retourne un identifiant, vous pouvez récupérer cette valeur dans une variable, qui pourrait être utilisée par la prochaine commande (ici un simple “echo”) :

variable=$(automation run -op "myoperation" -h "localhost" -q -y)
echo "${variable}

Communtateur -e

Ce commutateur est chargé de fournir les valeur de l’environnement des opérations. La syntaxe est : -e NOMVARIABLE="VALEUR". Vous pouvez spécifier plusieurs ce commutateur. Les valeurs fournies ici sont prioritaires sur toute les valeurs fournies par “operation” et “operationBook”. Il peut aussi servir pour enrichir l’environnement de préparation. Il pourra être utilisé dans les interpolation que l’on peut retrouver dans un inventaire ou la paramètre “when” dans “operationBook”. Attention les valeurs passées au moyen de ce commutateur ne peuvent pas surcharger votre environnement de travail courant. Par exemple votre environnement spécifie la variable “USER”, passer une nouvelle valeur par ce commutateur ne sera pas pris en compte. Dans ce cas, vous savez ce que vous faîtes, cette variable devra préfixer la commande “automation-cli” : USER="other" automation-cli run ....

Pour plus d’information sur l’environnement consulter ce chapitre.

|clearlogs| - Suppression des logs

Les fichiers de logs sont enregistrés dans le répertoire “automation.logs” de l’utilisateur exécutant l’opération : [Home Directory]/automation.logs.

“automation-cli” n’efface jamais automatiquement ces fichiers. Votre intervention est nécessaire en indiquant le nombre de jours à conserver :

• supprimer tous les fichiers sans exception : automation-cli clearlogs 0
• conserver seulement les 2 jours précédents la date courante : automation-cli clearlogs 2

Cette partie étant très sensible, cette commande ne prévoit pas de commutateur de confirmation. Pour automatisez, sans ambiguïté, utilisez cette commande :

echo "Y" | automation-cli clearlogs 10

|catop| - Catalogue des opérations

Pour obtenir l’affichage d’un catalogue complet des opérations d’un “OPSDirectory”.

Commande : OPS="$(pwd)" automation-cli catop

Vous pouvez filtrer par nom d’opération avec le commutateur “-f [Filter]“

|tree| - Visualisation des opérations sous forme d’arbre

Une manière très visuelle de voir le contenu des opérations d’un OPSDirectory : OPS="$(pwd)" automation-cli tree.

Cette commande dispose de plusieurs options (OPS="$(pwd)" automation-cli tree --help), notamment une option permettant de générer la commande complète d’exécution d’une opération (“-gc” & “-h”). Cette option permet de générer une commande complète incluant les paramètres requis, optionnels et la liste des hôtes cibles.

|search| - Recherche sur les opérations

Cette commande permet de rechercher parmi toutes les opérations, un ou plusieurs mots présents dans le nom de l’opération ou de son commentaire, pour produire une liste des opération qui correspondent.

|deplist| - Dépendance de paquets

L’attribut “dependencies” dans une opération est la liste des paquets Debian nécessaires pour exécuter une opération. Cette fonctionnalité permet d’afficher un récapitulatif des ces valeurs par opération (opérations situées dans OPSDirectory).

Concernant les options :

automation-cli deplist --help

|importop/exportop| - Import/Export d’une opération

“automation-cli” permet, comme indiqué, d’importer ou d’exporter une opération.

Le fichier généré est au format Zip.

Commande :

• Importer une opération: OPS="$(pwd)" automation-cli importop -f [full path zip file]
• Exporter une opération: OPS="$(pwd)" automation-cli exportop -op [operation name]

|listen| - Récupérer des informations du réseau

Cette commande a été implémentée dans le but de retrouver facilement un serveur sur le réseau. C’est une fonction très pratique quand vous ne maîtrisez la configuration du service DHCP sur le réseau. Ou bien lorsque vous utilisez des RaspberryPI, la carte ne présente d’inscription concernant l’adresse MAC, il est donc impossible de configurer le serveur DHCP par avance.

Pour implémenter ce dispositif, le serveur doit démarrer le service que j’ai nommé “presence” et disponible dans les collections d’opérations

Une fois le service installé et le serveur démarré, à partir de votre noeud de contrôle, sur le même réseau que le serveur, exécutez :

automation-cli listen

Les serveurs ne sont affichés qu’une seule fois.

CTRL+C pour quitter, pour les options, ajoutez --help.

Le service “presence” installé sur un serveur, émet un signal (hostname du serveur) toutes les 15 secondes sur l’adresse de broadcast du réseau.

Fonction de mise à jour dynamique de l’inventaire

En utilisant le commutateur “-i [inventoryFile]”, l’hôte detécté sera ajouté à la liste représentée par l’attribut : “serversGroups” de l’inventaire.

Exemple, votre fichier d’inventaire ”./inventory.yaml” avant la mise à jour :

serverGroups
  - all
  [...]
  server: 172.28.1.1

Etat du fichier d’inventaire après la mise à jour dynamique :

serverGroups
  - all
  [...]
  server: 172.28.1.1
  infra: 172.28.1.10

[serve] Serveur web minimaliste

Pour des raisons pratiques sur un réseau local, “automation-cli” peut distribuer des fichiers au moyen d’un service web. Ce service est minimaliste, n’espérez pas héberger un site avec ce système :).

Je m’en sert, par exemple, pour exposer des clés publiques ssh, des shells, des images iso, etc. Les valeurs par défaut sont :

• Port d’écoute: 9200
• Répertoire de travail “$OPS/public”.

Vous pouvez modifier ces valeurs en passant les commutateurs : -d et/ou -p.

Le principe est simple, vous créez le répertoire “public” dans votre “OPSDirectory”, ajoutez quelques fichiers et démarrez le service :

OPS="$(pwd)" automation-cli serve

Les autres postes de travail peuvent s’y connecter à l’adresse affichée (CTRL+C pour stopper).

[audit] Audit de sécurité

Tous les détails ici

OPS="$(pwd)" automation-cli audit