Terraform-provider-aws: No se pudo destruir el nodo de AWS con el volumen: * aws_volume_attachment.jenkins_disk_attachment: Error al esperar que el Volumen (vol-XXXX) se desconecte de la Instancia: i-XXXXX

Creado en 20 oct. 2017  ·  3Comentarios  ·  Fuente: hashicorp/terraform-provider-aws

_Esta edición fue originalmente abierta por @evgeniagusakova como hashicorp / terraform # 16167. Se migró aquí como resultado de la división del proveedor . El cuerpo original del problema se encuentra a continuación.


¡Hola equipo!

Me enfrenté a un problema cuando no puedo destruir la instancia con el volumen creado por terraform

Versión Terraform

bash-4.3$ uname  -s
Darwin
bash-4.3$ terraform version
Terraform v0.10.6



md5-58db0e4bdc67a27c4b9068659851f4f4



data "aws_ebs_volume" "jenkins_disk" {
  most_recent = true

  filter {
    name   = "volume-id"
    values = ["vol-XXXXX"]
  }
}
resource "aws_volume_attachment" "jenkins_disk_attachment" {
  device_name = "/dev/sdx"
  volume_id   = "${data.aws_ebs_volume.jenkins_disk.id}"
  instance_id = "${aws_instance.jenkins_server.id}"
}

resource "aws_instance" "jenkins_server" {
  connection {
    type        = "ssh"
    user        = "${var.instance_user}"
    host        = "${aws_instance.jenkins_server.public_ip}"
    private_key = "${file("${var.jenkins_server_ssh_key_path}")}"
  }
...
}



md5-46cb7666285c5936e8fec21a7d22aef1



terraform  destroy   -var secret_key=<KEY> -var access_key=<KEY>
aws_security_group.jenkins_server_security_group: Refreshing state... (ID: sg-XXXXX)
<other resources here>
data.aws_ebs_volume.jenkins_disk: Refreshing state...
<other resources here>
aws_instance.jenkins_server: Refreshing state... (ID: i-XXXXX)
aws_volume_attachment.jenkins_disk_attachment: Refreshing state... (ID: vai-XXXXX)

An execution plan has been generated and is shown below.
Resource actions are indicated with the following symbols:
  - destroy

Terraform will perform the following actions:
<full and correct list of resources to delete here>
Plan: 0 to add, 0 to change, 12 to destroy.
Do you really want to destroy?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.
  Enter a value: yes

<deleting resource>
aws_volume_attachment.jenkins_disk_attachment: Destroying... (ID: vai-XXXXX)
<deleting resources>
aws_volume_attachment.jenkins_disk_attachment: Still destroying... (ID: vai-XXXXX, 10s elapsed)
aws_volume_attachment.jenkins_disk_attachment: Still destroying... (ID: vai-XXXXX, 20s elapsed)
aws_volume_attachment.jenkins_disk_attachment: Still destroying... (ID: vai-XXXXX, 30s elapsed)
aws_volume_attachment.jenkins_disk_attachment: Still destroying... (ID: vai-XXXXX, 40s elapsed)
Error applying plan:
1 error(s) occurred:
* aws_volume_attachment.jenkins_disk_attachment (destroy): 1 error(s) occurred:
* aws_volume_attachment.jenkins_disk_attachment: Error waiting for Volume (vol-XXXXX) to detach from Instance: i-XXXXX

Salida de depuración

Comportamiento esperado

La instancia se elimina, el volumen se desconecta pero no se elimina.

Comportamiento real

EIP está desconectado
Segundo. Los grupos no se eliminan
La instancia no se elimina
El volumen no está desconectado

Solución alterna

en el nodo:

  1. Detenga todos los procesos usando el punto de montaje del disco ( lsof ayuda a encontrar todos los procesos)
  2. Sincronizar disco y desmontarlo
  3. Desactivar el volumen con la consola de Amazon
  4. Eliminar archivo adjunto del estado terraform state rm aws_volume_attachment.jenkins_disk_attachment
  5. Instancia de destrucción: terraform destroy -var ....

Detalles adicionales

Estoy realmente seguro de que el disco no se desconectó porque estaba montado y en uso. Desde la consola de Amazon, pude desconectarlo solo después de desmontar el disco.

Pero esperaba la desacoplamiento forzado de terraform después de un tiempo de espera (¿configurable?).

Entonces, si este es el comportamiento esperado, supongo que debemos convertir este informe de error en una solicitud de función :)

Referencias

No estoy seguro, pero este problema parece cercano a mi.
Fue con la versión anterior de terraform, así que decidí crear una nueva edición.

bug servicec2

Comentario más útil

Tuve un problema similar al destruir aws_ebs_volume adjunto a la instancia.
Para que una aplicación pueda utilizar el volumen (espacio en disco) en una instancia, se deben realizar los siguientes pasos:

  • crear volumen aws
  • adjuntarlo a una instancia
  • crear un sistema de archivos en ese disco
  • crear una carpeta de punto de montaje
  • agregar punto de montaje a fstab
  • Móntalo
  • empezar a usarlo (normalmente ejecutar una aplicación)

Así que traté de separar un volumen montado de la instancia manualmente y después de un tiempo falló con una nota:
.... /dev/xvdg (busy)
En base a eso, llegué a la conclusión de que terraform no puede eliminar por la fuerza el volumen montado de una instancia. Cual es correcta. Entonces, para separar el volumen, he creado un llamado procedimiento que desmonta el volumen de forma segura antes de separarlo:

  • dejar de usar el volumen (detener la aplicación)
  • desmontarlo
  • eliminar mountpoint de fstab (opcional, si es permanente)
  • eliminar carpeta de montaje (opcional, si es permanente)
  • separarse de la instancia
  • eliminar el volumen de AWS

Que en el código se ve así:

# Commands in variable to create 
# a filesystem and add to fstab
variable "dataCreate" {
  default = [ "echo 'BEGIN: mkfs.ext4 /dev/xvdg'",
              "sudo mkfs.ext4 /dev/xvdg > /dev/null 2>&1 && echo 'END: mkfs.ext4 /dev/xvdg done'",
              "echo 'BEGIN: create /data folder'",
              "sudo mkdir -p /data > /dev/null 2>&1 && echo 'END: create /data folder done'",
              "echo 'BEGIN: Add /dev/xvdg to fstab /data'",
              "sudo sh -c \"echo '/dev/xvdg /data ext4 defaults 1 2' >> /etc/fstab\" && echo 'END: Added /dev/xvdg to fstab /data'",
              "echo 'BEGIN: Mount /dev/xvdg as /data'",
              "sudo mount /bitcoin && echo 'END: Mount /data done'" ]
}
## Variable holding commands to stop application, 
## unmount and remove from fstab
variable "dataUmount" {
  default = [ "echo 'BEGIN: Stop application using /data''",
              "sudo systemctl stop {{APP}} && echo 'END: Application using /data stopped'",
              "echo 'BEGIN: unmount /data'",
              "sudo umount /data && echo 'END: unmount /data done'",
              "echo 'BEGIN: Remove /data from fstab''",
              "sudo sed -i '/data/d' /etc/fstab && echo 'END: Remove /data from fstab'",
              "echo 'BEGIN: Remove /data folder",
              "sudo rm -rfv /data && echo 'END: Added /dev/xvdg to fstab /data'"
            ]
}
## Create a data volume
resource "aws_ebs_volume" "data" {
  availability_zone = "eu-central-1a"
  size = "10"
}
## Attach to instance
resource "aws_volume_attachment" "data_attach" {
  device_name = "/dev/xvdg"
  volume_id   = "${aws_ebs_volume.data.id}"
  instance_id = "${aws_instance.instance.id}"
}

## Configure volume
resource "null_resource" "data_config" {
  depends_on = ["aws_volume_attachment.data_attach", "aws_instance.instance"]

 ## commands to run when creating
  provisioner "remote-exec" {
    connection {
      type = "ssh"
      agent = false
      timeout = "60s"
      host = "${aws_instance.instance.public_ip}"
      user = "ubuntu"
      private_key = "${file(var.privateKey)}"
    }
    inline = ["${var.dataCreate}"]
    }

  ## run unmount commands when destroying the data volume
  provisioner "remote-exec" {
    when = "destroy"
    on_failure = "continue"
    connection {
      type = "ssh"
      agent = false
      timeout = "60s"
      host = "${aws_instance.instance.public_ip}"
      user = "ubuntu"
      private_key = "${file(var.privateKey)}"
    }
    inline = ["${var.dataUmount}"]
  }
}

## Create instance
resource "aws_instance" "instance" {
  depends_on = ["aws_ebs_volume.data"]
  ami = .....
......
}

Entonces la idea es liberar el volumen antes de que se desprenda.
Espero que ayude a alguien.

Todos 3 comentarios

@evgeniagusakova Es posible que desee intentar establecer skip_destroy en verdadero. https://www.terraform.io/docs/providers/aws/r/volume_attachment.html#skip_destroy

1017 valdría la pena echarle un vistazo.

Estoy enfrentando el mismo problema y ayuda establecer skip_destroy

Tuve un problema similar al destruir aws_ebs_volume adjunto a la instancia.
Para que una aplicación pueda utilizar el volumen (espacio en disco) en una instancia, se deben realizar los siguientes pasos:

  • crear volumen aws
  • adjuntarlo a una instancia
  • crear un sistema de archivos en ese disco
  • crear una carpeta de punto de montaje
  • agregar punto de montaje a fstab
  • Móntalo
  • empezar a usarlo (normalmente ejecutar una aplicación)

Así que traté de separar un volumen montado de la instancia manualmente y después de un tiempo falló con una nota:
.... /dev/xvdg (busy)
En base a eso, llegué a la conclusión de que terraform no puede eliminar por la fuerza el volumen montado de una instancia. Cual es correcta. Entonces, para separar el volumen, he creado un llamado procedimiento que desmonta el volumen de forma segura antes de separarlo:

  • dejar de usar el volumen (detener la aplicación)
  • desmontarlo
  • eliminar mountpoint de fstab (opcional, si es permanente)
  • eliminar carpeta de montaje (opcional, si es permanente)
  • separarse de la instancia
  • eliminar el volumen de AWS

Que en el código se ve así:

# Commands in variable to create 
# a filesystem and add to fstab
variable "dataCreate" {
  default = [ "echo 'BEGIN: mkfs.ext4 /dev/xvdg'",
              "sudo mkfs.ext4 /dev/xvdg > /dev/null 2>&1 && echo 'END: mkfs.ext4 /dev/xvdg done'",
              "echo 'BEGIN: create /data folder'",
              "sudo mkdir -p /data > /dev/null 2>&1 && echo 'END: create /data folder done'",
              "echo 'BEGIN: Add /dev/xvdg to fstab /data'",
              "sudo sh -c \"echo '/dev/xvdg /data ext4 defaults 1 2' >> /etc/fstab\" && echo 'END: Added /dev/xvdg to fstab /data'",
              "echo 'BEGIN: Mount /dev/xvdg as /data'",
              "sudo mount /bitcoin && echo 'END: Mount /data done'" ]
}
## Variable holding commands to stop application, 
## unmount and remove from fstab
variable "dataUmount" {
  default = [ "echo 'BEGIN: Stop application using /data''",
              "sudo systemctl stop {{APP}} && echo 'END: Application using /data stopped'",
              "echo 'BEGIN: unmount /data'",
              "sudo umount /data && echo 'END: unmount /data done'",
              "echo 'BEGIN: Remove /data from fstab''",
              "sudo sed -i '/data/d' /etc/fstab && echo 'END: Remove /data from fstab'",
              "echo 'BEGIN: Remove /data folder",
              "sudo rm -rfv /data && echo 'END: Added /dev/xvdg to fstab /data'"
            ]
}
## Create a data volume
resource "aws_ebs_volume" "data" {
  availability_zone = "eu-central-1a"
  size = "10"
}
## Attach to instance
resource "aws_volume_attachment" "data_attach" {
  device_name = "/dev/xvdg"
  volume_id   = "${aws_ebs_volume.data.id}"
  instance_id = "${aws_instance.instance.id}"
}

## Configure volume
resource "null_resource" "data_config" {
  depends_on = ["aws_volume_attachment.data_attach", "aws_instance.instance"]

 ## commands to run when creating
  provisioner "remote-exec" {
    connection {
      type = "ssh"
      agent = false
      timeout = "60s"
      host = "${aws_instance.instance.public_ip}"
      user = "ubuntu"
      private_key = "${file(var.privateKey)}"
    }
    inline = ["${var.dataCreate}"]
    }

  ## run unmount commands when destroying the data volume
  provisioner "remote-exec" {
    when = "destroy"
    on_failure = "continue"
    connection {
      type = "ssh"
      agent = false
      timeout = "60s"
      host = "${aws_instance.instance.public_ip}"
      user = "ubuntu"
      private_key = "${file(var.privateKey)}"
    }
    inline = ["${var.dataUmount}"]
  }
}

## Create instance
resource "aws_instance" "instance" {
  depends_on = ["aws_ebs_volume.data"]
  ami = .....
......
}

Entonces la idea es liberar el volumen antes de que se desprenda.
Espero que ayude a alguien.

¿Fue útil esta página
0 / 5 - 0 calificaciones