// LINUXFR.ORG — LINUX & OPEN SOURCE
Scrippy : en finir avec script_final_old_v3_OK_last.py
Tout administrateur système a croisé un jour, au détour d'un serveur, un script_final_old_v3_OK_last.py sans logs, sans historique, avec un mot de passe en clair à la ligne 42 et un commentaire # TODO: gérer les erreurs daté de 2014.
Après cinq ans de développement en parallèle de mes activités professionnelles, je publie Scrippy, un framework Python sous licence MIT pour écrire des scripts d'exploitation standardisés, robustes et prêts pour la production.
Dans beaucoup d'équipes, les scripts d'exploitation sont écrits vite, chacun à sa manière, puis maintenus dans la douleur. Le cycle de vie typique est bien connu :
Le tout agrémenté d'un mot de passe qui s'affiche fièrement dans la sortie standard. Oui, hunter2, on te voit.
Avec Scrippy, un script décrit son comportement dans un en-tête déclaratif : auteur, version, description, configuration attendue, options acceptées, utilisateurs autorisés, nombre d'exécutions simultanées. Une seule instruction with dans le code suffit ensuite pour bénéficier de l'ensemble des fonctionnalités, sans écrire une seule ligne de plomberie :
Voici un script de surveillance de l'occupation d'un système de fichiers. Toute ressemblance de l'auteur avec un personnage des Monty Python n'est évidemment pas fortuite : on fait du Python, on a des traditions.
Ce court script dispose déjà de --help, --version, d'un fichier de configuration validé, d'une option --mount-point validée, d'un log par exécution (--log), d'un historique (--hist), d'un mode debug (--debug) et d'un espace de travail temporaire. Le tout sans avoir vendu son âme à un fichier YAML de 800 lignes, ni avoir à relire une n-ième fois la doc de argparse, ni sans incantation mystique pour la configuration de log, ni pentacle renversé. Ni !
D'une part, tous les scripts d'exploitation suivent le même standard : ils se lisent, s'exploitent et se maintiennent de la même façon, quel que soit leur auteur. Le script du collègue parti n'est plus une boîte noire.
D'autre part, ils s'écrivent beaucoup plus vite : inutile de recoder ces contrôles dans chaque script, on se concentre sur ce qu'il doit réellement faire. Le temps gagné peut être réinvesti dans des activités à haute valeur ajoutée, comme le troll sur systemd.
Le cœur (scrippy-core) est complété par des modules optionnels :