Terraform-provider-local: Agregue la capacidad de preservar local_file al destruir

Creado en 5 ene. 2018 · 8Comentarios · Fuente: hashicorp/terraform-provider-local

_Este problema lo abrió originalmente @alanbchristie como hashicorp/terraform#17040. Se migró aquí como resultado de la división del proveedor . El cuerpo original del problema se encuentra a continuación._

¿Sería posible agregar un argumento $# do_not_destroy local_file para que cuando se ejecute terraform destroy , el archivo local generado quede intacto? ¿La razón? Creo contenido dinámico para un script de Ansible posterior a la destrucción y sería útil mantener el contenido del archivo generado localmente para este libro de jugadas.

es decir, ¿sería aceptable proporcionar la capacidad de hacer esto...

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

Con lo anterior, si terraform apply se vuelve a ejecutar, está perfectamente bien (y se espera) sobrescribir cualquier archivo existente.

Versión Terraform

Terraform v0.11.1

Archivos de configuración de 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"
}

Salida de depuración

n / A

Salida de choque

n / A

Comportamiento esperado

n / A

Comportamiento real

n / A

Pasos para reproducir

n / A

Contexto adicional

n / A

Referencias

n / A

enhancement

Fuente

hashibot

👍5

Comentario más útil

¡Hola @alanbchristie! Gracias por esta solicitud de función y disculpe la demora en responder.

El equipo de Terraform en HashiCorp no podrá trabajar en esto en un futuro cercano debido a que nuestro enfoque está en otra parte, pero estaremos encantados de revisar una solicitud de incorporación de cambios si usted u otra persona tiene el tiempo y la motivación para implementarla.

Hay algún precedente para opciones como esta para recursos donde es común usar Terraform para crearlos pero pasar la administración a otro sistema después de un tiempo. Por lo general, estos tienen nombres como verb_on_destroy , donde "verbo" es una terminología adecuada para el recurso en cuestión. Para esta situación, sugeriría nombrar el argumento delete_on_destroy , tenerlo predeterminado en true , y luego tener la configuración explícita en delete_on_destroy = false . Esto es consistente con otras características existentes similares como el argumento nomad_job deregister_on_destroy .

(La razón de la terminología *_on_destroy aquí es que "destruir" en este contexto es la operación de Terraform, que a su vez provoca otras operaciones en el sistema de destino. Llamarlo do_not_destroy podría ser confuso ya que se configuró en realidad, no evitará que Terraform destruya la instancia de recurso en sí. En cambio, ajusta las acciones que Terraform toma _cuando_ destruye la instancia de recurso).

apparentlymart en 20 feb. 2018

👍3

Todos 8 comentarios

¡Hola @alanbchristie! Gracias por esta solicitud de función y disculpe la demora en responder.

apparentlymart en 20 feb. 2018

👍3

@apparentlymart He intentado una resolución en el n. ° 10, feliz de recibir cualquier comentario.

abn en 31 mar. 2018

Hola,
Mismo caso de uso y mismo problema que @alanbchristie. ¿Alguna actualización sobre este boleto? Gracias por adelantado.

MOURIK en 9 abr. 2020

Gracias por su paciencia @abn mientras mejoramos nuestro proceso de clasificación para los proveedores de HashiCorp. Me gustaría entender más sobre su caso de uso aquí: dado que está llamando a terraform destroy pero quiere conservar este recurso, debe ser parte de una configuración más grande con tipos adicionales de recursos que desea destruir. ¿Podría resumir los pasos de este proceso y cómo se usa la configuración?

kmoe en 7 ago. 2020

@kmoe Para ser honesto, mi memoria del caso de uso original es un poco de mala calidad. Pero, como dice la descripción, el caso particular que condujo a esto fue que creamos algunos recursos en AWS que generaron tokens y/o configuraciones que debían usarse para limpiar los recursos que se crearon después de la aplicación fuera de tf state, que debía limpiarse con un libro de jugadas ansible después de llamar a destroy. El requisito simple es poder no eliminar un archivo generado; hay varios otros casos en los que esto será útil en general.

abn en 7 ago. 2020

aquí igual

HaveFun83 en 7 jun. 2021

Todavía se necesita lo mismo aquí

crazychatting en 26 oct. 2021

Me encantaría decir que todavía estoy interesado en este problema, pero no es así. En su lugar, como se indica al comienzo del problema, utilizo Ansible como controlador, así que solo copio el archivo fuera del camino de Terraform una vez que se aprovisiona la infraestructura. Luego, después de llamar a destroy, cuando el control vuelve a mi libro de jugadas de Ansible, tengo el archivo antes de su eliminación y puedo realizar el procesamiento requerido.

Con respecto a la pregunta anterior en 2020, ¿por qué alguien querría mantener un archivo de este tipo? A diferencia de otros recursos, el hecho de que sea un recurso "local" debería indicar que normalmente no juega un papel crucial dentro de la infraestructura... después de todo, es "local" (y se reescribirá de todos modos cuando ejecute apply ). Y, tal vez el hecho de que otros tres también piensen que esta es una buena idea también podría indicar que, tal vez, ¿lo es?

De todos modos, ha sido más productivo para mí codificar el comportamiento usando una herramienta externa.