L'administration système quand on est dev

Je vous raconte ma transition vers l'administration système avec Ansible, automatisant le déploiement et la gestion d'infrastructures grâce à l'Infrastructure as Code.
Tout a commencé quand je devais déployer un projet pour un client.
Mon tout premier client (entre 2014 et 2015), j'avais déjà fait d'autres missions pour lui mais jusqu'à présent c'était hébergé sur ses machines Windows Serveur et c'était des projets en C#.
Un jour, je lui ai fait une app pour une de ses sociétés de transport, c'était un backend Ruby on Rails et un front AngularJS (le tout premier).
Quand j'ai dû déployer ça, c'était sur un VPS d'OVH à l'époque. J'ai tellement galéré ! 😂
Et oui, jusqu'à présent je travaillais sur ma machine, j'étais familier à Linux mais de là à déployer un projet il y a encore une marge de manœuvre.
D'autant plus qu'il faut gérer la sécurité, l'exposition des ports etc... Ce qui n'était pas ma tasse de thé initialement.
Mais j'ai dû m'y mettre, tant bien que mal et j'ai fini par lui déployer son app avec Passenger, puis j'ai switché sur Nginx.
Pendant longtemps je n'ai fait que du PHP sur Apache. Mais lorsqu'il a fallu toucher à autre chose, c'était assez angoissant au départ, étant donné que ce n'était pas pour moi mais pour mon client.
Mais j'ai fini par le faire, m'y habituer et même par aimer ça.
L'évolution
Pendant un moment j'ai continué à déployer manuellement.
Puis, au bout d'un moment j'ai commencé à scripter.
Au début c'était toujours depuis ma machine avec du scp, rsync ou des ssh call directement.
J'étais déjà content de pouvoir, redémarrer un service comme ça, ou encore mettre à jour les repo distants etc.
Mais au fil du temps, j'ai compris que ce n'était pas viable, je recommençais souvent les mêmes scripts et parfois je devais adapter en fonction de la distribution de l'hôte.
Je me souviens qu'à l'époque mon mentor m'avait parlé d'Ansible, j'avais retenu le nom pas plus.
Cependant au fil du temps, mon besoin en maintenance de serveurs grandissait car j'ai de plus en plus de projets en ligne, mais je continuais à faire ces opérations à la main.
J'ai décidé de prendre le taureau par les cornes et me plonger dans le métier d'OPS afin de travailler sur l'automatisation de ces tâches et même leur planification.
La découverte d'Ansible
Ansible est une plateforme d'automatisation open-source qui simplifie considérablement la gestion de la configuration, le déploiement d'applications et l'orchestration des tâches informatiques.
Contrairement à d'autres outils similaires, Ansible fonctionne sans agent, ce qui signifie qu'il ne nécessite aucune installation préalable sur les machines cibles, utilisant simplement SSH pour communiquer avec elles.
Sa philosophie est centrée sur l'idiosyncrasie (l'état souhaité du système) plutôt que sur les actions procédurales, permettant de décrire ce que l'infrastructure devrait être au lieu de comment y parvenir.
Les playbooks, écrits en YAML, offrent une syntaxe humainement lisible pour définir des séquences d'opérations à exécuter sur des groupes de serveurs.
Avec sa large communauté et ses nombreux modules prédéfinis, Ansible s'est imposé comme un outil essentiel pour les développeurs et administrateurs système souhaitant adopter les pratiques d'Infrastructure as Code (IaC), permettant une gestion plus cohérente, reproductible et sécurisée des environnements informatiques.
J'ai mis peu de temps à comprendre le principe, car j'avais l'habitude de tout faire à la main, donc le fait d'orchestrer maintenant reste logique pour moi:
c'est une succession d'étapes que l'on organise et qui fait ce qu'on aurait dû faire nous-même à la main.
Pourquoi c'est intéressant ?
Parce qu'il reproduit ce que vous auriez fait en évitant de trop abstraire les commandes. Alors oui on peut mettre les résultats dans des variables et les exploiter, mais il n'y a pas beaucoup de surcouche par rapport à une commande que l'on doit lancer soi-même.
Et puis, j'aime beaucoup cette logique par état.
Vérifier qu'un service est up, que telle app est installée, etc...
On vérifie un état et on cherche à mettre la machine dans un état voulu.
Cette approche permet d'éviter de refaire en boucle les mêmes commandes quand elles ont déjà été faites. En sachant que certaines d'entre elles peuvent être dévastatrices si on les lance plusieurs fois.
Par exemple le nettoyage et la création d'une base de données.
Bref, plus j'en fais, plus je trouve ça sympa.
Ça fait déjà quelques mois et je déploie déjà des services avec, j'aime beaucoup, j'ai déjà plusieurs repos d'Infrastructure as Code.
Je ne fais que commencer mon périple mais j'apprécie le chemin.

Alexandre P.
Développeur passionné depuis plus de 20 ans, j'ai une appétence particulière pour les défis techniques et changer de technologie ne me fait pas froid aux yeux.
Poursuivre la lecture dans la rubrique Dev