_Ce numéro a été initialement ouvert par @evgeniagusakova en tant que hashicorp / terraform # 16167. Il a été migré ici en raison de la scission des fournisseurs . Le corps d'origine du numéro est ci-dessous._
Bonjour l'équipe!
J'ai rencontré un problème lorsque je ne suis pas en mesure de détruire une instance avec un volume créé par 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
L'instance est supprimée, le volume est détaché mais pas supprimé.
EIP est détaché
Seconde. Les groupes ne sont pas supprimés
L'instance n'est pas supprimée
Le volume n'est pas supprimé
sur le nœud:
lsof
aide à trouver tous les processus)terraform state rm aws_volume_attachment.jenkins_disk_attachment
terraform destroy -var ....
Je suis vraiment sûr que ce disque n'a pas été détaché car il était monté et en cours d'utilisation. Depuis Amazon Console, je n'ai pu le détacher qu'après avoir démonté le disque.
Mais je m'attendais à un détachement forcé de terraform après un certain délai (configurable?).
Donc, si c'est un comportement attendu, je suppose que nous devons convertir ce rapport de bogue en demande de fonctionnalité :)
Je ne sais pas mais ce problème me ressemble.
C'était avec l'ancienne version de terraform, j'ai donc décidé de créer un nouveau problème.
@evgeniagusakova Vous voudrez peut-être essayer de définir skip_destroy
sur true. https://www.terraform.io/docs/providers/aws/r/volume_attachment.html#skip_destroy
Je suis confronté au même problème et il est utile de définir skip_destroy
J'ai eu un problème similaire avec la destruction de aws_ebs_volume attaché à l'instance.
Pour qu'une application puisse utiliser le volume (espace disque) sur l'instance, les étapes suivantes doivent être effectuées:
J'ai donc essayé de détacher manuellement un volume monté de l'instance et après un certain temps, il a échoué avec une note:
.... /dev/xvdg (busy)
Sur cette base, je suis arrivé à la conclusion que terraform ne peut pas supprimer de force le volume monté d'une instance. Qui est correct. Donc, afin de détacher le volume, j'ai créé une soi-disant procédure qui démonte le volume en toute sécurité avant de le détacher:
Ce qui dans le code ressemble à ceci:
# 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 = .....
......
}
L'idée est donc de libérer le volume avant qu'il ne se détache.
J'espère que ça aide quelqu'un.
Commentaire le plus utile
J'ai eu un problème similaire avec la destruction de aws_ebs_volume attaché à l'instance.
Pour qu'une application puisse utiliser le volume (espace disque) sur l'instance, les étapes suivantes doivent être effectuées:
J'ai donc essayé de détacher manuellement un volume monté de l'instance et après un certain temps, il a échoué avec une note:
.... /dev/xvdg (busy)
Sur cette base, je suis arrivé à la conclusion que terraform ne peut pas supprimer de force le volume monté d'une instance. Qui est correct. Donc, afin de détacher le volume, j'ai créé une soi-disant procédure qui démonte le volume en toute sécurité avant de le détacher:
Ce qui dans le code ressemble à ceci:
L'idée est donc de libérer le volume avant qu'il ne se détache.
J'espère que ça aide quelqu'un.