🥇 Meilleures pratiques pour les scripts bash : un guide concis pour des scripts bash fiables et performants

Papier peint Shell par manapi

Le débogage des scripts bash est comme chercher une aiguille dans une botte de foin, d'autant plus que de nouvelles extensions apparaissent dans une base de code existante sans un examen opportun des questions de structure, de journalisation et de fiabilité. Dans de telles situations, on peut se retrouver confronté à ses propres erreurs tout en gérant des enchevêtrements complexes de scripts.

Commande Mail.ru Cloud Solutions J'ai traduit un article avec des recommandations qui vous aideront à mieux écrire, déboguer et maintenir vos scripts. Que vous le croyiez ou non, rien ne peut égaler la satisfaction d'écrire un code bash propre, prêt à l'emploi, qui fonctionne à chaque fois.

Dans l'article, l'auteur partage ce qu'il a appris au cours des dernières années, ainsi que certaines erreurs courantes qui l'ont surpris. C'est important car chaque développeur de logiciels travaille, à un moment donné de sa carrière, avec des scripts pour automatiser des tâches professionnelles répétitives.

Gestionnaires de pièges

La plupart des scripts bash que j'ai rencontrés n'ont jamais utilisé de mécanisme de nettoyage efficace lorsqu'il se passe quelque chose d'inattendu pendant l'exécution du script.

Des surprises peuvent survenir de l'extérieur, comme la réception d'un signal du noyau. Gérer de tels cas est extrêmement important pour garantir que les scripts soient suffisamment fiables pour être exécutés dans des systèmes de production. J'utilise souvent des gestionnaires de sortie pour réagir à de tels scénarios :

function handle_exit() {
  // Ajoutez du code de nettoyage ici
  // par exemple. rm -f "/tmp/${lock_file}.lock"
  // quittez avec un code de statut approprié
}
  
// trap  
trap handle_exit 0 SIGHUP SIGINT SIGQUIT SIGABRT SIGTERM

trap est une commande intégrée de l'interpréteur de commandes qui vous aide à enregistrer une fonction de nettoyage appelée en cas de signaux. Cependant, il faut faire particulièrement attention avec des gestionnaires comme SIGINT, qui provoque l'interruption du script.

De plus, dans la plupart des cas, il convient de ne capturer que EXIT, mais l'idée est que vous pouvez vraiment personnaliser le comportement du script pour chaque signal individuel.

Fonctions intégrées set - arrêt rapide en cas d'erreur

Il est très important de réagir aux erreurs dès qu'elles surviennent et d'arrêter rapidement l'exécution. Rien n'est pire que de continuer à exécuter une commande comme celle-ci :

rm -rf ${directory_name}

Notez que la variable directory_name n'est pas définie.

Pour traiter de tels scénarios, il est important d'utiliser les fonctions intégrées set, telles que set -o errexit, set -o pipefail ou set -o nounset au début du script. Ces fonctions garantissent que votre script s'arrête dès qu'il rencontre un code de sortie non nul, l'utilisation de variables non définies, de commandes incorrectes passées par le pipeline, et ainsi de suite :

#!/usr/bin/env bash

set -o errexit
set -o nounset
set -o pipefail

function print_var() {
  echo "${var_value}"
}

print_var

$ ./sample.sh
./sample.sh: line 8: var_value: unbound variable

Remarque : fonctions intégrées, telles que set -o errexit, sortiront du script dès qu'un code de retour « non géré » (autre que zéro) apparaîtra. Il est donc préférable d'introduire un traitement d'erreurs personnalisé, par exemple :

#!/bin/bash
error_exit() {
  line=$1
  shift 1
  echo "ERROR: non zero return code from line: $line -- $@"
  exit 1
}
a=0
let a++ || error_exit "$LINENO" "let operation returned non 0 code"
echo "you will never see me"
# run it, now we have useful debugging output
$ bash foo.sh
ERROR: non zero return code from line: 9 -- let operation returned non 0 code

Écrire des scripts de cette manière vous oblige à prêter une attention particulière au comportement de toutes les commandes dans le script et à prévoir la possibilité d'erreurs avant qu'elles ne vous surprennent.

ShellCheck pour détecter les erreurs lors du développement

Il vaut la peine d'intégrer quelque chose comme ShellCheck dans vos pipelines de développement et de test pour vérifier votre code bash selon les meilleures pratiques.

Je l'utilise dans mes environnements de développement locaux pour obtenir des rapports sur la syntaxe, la sémantique et certaines erreurs de code que j'aurais pu manquer lors du développement. C'est un outil d'analyse statique pour vos scripts bash, et je le recommande vivement.

Utilisation de vos codes de sortie

Les codes de retour en POSIX ne se limitent pas à zéro ou un, mais peuvent aussi être zéro ou une valeur non nulle. Profitez de cette fonctionnalité pour renvoyer des codes d'erreur personnalisés (entre 201-254) pour différents cas d'erreur.

Ces informations peuvent ensuite être utilisées par d'autres scripts qui enveloppent le vôtre, pour comprendre exactement quel type d'erreur s'est produit et réagir en conséquence :

#!/usr/bin/env bash

SUCCESS=0
FILE_NOT_FOUND=240
DOWNLOAD_FAILED=241

function read_file() {
  if ${file_not_found}; then
    return ${FILE_NOT_FOUND}
  fi
}

Remarque : veuillez faire particulièrement attention aux noms de variables que vous définissez afin d'éviter de redéfinir accidentellement des variables d'environnement.

Fonctions de logging

Une gestion des logs belle et structurée est essentielle pour comprendre facilement les résultats de l'exécution de votre script. Comme dans d'autres langages de programmation de haut niveau, j'utilise toujours dans mes scripts bash des fonctions de journalisation personnalisées, telles que __msg_info, __msg_error et ainsi de suite.

Cela permet d'assurer une structure de journalisation standardisée, en apportant des modifications à un seul endroit :

#!/usr/bin/env bash

function __msg_error() {
    [[ "${ERROR}" == "1" ]] && echo -e "[ERROR]: $*"
}

function __msg_debug() {
    [[ "${DEBUG}" == "1" ]] && echo -e "[DEBUG]: $*"
}

function __msg_info() {
    [[ "${INFO}" == "1" ]] && echo -e "[INFO]: $*"
}

__msg_error "File could not be found. Cannot proceed"

__msg_debug "Starting script execution with 276MB of available RAM"

J'essaie généralement d'avoir dans mes scripts un mécanisme __init, où de telles variables de journalisation et d'autres variables système sont initialisées ou définies avec des valeurs par défaut. Ces variables peuvent également être définies à partir des paramètres de ligne de commande lors de l'appel du script.

Par exemple, quelque chose comme :

$ ./run-script.sh --debug

Lorsque ce script est exécuté, il garantit que les paramètres système sont définis sur des valeurs par défaut, si cela est obligatoire, ou, au minimum, initialisés par quelque chose de pertinent si nécessaire.

Je base généralement mon choix sur ce qui doit être initialisé ou non, sur un compromis entre l'interface utilisateur et les détails de configuration que l'utilisateur peut/doit comprendre.

Architecture pour la réutilisation et l'état propre du système

Code modulaire / réutilisable

├── framework
│   ├── common
│   │   ├── loggers.sh
│   │   ├── mail_reports.sh
│   │   └── slack_reports.sh
│   └── daily_database_operation.sh

Je garde un dépôt séparé qui peut être utilisé pour initialiser un nouveau projet/script bash que je souhaite développer. Tout ce qui peut être réutilisé peut être conservé dans le dépôt et récupéré dans d'autres projets qui souhaitent utiliser telles fonctionnalités. Cette organisation des projets réduit considérablement la taille des autres scripts et garantit également que la base de code est petite et facilement testable.

Comme dans l'exemple ci-dessus, toutes les fonctions de journalisation, telles que __msg_info, __msg_error et d'autres, comme des rapports sur Slack, sont contenues séparément dans common/* et sont dynamiquement incluses dans d'autres scénarios, comme daily_database_operation.sh.

Laissez un système propre

Si vous chargez des ressources pendant l'exécution d'un script, il est recommandé de stocker toutes ces données dans un répertoire commun avec un nom aléatoire, par exemple /tmp/AlRhYbD97/*. Vous pouvez utiliser des générateurs de texte aléatoire pour choisir le nom du répertoire :

rand_dir_name="$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1)"

Après l'exécution, le nettoyage de ces répertoires peut être assuré par les gestionnaires de pièges, comme mentionné ci-dessus. Si l'on ne prend pas soin de supprimer les répertoires temporaires, ils s'accumulent et peuvent, à un certain moment, causer des problèmes inattendus sur l'hôte, comme un disque plein.

Utilisation des fichiers de verrouillage

Il est souvent nécessaire d'assurer l'exécution d'une seule instance d'un script sur l'hôte à tout moment. Cela peut être fait en utilisant des fichiers de verrouillage.

Je crée généralement des fichiers de verrouillage dans /tmp/project_name/*.lock et vérifie leur existence au début du script. Cela aide à bien terminer le script et à éviter des modifications inattendues de l'état du système par un autre script s'exécutant en parallèle. Les fichiers de verrouillage ne sont pas nécessaires si vous devez exécuter le même script en parallèle sur cet hôte.

Mesurer et améliorer

Nous avons souvent à travailler avec des scripts qui s'exécutent pendant de longues périodes, comme des opérations quotidiennes sur des bases de données. Ces opérations comprennent généralement une séquence d'étapes : chargement des données, vérification des anomalies, importation des données, envoi de rapports d'état, etc.

Dans de tels cas, j'essaie toujours de décomposer le script en petits scripts distincts et de signaler leur état et leur temps d'exécution avec :

time source "${filepath}" "${args}" >> "${LOG_DIR}/RUN_LOG" 2>&1

Plus tard, je peux consulter le temps d'exécution avec :

tac "${LOG_DIR}/RUN_LOG.txt" | grep -m1 "real"

Cela m'aide à identifier les zones problématiques/lentes dans les scripts nécessitant une optimisation.

Bonne chance !

Que lire d'autre :

Source : habr.com

Meilleures pratiques des scripts bash : guide concis pour des scripts bash fiables et performants