L'automatisation des tâches que nous effectuons est l'une des parties les plus importantes de notre travail en tant qu'administrateur système. Il ne s'agit pas seulement d'effectuer les nombreuses tâches nécessaires pour maintenir les systèmes que nous prenons en charge opérationnels. Il s'agit de nous faciliter la tâche, ainsi qu'aux autres administrateurs système qui pourraient nous remplacer pendant que nous sommes en vacances ou malades ; il s'agit de s'assurer que nous pouvons effectuer nos tâches rapidement et facilement avec un minimum de travail et d'intervention de notre part ; il s'agit - hmmm, devrais-je vraiment dire cela - d'être l'administrateur système paresseux.
J'ai beaucoup écrit sur l'automatisation dans mes livres et articles, et mon mantra est toujours "tout automatiser". Mais comment savoir par où commencer ?
[ Vous pourriez également aimer : 8 conseils pour une automatisation fiable du système Linux ]
Le point douloureux
J'ai commencé sur la voie de l'automatisation en réduisant un problème majeur pour l'une des tâches les plus importantes effectuées par les administrateurs système :les sauvegardes. J'ai commencé avec un très petit réseau : un ordinateur et une connexion Internet. Les sauvegardes étaient faciles, même si la technologie consistait en une série de lecteurs de bande qui finissaient par tomber en panne.
Au départ, je tapais une commande le vendredi soir pour sauvegarder tous mes répertoires importants et vérifiais parfois que les sauvegardes avaient bien été créées. C'était, principalement, à cause du ruban adhésif.
Au fur et à mesure que mon réseau grandissait et que je devenais responsable de réseaux autres que le mien, j'ai constaté que l'utilisation de la ligne de commande pour effectuer plusieurs sauvegardes devenait assez fastidieuse. Cependant, la technologie a évolué et j'ai également découvert que les disques durs USB externes constituent un excellent support de sauvegarde, et un script facilite grandement la sauvegarde de plusieurs ordinateurs. L'utilisation de tâches cron ou de minuteurs systemd me permet également de planifier des sauvegardes.
Mon système de sauvegarde actuel utilise un script Bash qui utilise rsync pour créer des sauvegardes d'une douzaine d'ordinateurs maximum sur mon réseau domestique existant. Les sauvegardes sont d'abord créées sur un disque dur interne de 4 To, puis écrites sur l'un des disques durs USB externes de 4 To. Je peux facilement transporter les disques externes dans mon coffre-fort pour une sauvegarde hors site. Vous pouvez lire les détails de ce système de sauvegarde dans mon article, Utiliser rsync pour sauvegarder votre système Linux. La clé est de trouver votre point de douleur le plus intense et de commencer par là.
Ma stratégie
Je n'ai vraiment qu'une seule stratégie pour déterminer ce qu'il faut automatiser en premier ou ensuite. Il s'agit simplement de déterminer la tâche qui me cause le plus de douleur à l'instant présent. Cette douleur peut être de devoir passer beaucoup de temps à taper les mêmes commandes à plusieurs reprises, à attendre que les choses se passent avant d'entrer la commande suivante, à se souvenir de la syntaxe appropriée pour les commandes que j'utilise fréquemment, etc.
Vous connaissez probablement déjà la source de la plus grande douleur dans votre vie d'administrateur système. C'est la première chose que vous devriez envisager d'automatiser, surtout si c'est relativement petit et pas aussi majeur ou important qu'un système de sauvegarde complet et avancé. J'ai commencé avec un système de sauvegarde simple qui utilisait tar et quelques fonctionnalités amusantes de SSH, dont j'ai parlé dans Best Couple of 2015 :tar et ssh.
D'autres problèmes pour moi ont été d'effectuer des mises à jour de Fedora, y compris des correctifs de sécurité et fonctionnels ainsi que des améliorations de fonctionnalités. Cela inclut également la réalisation de mises à niveau d'une version de Fedora à la suivante, comme de Fedora 32 à Fedora 33.
Il existe également de nombreuses options pour mettre en œuvre l'automatisation, quelle que soit la tâche. Une partie de ma stratégie a été de commencer par utiliser des scripts pour bien comprendre les solutions et tous les problèmes qui pourraient être rencontrés. Je vais écrire un script pour résoudre un problème sur un hôte, le copier sur tous les hôtes du réseau, puis taper les programmes Bash en ligne de commande pour effectuer cette tâche sur tous les hôtes. Cela prend la forme :
for host-name in `cat ~/list-of-hosts` ; do ssh host-name "script-name"; done Mais même cela devient une corvée et un autre problème avec suffisamment d'hôtes sur suffisamment de réseaux. Cela peut également être problématique lorsque certains hôtes doivent être traités différemment des autres. J'ai découvert que des outils plus avancés tels qu'Ansible peuvent automatiser des tâches sur de nombreux hôtes sur un réseau tout en traitant certains types, tels que les serveurs, différemment des postes de travail standard. Ansible ne nécessite pas la distribution de scripts sur chaque hôte pour effectuer son travail ; il n'est même pas nécessaire de l'installer sur chaque hôte, mais uniquement sur le système utilisé comme "hub".
Le point douloureux du PHB
Nous avons tous eu des patrons aux cheveux pointus (PHB), et parfois ils sont le point douloureux. Supposons qu'un PHB demande une liste de tous les RPM sur un ordinateur Linux particulier et une courte description de chacun. Cela m'est arrivé alors que je travaillais dans l'État de Caroline du Nord. L'open source n'était pas "approuvé" pour une utilisation par les agences d'État à l'époque, et je n'utilisais Linux que sur mon ordinateur de bureau. Les PHB avaient besoin d'une liste de chaque logiciel installé sur mon système afin qu'ils puissent "approuver" une exception.
Il m'a fallu environ cinq minutes pour écrire un script rapide qui pourrait être exécuté autant de fois à l'avenir qu'ils m'ont posé la même question. Il répertorie les packages RPM installés sur mon hôte et extrait la description de chaque package. Ce script a produit une liste de plus de 1 900 packages avec une courte description de chacun. J'ai envoyé cette liste au PHB qui l'avait demandée et n'en a plus jamais entendu parler.
Parfois, le point douloureux est facilement et rapidement résolu. Mais les PHB exigent généralement une attention immédiate.
[ Vous souhaitez en savoir plus sur l'automatisation du système ? Démarrez avec The Automated Enterprise, un livre gratuit de Red Hat. ]
Réflexions finales
J'ai commencé par créer un script d'automatisation simple pour traiter la tâche qui me causait le plus de douleur. Je suis ensuite passé au point douloureux suivant, et ainsi de suite. Finalement, ces points douloureux d'origine reviennent et doivent être affinés à l'aide d'outils plus avancés tels qu'Ansible. Il s'agit d'un processus itératif qui ne finira jamais.