Je vais enfoncer une porte ouverte : le shell est présent sur tous les serveurs, sous un parfum ou sous un autre : sh, ksh, PowerShell, ... (Ce petit dernier, Microsoftien, encore absent de la plupart des parcs, avance à grands pas dans sa colonisation). Le shell, ainsi que ses amis CLI évolués (Perl, Python, Ruby, ...), exotiques (screen, expect, lex, ...) ou de longue date (cut, sed, awk, tail, ssh, ...). Je regroupe tout ce beau monde sous l'appellation "shell".

Il est logiquement la première solution envisagée lorsqu'il s'agit d'administrer son serveur / un serveur / ses serveurs/ son parc de serveurs.

Pourquoi ?

Pourquoi utiliser les outils du shell pour gérer un parc de serveurs ? Pour ces raisons :

• Disponible : comme dit au début de l'article, ils sont de base installés sur le serveur.
• Connu : quel administrateur, quel architecte réseau ne connait pas le shell ?
• Poulpe : constituant de base d'un serveur, s'interface avec quasiment tous les outils plus gros et plus spécifiques qu'eux : maven, rpm, apt-get, apache, svn, ...
• Léger : pas d'interface graphique, depuis le temps qu'ils existent les outils du shell ont étés épurés et adhérent étroitement à la philosophie Unix : faire une seule chose, mais la faire bien.
• Souple : standards aux possibles, ils peuvent facilement communiquer entre eux et s'organiser les uns autour des autres.
• Gratuit : est-il besoin d'en dire plus...
• Ubique : beaucoup de possibilité sont offertes pour exécuter des commandes à distances, en récupérer les résultats, déposer ou récupérer des fichiers...
• Portable : la conformité de ces outils à la norme Posix garanti la plupart du temps leur portabilité.
• Ouvert : les scripts sont par nature modifiables par tout le monde. Avec un peu de matière grise il est facile de transformer un script plein de variables en dures écrit pour un cas précis en script plein de switchs et qui s'adapte à son environnement.

Toutes ces qualités en font des outils de choix pour gérer un parc de serveurs, au moins dans un premier temps, et parfois pendant très longtemps...

... si l'on a des besoins relativement restreints : déploiement d'applications, environnement homogène (et sous *nix...), pas de versionnage de la configuration, profils de serveurs relativement identiques, grande accessibilité des machines, peu de parallélisation (quoiqu'avec Capistrano...), ergonomie un tantinet spartiate, en mode push...

Pourquoi pas ?

L'administration de machines par script shell montre tout de même des limites :

• Dès que le parc s'hétérogénéise, ou que des envies de diversité vous prennent, ces outils peuvent commence à ne plus être adaptés : introduction de machine Windows sans un parc sous *nix, volonté de gestion de routeurs, de bornes wifi, de SAN, ou même tout simplement introduction de Solaris dans un parc RedHat.
• Si votre/vos outils shell prennent une certaine place dans votre palette de moyens d'administration, leur maintenabilité peut poser problème : sont-ils centralisés ? versionnés ? lisible par un nouvel arrivant ? utilisable sans plonger dans le code pour connaître les options ?
• Avec le temps et la croissance de votre parc de serveurs, vos scripts ne commencent-ils pas à former un serpent de mer dont plus personne n'a la maîtrise et sur lequel vous comptez comme on croit en une amulette magique ?
• Les scripts, loin d'être un langage normalisé, sont un assemblage de briques. De fait, la connaissance de ces briques est indispensables, mais certains peuvent en avoir une plus grande (connaissance, hein) que d'autres. Êtes-vous sûr que le niveau de connaissance est à peu près homogène ?
• Enfin, si vous comptez, et nous espérons que c'est votre volonté, ouvrir ces outils à vos cher enn... amis développeur afin qu'ils fassent eux-même le déploiement et vous laisse à des tâches moins répétitives et moins ingrates, ces outils ont-ils une ergonomie adaptée ?

À partir d'une certaine masse de serveurs (une dizaine) et/ou de scripts, il faut se rendre à l'évidence : une adaptation doit être envisagée pour éviter de perdre la maitrise de ce qui était initialement un bout de script sur un coin de table et que l'on appelle maintenant Frankenstein (assemblage immaîtrisable de bouts hétéroclites). Il est temps d'affronter la bête les yeux dans les yeux et de choisir :

• Capitaliser sur les scripts, s'assurer qu'ils sont considérés / vus / acceptés comme une application (ou des applications) et que l'on leur donne l'outillage de dev qui va bien : gestion de version, packaging, déploiement, norme de codage/nommage, utilisation d'API / librairies pour Don't Repeat Yourself, documentation, voir, pourquoi ne pas rêver, usine de dev

• Suivre le conseil de mon avocat qui disait "mieux vaut un divorce réussi qu'un mariage raté" et étudier la possibilité de vous séparer de vos scripts pour vous pencher vers des outils plus adaptés, tels que Puppet, Chef ou CFengine.