Préface
J’ai parfois entendu certaines personnes tenter de se justifier avec l’argument suivant quand il s’agissait de faire le travail d’un ordinateur :
Étant donné que je dois réaliser cette tâche une seule fois par mois, développer une solution me ferai perdre plus de temps qu’elle ne m’en ferai gagner.
Sauf que cet argument considère la rentabilité uniquement au niveau du temps.
De mon point de vue cette justification n’est pas réaliste car en effet le temps de développement de cette solution d’automatisation dépend énormément de votre expérience dans le domaine (maitrise des langages de script, connaissance des outils en ligne de commande classiques, connaissances d’outils systèmes tels que cron, …).
« Ça prend trop de temps pour ce que ça fait » / CC-BY Alan O'Rourke
Plus vous avez l’habitude d’automatiser des tâches et moins cela prend de temps ! Mais comment acquérir cette précieuse expérience ? Tout simplement en automatisant tout, même les petites tâches que vous devez effectuer uniquement une seule fois par mois.
Ça va vous prendre du temps, vous allez galérer à chercher pendant plusieurs heures dans votre moteur de recherche (ou vos pages de man) à essayer de comprendre comment utiliser tel ou tel outil. Mais au final, la prochaine fois que vous devrez automatiser une tâche qui aura vraiment besoin de l’être, vous aurez déjà suffisamment d’expérience pour savoir ou chercher les informations et sur quels outils vous baser en fonction de vos besoins.
Pour une seule machine : les scripts shells
La manière la plus simple de faire de l’automatisation sur une machine UNIX (GNU/Linux et *BSD) reste d’écrire des scripts shell. Il faut néanmoins distinguer les deux langages principaux qui permettent de se lancer dans l’écriture de tels scripts :
- sh est le shell standard imposé par POSIX. Je vous recommande fortement d’écrire vos scripts dans ce langage.
- bash est une surcouche à sh qui − à mon avis − n’apporte rien d’intéressant au niveau de la rédaction des scripts par rapport au bon vieux shell standard (et apporte même quelques pièges). Je vous le déconseille, sauf si vous avez de bonnes raisons de l’utiliser à la place de sh.
Vous pouvez lire l’excellent Linux Shell Scripting Tutorial pour débuter dans le merveilleux monde du Bourne shell et du scripting de manière générale sur systèmes *NIX, ou approfondir vos connaissances pour ceux qui ont déjà écrit des petits utilitaires avec.
Voici ci-dessous un exemple d’utilisation de script que j’ai réalisé et dont je me sert afin de générer un corps pour les nouveaux articles de ce site :
Vous voyez bien que c’est pas grand chose (génération d’un bête fichier texte) mais je m’en sers désormais tout le temps, même si je ne publie pas forcément souvent !
Pour plein de machines : Ansible
Si vous devez non plus automatiser une tâche sur une seule mais un ensemble de machines, il existe des outils spécialisés permettant de gérer tout un parc de machines : Ansible, Puppet, Chef, et d’autres qui doivent sans doute exister.
J’ai pour ma part retenu Ansible qui − d’après mes différentes recherches sur le sujet − était le plus simple à découvrir pour une première expérience avec ces outils de gestion de parc (et de gestion d’un peu de tout et de rien au final, c’est juste prévu pour plusieurs machines mais on peut en faire ce que l’on veut).
La première solution d’automatisation que j’ai réussi à mettre en place est donc la suivante :
Ce playbook (vocabulaire Ansible qui se rapporte simplement à une suite d’actions à effectuer sur les hôtes) me permet de synchroniser mes dotfiles sur mes différentes machines.
Voici le contenu du rôle dotfiles qui est appelé par le playbook :
---
- name: Add user microjoe
user: name=microjoe state=present
- name: Clone dotfiles.git
git:
repo=ssh://git@git.microjoe.org/MicroJoe/dotfiles.git
dest=~/dotfiles
accept_hostkey=yes
key_file=~/.ssh/gitlab_perso
- name: Installing symlinks for CLI programs
command:
./install.sh cli
args:
chdir: ~/dotfiles
- name: Install symlinks for Vim
command:
./install.sh vim
args:
chdir: ~/dotfiles
Le seul problème que j’ai rencontré est la gestion un peu compliquée des clés SSH entre les différentes machines. La solution temporaire que j’ai adopté est de passer la clé de l’hôte Ansible (ici mon notebook) sur toutes les machines afin de pouvoir cloner le dépôt Git avec cette même clé.
Cependant, pour que la clé de l’hôte puisse être transférée il faut qu’une clé pour ce même serveur n’existe pas déjà dans la configuration SSH de la machine cible ; j’ai donc du supprimer mes clés SSH sur mes machines cibles afin de pouvoir utiliser cette solution.
Je suis sûr qu’il y a un moyen de mieux faire, si vous avez des suggestions n’hésitez pas à me les faire parvenir !
Si aucune techno ne vous convient…
On a donc vu deux méthodes afin de faire de l’automatisation sur une seule machine ou carrément sur un parc de machines.
Si jamais ces solutions sont insuffisantes pour vos besoin, cela ne doit pas être un obstacle. Développez vos propres solutions d’automatisation et ne baissez surtout pas les bras !
Par exemple, si les scripts shell ne vous suffisent plus car vos besoins deviennent trop complexes, vous pouvez passer sur des langages de scripts plus développés tels que Python ou Ruby qui vous permettront d’avoir la même souplesse que les scripts shell (grâce au typage dynamique) tout en vous offrant un système de modules et d’objets ainsi qu’une bibliothèque standard bien fournie afin de vous aider dans la besogne.
Le rêve de tout développeur : une automatisation complète / CC-BY Steve Jurvetson
Conclusion
J’espère que cet article vous aura motivé à vous lancer dans l’écriture de scripts pour automatiser vos tâches du quotidien, car c’est une fois que l’on commence à être à l’aise avec ces technologies qu’elles devient vraiment sympa à utiliser !