J’ai déjà mentionné un certain nombre de limitations à bash dans mon premier article sur le sujet. Mais au final tout peut se résumer à un point: quand on fait du logiciel (ce qu’est un script), on fait de l’ingénierie logicielle et non du bricolage. On veut de la qualité. Et pour cela, on applique les bonnes pratiques de développement comme n’importe quel développeur. Et bash n’est tout simplement pas bon à cela.

Gestion des dépendances

Arrêtons s’il vous plaît de comparer source en bash avec un vrai système de gestion de dépendances supportant:

Ecosystème

C’est bien sûr en lien avec la gestion des dépendances mais pouvoir bénéficier de librairies de qualité (ce qui est le cas dans des langages comme Golang ou Python que l’on retrouve souvent dans l’administration système) est toujouts intéressant. Ecrire une CLI en Golang avec une gestion correcte des commandes et flags (commandes, sous commandes, flags optionnels ou non, répétition de flags, gestion de priorités entre flags et configuration via variables d’environnement…​ le tout vérifié grâce à du typage statique) se fait assez bien, de manière largement plus simple qu’en bash.

Clients de base de données (SQL, NoSQL…​), de cloud, de queues ou logs distribués (RabbitMQ, Kafka…​), ou même d’outils comme Kubernetes sont autant de choses très facilement utilisables dans des langages de programmation modernes, et qui ne le sont pas en bash. Vous pourriez certes me citer kafkacat, la CLI aws ou kubectl…​ mais ce n’est pas du tout le même niveau de confort à l’utilisation, la même fiabilité, ni les mêmes garanties qu’un SDK.

Mais l’écosystème ici va également plus loin. J’aime parler aussi d’écosystème d’entreprise (ou écosystème interne). Pouvoir partager des dépendances entre équipes (que ce soit dev ou ops, car les deux font au final du logiciel) est par exemple super. Cela permet de la même façon à n’importe quelle équipe de contribuer et faire évoluer les outils internes si besoin.

Outillage

J’ai déjà parlé de l’outillage dans la gestion des dépendances. Linter, analyse statique de code, IDE intelligents, outils pour les tests (mocking, framework de tests)…​ sont autant d’outils dont les équivalents pour le shell sont tout justes passables.

Logs

Logs structurés, gestion simplifiée de la verbosité via l’utilisation de logger globaux, possibilité de passer simplement sans changer le code, mais seulement la configuration du logger, sur des formats de sortie différents (texte, json…​). C’est ça qu’on veut aujourd’hui.
Des intégrations comme Sentry sont également très intéressantes et facilitées avec des langages autres que bash, notamment par l’utilisation de librairies fournies directement par l’éditeur ou par la construction d’abstractions au dessus d’une librairie de logging.

Gestion des erreurs

Comment peut-on comparer les erreurs de bash (utilisation de set, de code de retours…​) et des systèmes d’erreurs modernes présents dans les langages de programmations ? Type Result ou Error, exceptions, classification d’erreurs, vérification statique que toutes les erreurs sont correctement gérées…​ Comparer les deux n’est pas pertinent et montre vraiment un manque d’expérience en développement.

Métriques

Je parlais dans mon premier article sur le shell des métriques. Cela a souvent été interprété en mode "lol en shell on a time a on a une variable qui donne le temps d’exécution du script". Raisonner comme cela montre une certaine incompréhension des bonnes pratiques de monitoring.
Nos scripts ont souvent besoin de faire des I/O: appels HTTP divers, interactions avec des services SaaS, actions sur le système de fichier ou avec des bases de données par exemple. Comment dit précémmement nous essayons toujours de réutiliser ces scripts dans différents contextes, voir de fournir en tant que librairie externe certaines fonctionnalités.

Les systèmes de monitoring modernes supportent plusieurs types de métriques: gauges, histogrammes, counter…​ permettant ensuite de dériver de nombreuses autres métriques: rates (requêtes par secondes) ou quantiles (p99, p95…​sur des I/O) par exemple. Ces systèmes supportent également l’ajout de labels sur les métriques.

Nous avons besoins de métriques dans nos programmes, comme par exemple:

Ici, bash ne tient pas aussi la comparaison.

J’ai cité précédemment quelques points importants, mais d’autres le sont encore plus.

Le nerf de la guerre aujourd’hui est la donnée. On interagit en permanence avec des données de tout types. Fichiers de configuration, payload de requêtes et réponses HTTP, résultat de requêtes à des bases de données…​. nos scripts et programmes travaillent avec de la donnée, en entrée et en sortie.

Bash n’est pas un bon outil pour travailler avec de la donnée: structures de données limitées et avec peu de fonctionnalités built-in pour interagir avec ces données (itérations, map, reduce, filter…​), pas de façons simples de représenter des données (typage fort, structure de données immuables par exemple), ou de la sérialisation et désérialisation des données (mapping entre des types et des données en json ou YAML, gestion de valeurs optionnelles, validation métiers sur les données). Il faut vraiment aimer se donner du travail pour vouloir utiliser bash pour tout besoin un peu sérieux demandant interaction avec des systèmes externes.

On pourrait également parler du threading, d’architecture logicielle, de programmation fonctionnelle, de typage statique…​ Bref, de sujets familiers aux développeurs. J’ai souvent entendu dire par les fan du bash "je ne veux pas apprendre à coder donc je fais du bash". Je traduis personnellement cela par "je refuse de m’imposer une certaine rigueur dans ce que je produis". Bash ne serait donc pas du code ? C’est donc OK d’utiliser des outils peu efficaces dans une tâche donnée car "on a toujours fait comme ça" ? J’ai vraiment du mal à comprendre cette approche.

Et franchement, quelqu’un qui a réussit à maîtriser bash ne devrait pas avoir trop de mal à basculer sur un langage plus évolué qui au contraire lui donnera encore plus de garanties de fiabilité sur ce qui est produit.

Je ne vais pas m’étendre plus sur le sujet du développement car mon but n’est pas non plus d’écrire un article de type "programming 101". Mais répétons le encore une fois: bash n’est pas un bon outil pour développer.

C’est également un point important que j’ai déjà mentionné précédemment mais sur lequel il faut insister. Ce que l’on produit n’est pas que pour nous, mais aussi pour notre équipe et pour notre entreprise. Encourager les gens à contribuer à des scripts et programmes, à partager des librairies et faciliter la construction d’un écosystème interne (ou externe via l’open source) est ce qui apportera de la valeur sur le long terme à l’entreprise.

Et ce long terme est important. Car j’ai l’impression dans ce débat "bash vs le reste du monde" que c’est aussi deux visions de l’administration système qui s’affrontent. D’un côté une vision court-termiste, à coup de scripts bash "roulés sous les aisselles" comme j’ai entendu récemment, où le but est d’essayer d’éteindre l’incendie en mode "quick and dirty". Et une vision long terme, basée sur l’ingénierie, la qualité, le travail en équipe, la fiabilité, la reproductibilité des actions, et avec une projection sur les besoins et les évolutions futures de la plateforme. Bash n’a rien à faire dans cette dernière.

Je comprends que bash puisse sembler utile dans certains contextes "entreprises difficiles", mais c’est aussi de notre devoir en tant que professionnel de conseiller et mettre en place des solutions pérennes dans le temps. On a tous des contraintes que je peux comprendre et que parfois faire un truc peu maintenable mais rapidement disponile peut se justifier. Mais cela n’en fait pas une bonne pratique à promouvoir pour autant, plutôt quelque chose à garder en tête et à supprimer lorsque l’occasion s’en présente.

Bash peut être un outil intéressant pour certains petits besoins. Chaîner un kubectl -o json avec un jq, utiliser du awk/grep…​ pour rapidement récupérer une information m’arrive fréquemment. Pour des petits scripts "one shot", qui ne sont jamais réutilisés une fois lancés, pourquoi pas (et encore). Si vous avez quelques commandes simples à lancer dans un script de CI, ça le fait.

Mais c’est tout. N’utilisons pas bash pour de l’administration système long terme ou des systèmes critiques ou complexes.

Change my mind (ce sera compliqué).