cc_staff
44
edits
Terraform: Difference between revisions
Jump to navigation
Jump to search
→Add a volume
| Line 463: | Line 463: | ||
== Add a volume == | == Add a volume == | ||
Next, add a root volume to the VM. Since this will replace its boot disk, ''this is a destructive operation''. This is something you need to watch out for in Terraform, and one of the chief reasons for reading your plans carefully before applying. It’s unlikely you’re going to accidentally cause critical issues in creating new resources, but it can be deceptively easy to accidentally create configuration changes that require ''rebuilding'' existing VMs. | |||
Since this is a root volume, create it as part of the compute instance, as another subblock along with the network subblock: | |||
Since this is a root volume, | |||
<source lang="terraform"> block_device { | <source lang="terraform"> block_device { | ||
| Line 479: | Line 475: | ||
delete_on_termination = true | delete_on_termination = true | ||
}</source> | }</source> | ||
Set the <code>uuid</code> attribute to the UUID of the image you want to use and remove <code>image_id</code> from the outer block definition. The other attributes are self-explanatory, except for <code>destination_type</code>, which is here set to <code>volume</code> to indicate this is to be stored with an OpenStack-provided volume rather than using disk on the hypervisor. <code>delete_on_termination</code> is important—for testing, you will probably want this to be <code>true</code> so you don’t have to remember to constantly clean up leftover volumes, but for real use you should consider setting it to <code>false</code> as a last defence against accidental deletion of resources. | |||
<blockquote>Do ''not'' leave the <code>image_id</code> attribute defined in the outer compute instance definition! This will work, but Terraform will see a change from “boot from volume” to “boot directly from image” on every run, and so will always attempt to rebuild your instance. (This is probably a flaw in the OpenStack provider.) | <blockquote>Do ''not'' leave the <code>image_id</code> attribute defined in the outer compute instance definition! This will work, but Terraform will see a change from “boot from volume” to “boot directly from image” on every run, and so will always attempt to rebuild your instance. (This is probably a flaw in the OpenStack provider.) | ||
| Line 535: | Line 531: | ||
+ floating_ip = (known after apply) | + floating_ip = (known after apply) | ||
~ mac = "fa:16:3e:3b:79:27" -> (known after apply) | ~ mac = "fa:16:3e:3b:79:27" -> (known after apply) | ||
name = " | name = "tenant-net" | ||
+ port = (known after apply) | + port = (known after apply) | ||
~ uuid = "5c96bf54-a396-47c5-ab12-574f630bcb80" -> (known | ~ uuid = "5c96bf54-a396-47c5-ab12-574f630bcb80" -> (known | ||
| Line 541: | Line 537: | ||
} | } | ||
}</source> | }</source> | ||
So note there are several warnings of what’s going to be replaced and what’s going to change, not to mention this | So note there are several warnings of what’s going to be replaced and what’s going to change, not to mention this line: | ||
<source lang="shell">Plan: 2 to add, 0 to change, 2 to destroy.</source> | <source lang="shell">Plan: 2 to add, 0 to change, 2 to destroy.</source> | ||
Your VM will be created with a new SSH key, so if you connected previously you'll need to remove the SSH key from your <code>known_hosts</code> file (or the equivalent). After this, the first thing to do is log on and ''apply all available updates''. | |||
<source lang="shell">[centos@myvm ~]$ sudo yum update -y | <source lang="shell">[centos@myvm ~]$ sudo yum update -y | ||
... | ... | ||
[ goes for ages ]</source> | [ goes for ages ]</source> | ||
So | So you now have a working, Terraformed VM and a way to get to it and a place on it to store data once we get there, with the latest OS patches applied. | ||
== The full example == | == The full example == | ||