Terraform-provider-local: Ajout de la possibilité de conserver local_file lors de la destruction

Créé le 5 janv. 2018 · 8Commentaires · Source: hashicorp/terraform-provider-local

_Ce problème a été initialement ouvert par @alanbchristie sous le nom hashicorp/terraform#17040. Il a été migré ici à la suite de la scission du fournisseur . Le corps original du problème est ci-dessous._

Serait-il possible d'ajouter un argument do_not_destroy à l'élément de configuration local_file sorte que lorsque terraform destroy est exécuté, le fichier local généré reste intact ? La raison? Je crée du contenu dynamique pour un script Ansible post-destruction et il serait utile de conserver le contenu du fichier généré localement pour ce playbook.

c'est-à-dire serait-il acceptable de fournir la possibilité de le faire...

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
  do_not_destroy = true
}

Avec ce qui précède, si terraform apply est ré-exécuté, il est parfaitement correct (et attendu) d'écraser tout fichier existant.

Version Terraform

Terraform v0.11.1

Fichiers de configuration Terraform

data "template_file" "cleanup_vars" {
  template = "${file("../../../ansible/aws-cleanup/vars.yml.tpl")}"

  vars {
    aws_region = "${var.aws_region}"
  }
}

resource "local_file" "cleanup_vars" {
  content = "${data.template_file.cleanup_vars.rendered}"
  filename = "../../../ansible/aws-cleanup/vars.yml"
}

Sortie de débogage

n / A

Sortie de plantage

n / A

Comportement prévisible

n / A

Comportement réel

n / A

Étapes à suivre pour reproduire

n / A

Contexte supplémentaire

n / A

Les références

n / A

enhancement

Source

hashibot

👍5

Commentaire le plus utile

Salut @alanbchristie ! Merci pour cette demande de fonctionnalité et désolé pour le retard à y répondre.

L'équipe Terraform de HashiCorp ne sera pas en mesure de travailler là-dessus dans un avenir proche car nous nous concentrons ailleurs, mais nous serions heureux d'examiner une demande d'extraction si vous ou quelqu'un d'autre avez le temps et la motivation pour l'implémenter.

Il existe un précédent pour des options comme celle-ci pour les ressources où il est courant d'utiliser Terraform pour les créer mais de passer la gestion à un autre système après un certain temps. Habituellement, ceux-ci ont des noms comme verb_on_destroy , où "verbe" est une terminologie appropriée pour la ressource en question. Pour cette situation, je suggérerais de nommer l'argument delete_on_destroy , en lui donnant par défaut true , puis en ayant la configuration explicite delete_on_destroy = false . Ceci est cohérent avec d'autres fonctionnalités existantes similaires comme l'argument nomad_job deregister_on_destroy .

(La raison de la terminologie *_on_destroy ici est que "détruire" dans ce contexte est l'opération de Terraform, qui à son tour provoque d'autres opérations dans le système cible. L'appeler do_not_destroy pourrait être déroutant depuis sa définition n'empêchera pas Terraform de détruire l'instance de ressource elle-même. Au lieu de cela, il ajuste les actions que Terraform entreprend _lorsqu'il détruit l'instance de ressource.)

apparentlymart le 20 févr. 2018

👍3

Tous les 8 commentaires

Salut @alanbchristie ! Merci pour cette demande de fonctionnalité et désolé pour le retard à y répondre.

apparentlymart le 20 févr. 2018

👍3

@apparentlymart J'ai tenté une résolution au n ° 10, heureux de recevoir des commentaires.

abn le 31 mars 2018

Bonjour,
Même cas d'utilisation et même problème que @alanbchristie. une mise à jour concernant ce ticket ? Merci d'avance.

MOURIK le 9 avr. 2020

Merci pour votre patience @abn pendant que nous améliorons notre processus de triage pour les fournisseurs HashiCorp. J'aimerais en savoir plus sur votre cas d'utilisation ici : puisque vous appelez terraform destroy mais que vous souhaitez conserver cette ressource, elle doit faire partie d'une configuration plus large avec des types de ressources supplémentaires que vous souhaitez détruire. Pourriez-vous décrire les étapes de ce processus et comment la configuration est utilisée ?

kmoe le 7 août 2020

@kmoe Pour être honnête, ma mémoire du cas d'utilisation d'origine est un peu médiocre. Mais, comme le dit la description, le cas particulier qui a conduit à cela était depuis que nous avons créé quelques ressources sur AWS qui ont généré des jetons et/ou des configurations qui devaient être utilisées pour nettoyer les ressources qui ont été créées après l'application en dehors de tf state, qui devait être nettoyé à l'aide d'un playbook ansible après l'appel de destroy. La simple exigence est de pouvoir ne pas supprimer un fichier généré ; il existe divers autres cas où cela sera utile en général.

abn le 7 août 2020

pareil ici

HaveFun83 le 7 juin 2021

toujours le même nécessaire ici

crazychatting le 26 oct. 2021

J'aimerais dire que je suis toujours intéressé par ce problème, mais je ne le suis pas. Au lieu de cela, comme indiqué au début du problème, j'utilise Ansible comme contrôleur, donc je copie simplement le fichier hors de la portée de Terraform une fois l'infrastructure provisionnée. Ensuite, après avoir appelé destroy, lorsque le contrôle revient à mon playbook Ansible, j'ai le fichier avant sa suppression et je peux effectuer le traitement requis.

En ce qui concerne la question précédente en 2020, pourquoi quelqu'un voudrait-il conserver un tel fichier ? Contrairement à d'autres ressources, le fait qu'il s'agisse d'une ressource "locale" devrait indiquer qu'elle ne joue généralement pas un rôle crucial dans l'infrastructure ... elle est "locale" après tout (et serait réécrite de toute façon lorsque vous exécutez apply ). Et, peut-être que le fait que trois autres personnes pensent également que c'est une bonne idée pourrait également indiquer que, peut-être, c'est le cas ?

Quoi qu'il en soit, il a été plus productif pour moi de coder autour du comportement à l'aide d'un outil externe.