Une PME a migré son application métier vers un fournisseur cloud il y a dix-huit mois. Chaque besoin nouveau a été traité au fil de l'eau, en se connectant à la console d'administration et en cliquant. Aujourd'hui, personne ne peut dire avec certitude combien de machines tournent, laquelle sert encore à quelque chose, ni pourquoi une règle de pare-feu autorise l'accès à une base de données depuis n'importe quelle adresse. Une machine créée pour une démonstration facture toujours, faute d'étiquette permettant de l'identifier. Rien n'est en panne, mais l'infrastructure n'est plus décrite nulle part, sinon dans la mémoire de la personne qui a cliqué.
C'est le problème que résolvent Terraform et Ansible. Le premier relève de l'infrastructure décrite sous forme de code, c'est-à-dire l'écriture dans des fichiers texte de tout ce qui compose votre environnement, afin qu'il puisse être relu, revu et recréé. Le second relève de la gestion de configuration, c'est-à-dire la définition de l'état attendu à l'intérieur d'une machine : paquets installés, utilisateurs, services, réglages. Nous mettons ces outils en place dans nos missions d'expertise cloud à 1000 HT / jour, à distance dans toute la France et en Suisse, lorsqu'il existe quelque chose à reproduire.
Deux outils, deux métiers distincts
Terraform lit vos fichiers de description, les compare à ce qui existe réellement chez le fournisseur, puis affiche un plan avant d'agir. Ce plan est le point important pour un dirigeant : il liste ce qui sera créé, modifié ou supprimé, et il se fait relire avant exécution. Terraform conserve par ailleurs un fichier d'état qui mémorise la correspondance entre vos descriptions et les ressources réelles. Ce fichier doit être stocké dans un emplacement partagé et verrouillé, faute de quoi deux personnes travaillant en parallèle produisent des résultats contradictoires.
Ansible intervient une fois la machine créée. Il se connecte en SSH, sans installer d'agent permanent, et applique une liste de tâches décrivant l'état voulu : cette version de PHP est installée, ce compte utilisateur existe avec cette clé, ce service est démarré, cet agent de supervision est configuré. Ces tâches sont conçues pour être idempotentes, c'est-à-dire qu'elles produisent le même résultat qu'on les exécute une fois ou dix fois, ce qui permet de les relancer sans crainte sur un parc entier.
La séparation est simple à retenir : Terraform décide de ce qui existe, Ansible décide de ce qu'il y a dedans. Beaucoup d'installations bancales viennent d'une confusion entre les deux, par exemple lorsque Terraform déclenche à la création de la machine un long script d'installation qu'il ne saura jamais rejouer ni corriger ensuite.
Ce que votre entreprise y gagne, au-delà de l'argument technique
Le premier gain est la fin de la dépendance à une personne. Quand l'infrastructure est écrite, elle se lit, se transmet et se reprend par un autre prestataire ou par un salarié qui arrive. Les fichiers vivent dans un dépôt Git qui appartient à votre société, ce qui constitue en pratique le plan de votre système d'information.
Le deuxième gain est la traçabilité. Chaque modification passe par une proposition relue, avec son auteur, sa date et son motif. En cas d'incident, vous savez ce qui a changé la veille, ce qui raccourcit considérablement le diagnostic. Le troisième gain porte sur la facture : lorsque les étiquettes de projet et d'environnement sont écrites dans le code, elles ne sont plus oubliées, et la répartition des coûts devient exploitable, comme nous l'expliquons dans notre article sur la facture cloud qui augmente.
Le quatrième gain est la capacité de reconstruction. Recréer un environnement complet devient une opération planifiée de quelques heures et non un chantier de plusieurs semaines. Cela sert à préparer une reprise après un incident majeur, à monter un environnement de recette identique à la production, ou à changer de région d'hébergement.
Ce que l'infrastructure décrite sous forme de code ne règle pas
Ces outils ne dispensent d'aucune discipline, et nous préférons le dire avant la mission plutôt qu'après.
- Si les modifications continuent d'être faites à la main dans la console en parallèle du code, l'écart entre les deux se creuse et la description perd toute valeur. La règle doit être explicite : la console sert à consulter et à diagnostiquer, le code sert à modifier.
- Un fichier d'état Terraform mal protégé devient un point de fragilité, car il contient la cartographie de votre infrastructure et parfois des valeurs sensibles. Il se stocke dans un emplacement chiffré, versionné et à accès restreint.
- Le code d'infrastructure n'est pas une sauvegarde. Il recrée des serveurs vides, pas vos données. Les deux dispositifs sont complémentaires et aucun ne remplace l'autre.
- L'automatisation reproduit fidèlement une erreur de conception, et elle la reproduit sur tous les environnements à la fois. La revue par un pair avant application n'est pas une formalité.
Il faut aussi que quelqu'un maintienne ce code. Les fournisseurs et les modules évoluent, et un dépôt laissé sans mise à jour pendant deux ans finit par ne plus s'exécuter le jour où vous en avez besoin.
Quand ces outils sont disproportionnés pour votre situation
Automatiser une infrastructure qui ne se répète pas coûte plus cher que le geste manuel qu'elle remplace. Pour une machine virtuelle isolée qui rend un service stable, une documentation d'installation à jour suffit largement.
De la même manière, un parc de dix ou vingt postes Windows ne relève pas de ces outils. Les correctifs, l'antivirus avec supervision, la prise en main à distance et la gestion des comptes se traitent dans un contrat d'infogérance à partir de 120 HT / mois, avec des interventions sur site dans le Bassin Genevois. Terraform et Ansible se justifient sur les environnements cloud et sur les serveurs Linux que vous devez pouvoir reconstruire, pas sur la bureautique quotidienne. Là encore, le principe est de retenir l'outil le plus simple qui couvre le besoin et que vos équipes sauront exploiter.
Notre méthode pour passer d'une console cliquée à une infrastructure écrite
Nous commençons par un inventaire de l'existant, ressource par ressource, avec l'identification de ce qui sert et de ce qui ne sert plus. Cette étape produit souvent les premières économies, avant même la moindre ligne de code. Nous vérifions au passage la gouvernance du compte, sujet que nous traitons dans notre article sur le compte racine d'un fournisseur cloud, car automatiser un environnement dont la propriété est floue revient à consolider un problème.
Nous décrivons ensuite le socle avec Terraform : réseau, droits d'accès, stockage, règles de filtrage, étiquetage. Nous importons l'existant plutôt que de tout recréer, ce qui évite toute interruption pendant la reprise. Nous passons ensuite à Ansible pour la configuration interne des serveurs, en commençant par ce qui est répétitif et à risque, comme les comptes d'administration, les correctifs de sécurité et l'agent de supervision décrit dans notre article sur la supervision avec Zabbix.
Nous terminons par la mise en place d'une procédure de modification et par la formation de vos interlocuteurs, afin que le dépôt reste vivant après notre départ. Sur les environnements que nous administrons ensuite, notamment côté expertise AWS, cette base rend chaque intervention plus rapide et beaucoup plus sûre.
Si votre infrastructure cloud n'est décrite que dans la mémoire d'une personne, parlons de vos fondations. Nous commençons toujours par écrire ce qui existe, et l'automatisation vient seulement ensuite.