D'un point de vue purement théorique sur la manière dont fonctionne terraform, il a un gros avantage par rapport a Ansible, Chef ou Puppet : il stocke son état courant.
En pratique ça veut dire que lorsqu'on enlève une ressource du fichier terraform, au prochain lancement, il va se souvenir que la ressource existait, quelle n'existe plus, et il tentera de la supprimer. Dans les faits, ça lui permet d'être toujours au plus proche de son état.
Des outils de gestion de conf classique, en cas de suppression d'une ressource dans les sources, ne vont pas la supprimer. Elle restera là sur les serveurs. Ce qui je trouve peut poser problème. Imagine que ce soit un serveur avec une faille de sécurité... En pratique, la solution est d'indiquer la ressource mais avec une booléen pour dire qu'elle doit être absente. Pas très propre je trouve.
En constatant cela, j'ai immédiatement pensé a comment faire pour utiliser terraform a la place de puppet, chef ou ansible. En pratique, c'est pas faisable ... dans terraform on ne gère pas des fichiers, des services ou d'autres objets existant sur la machine où on exécute terraform. Ce que fait terraform c'est gérer des ressources distantes par API Web.
Mais en pratique, terraform permet l'écriture de plugins. En théorie rien n'empêche donc d'écrire un plugin qui au lieu de discuter avec une API Web, discutera avec une API d'appel systèmes pour provisionner une machine réelle et pas dans le cloud.
Après, en pratique, je n'ai pas tenté cette voie parce que terraform n'est vraiment pas fait pour ça, et rien ne dit que ça marchera pour tout faire. Et il n'y aura aucune volonté de merger du code sur ces fonctionnalités upstream. Ce serait un gros hack en quelque sorte. mais si vous avez du temps a faire, ça peut être un truc cool :)
Sachant qu'il existe un outil : mgmt (déjà discuté plus haut), tout neuf, écrit par un gars de Red Hat qui pourrait remplir ce rôle parfaitement.
# Plugins
Posté par Mildred (site web personnel) . En réponse à la dépêche Sortie de Terraform 0.9. Évalué à 3.
D'un point de vue purement théorique sur la manière dont fonctionne terraform, il a un gros avantage par rapport a Ansible, Chef ou Puppet : il stocke son état courant.
En pratique ça veut dire que lorsqu'on enlève une ressource du fichier terraform, au prochain lancement, il va se souvenir que la ressource existait, quelle n'existe plus, et il tentera de la supprimer. Dans les faits, ça lui permet d'être toujours au plus proche de son état.
Des outils de gestion de conf classique, en cas de suppression d'une ressource dans les sources, ne vont pas la supprimer. Elle restera là sur les serveurs. Ce qui je trouve peut poser problème. Imagine que ce soit un serveur avec une faille de sécurité... En pratique, la solution est d'indiquer la ressource mais avec une booléen pour dire qu'elle doit être absente. Pas très propre je trouve.
En constatant cela, j'ai immédiatement pensé a comment faire pour utiliser terraform a la place de puppet, chef ou ansible. En pratique, c'est pas faisable ... dans terraform on ne gère pas des fichiers, des services ou d'autres objets existant sur la machine où on exécute terraform. Ce que fait terraform c'est gérer des ressources distantes par API Web.
Mais en pratique, terraform permet l'écriture de plugins. En théorie rien n'empêche donc d'écrire un plugin qui au lieu de discuter avec une API Web, discutera avec une API d'appel systèmes pour provisionner une machine réelle et pas dans le cloud.
Après, en pratique, je n'ai pas tenté cette voie parce que terraform n'est vraiment pas fait pour ça, et rien ne dit que ça marchera pour tout faire. Et il n'y aura aucune volonté de merger du code sur ces fonctionnalités upstream. Ce serait un gros hack en quelque sorte. mais si vous avez du temps a faire, ça peut être un truc cool :)
Sachant qu'il existe un outil : mgmt (déjà discuté plus haut), tout neuf, écrit par un gars de Red Hat qui pourrait remplir ce rôle parfaitement.