Fonctions internes
Les fonctions internes comprennent les méthodes bash internes, et les opérations intégrées (builtin).
Méthodes internes
Les méthodes bash internes peuvent être appelées dans vos scripts bash.
Wrappers d’affichage
Afin d’unifier la présentation des messages sur les sorties “standard” et “error”, j’ai créé 3 méthodes :
Méthodes | Utilisation | Sortie utilisée | Exemple d’affichage |
---|---|---|---|
_info | _info "Your message" | stdout | ”[INFO] Your message” |
_warn | _warn "Your message" | stdout | ”[WARN] Your message” |
_error | _error "Your message" | stderr | ”[ERROR] Your message” |
Changements d’état du système
Il peut s’avérer utile, de définir et d’obtenir un résumé des changements effectués par un shell sur un système.
Pour définir un changement, faite suivre la commande qui impacte l’environnement par l’instruction “_change”.
Exemple d’utilisation : Le script créé un fichier sur le système entraînant de facto un changement d’état du système, le nombre de changements opérés est indiqué dans le rapport d’exécution, tandis que le détail apparaît dans le fichier de log.
touch /tmp/myfile_change
Après exécution, vous obtenez un résultat similaire :
Le fichier de traces détaille l’intégralité des changements effectués :
Exemple de traces (sans rapport avec la copie écran précédente) :
[...]shellStdOut: #[C]: Changes made during the script execution:shellStdOut: #[C]: Change #0: /usr/bin/etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/etcd/server.crt --endpoints=https://127.0.0.1:2379 --key=/etc/kubernetes/pki/etcd/server.key snapshot save "$DIRBACKUP/etcd-snapshot-$(date +%Y-%m-%d_%H:%M:%S_%Z).db" > /dev/null 2>&1shellStdOut: #[C]: Change #1: rm -f "$F"shellStdOut: #[C][TOTAL NUMBER OF CHANGES]:2[INFO] Shell execution completed - 10/19/2024, 12:00:05 (1729332005998 in milliseconds) - Elapsed Time: 3375 ms
debInstall
Méthode idempotente pour l’installation de paquets Debian. Cette méthode est appelée automatiquement lorsque qu’un manifeste d’opération spécifie une liste de valeurs pour l’attribut : “dependencies”.
Exemple :
Le manifeste d’une opération indique une dépendance liée au paquet Debian “jq”, “automation-cli” procédera en priorité à l’installation, seulement si le paquet n’est pas installé :
[...]dependencies: - "jq"[...]
checkIsServerProtected
Cette méthode exécutée systématiquement par “automation-cli” est chargée de vérifier la présence d’un marqueur spécifique sur un serveur. Si ce marqueur est présent aucune opération ne pourra être exécutée sur ce serveur.
Du fait que les opérations sont exécutées par “root”, il convient de trouver une limitation permettant d’interdire momentanément l’exécution d’opérations (un serveur compromis, un serveur en maintenance prolongée…),
Le marqueur est le fichier “/mytinydc-runtime-protection.lock”.
Protéger un serveur
Pour protéger un serveur, exécutez :
sudo automation-cli run -h "localhost" -c "touch /mytinydc-runtime-protection.lock"
Pour tester, exécuter la commande “ls /”
automation-cli run -h "localhost" -c "ls -l"
La commande affiche un message d’erreur et sort avec le code de sortie : “2”
Retirer la protection
Pour retirer la protection, connectez-vous par SSH au serveur protégé, et supprimer le marqueur en exécutant :
sudo rm -f "/mytinydc-runtime-protection.lock"
Opérations intégrées (builtin)
Ces opérations sont réalisées par le nœud de contrôle. Le nom de l’opération commence par ”#”. La liste de ces opérations spéciales est disponible en tapant la commande : automation-cli builtin
#waitForServerRestart
Dans un “operationBook”, une étape stipule le redémarrage du serveur, en exécutant la commande “reboot”. Le problème des connexions réseaux est le “timeout”. Sur une connexion SSH cette valeur est très courte.
Pour palier à ce phénomène, j’ai créé une opération interne, dont la fonction est de détecter l’arrêt et le redémarrage du serveur. Après redémarrage les opérations continuent normalement.
Exemple d‘“operationBook” :
operations: - command: "reboot" - operation: "#waitForServerRestart" - command: "ls /"
#isCidrNetwork
Test si la valeur spécifiée est bien au format de réseau CIDR.
**Bien que ce test ne vérifie qu’une seule valeur, les opérations intégrées utilisent toutes le même framework. “values” est de type Array.
operations: [...] - operation: "#isCidrNetwork" values: [ "172.28.0.0/24" ] [...]
#isPrivateCidrNetwork
Tester si la valeur spécifiée est bien une valeur au format de réseau CIDR et si le réseau est privé.
**Bien que ce test ne vérifie qu’une seule valeur, les opérations intégrées utilisent toutes le même framework. “values” est de type “Array”.
operations: [...] - operation: "#isPrivateCidrNetwork" values: [ "172.28.0.0/24" ] [...]
#confirm
Cette opération ne fonctionne que pour un seul hôte et permet d’insérer un point d’arrêt demandant à l’utilisateur de confirmer l’exécution. Une autre implémentation est à l’étude, qui permettrait de confirmer pour l’ensemble des hôtes de la liste.
operations: [...] - operation: "#confirm" [...]