Terraform: Difference between revisions

Jump to navigation Jump to search
850 bytes removed ,  5 years ago
Line 361: Line 361:
Floating IPs are not created directly on a VM in OpenStack: they are allocated to the project from a pool and associated with the VM’s private network interface.
Floating IPs are not created directly on a VM in OpenStack: they are allocated to the project from a pool and associated with the VM’s private network interface.


Assuming we do not already have a floating IP allocated for this use, we declare a desired floating IP resource like the following example. The only thing we need is to know the pool from which to allocate the floating IP; in Compute Canada clouds this is the external network.
Assuming you do not already have a floating IP allocated for this use, declare a desired floating IP resource like the following example. The only thing you need is to know the pool from which to allocate the floating IP; in Compute Canada clouds this is the external network (<code>ext_net</code> in this example).


<source lang="terraform">resource "openstack_networking_floatingip_v2" "myvm_fip" {
<source lang="terraform">resource "openstack_networking_floatingip_v2" "myvm_fip" {
   pool = "provider-199-2"
   pool = "ext_net"
}</source>
}</source>
I can add this right away and either apply it or just use <code>terraform plan</code> to show what would happen. I’m going to apply it to demonstrate something about Terraform.
You may either apply this change immediately or just use <code>terraform plan</code> to show what would happen.


<source lang="shell">$ terraform apply
<source lang="shell">$ terraform apply
Line 403: Line 403:


Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source>
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source>
Yay. So now I have a floating IP allocate&mdash;but I haven’t associated it to anything, is it just sort of dangling there? No, it’s allocated to the project now, and Terraform knows about it, so when we add the next piece, even though we aren’t creating either resource, we are creating an association between the compute instance and floating IP.
This floating IP is now ''allocated'' but not yet associated with your VM. Add the following definition:
 
That looks like the following. We’re introducing something new here:


<source lang="terraform">resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
<source lang="terraform">resource "openstack_compute_floatingip_associate_v2" "myvm_fip" {
Line 411: Line 409:
   instance_id = openstack_compute_instance_v2.myvm.id
   instance_id = openstack_compute_instance_v2.myvm.id
}</source>
}</source>
This new resource defines as its attributes references to other resources and their attributes.
This new resource defines as its attributes references to other resources and their attributes.


<blockquote>If you’ve been looking at the OpenStack provider documentation, you may have noted the syntax differs from what I’m presenting here, because Terraform version 0.12 as mentioned does not require string interpolation for all use of variables.
<blockquote>'''Note''': Current documentation of the OpenStack provider documentation uses syntax which differs from what is presented here as it has not yet been updated for changes to Terraform v.12.
</blockquote>
</blockquote>
References like this are typically <code>&lt;resource type&gt;.&lt;resource name&gt;.&lt;attribute&gt;</code>. Others you may soon see include <code>var.&lt;variable name&gt;</code>. But this is hopefully pretty clear: this resource forms an association between the VM we created earlier, and the floating IP we allocated in the next step.
References like this are typically <code>&lt;resource type&gt;.&lt;resource name&gt;.&lt;attribute&gt;</code>. Others you may soon see include <code>var.&lt;variable name&gt;</code>. At any rate, this resource forms an association between the created earlier, and the floating IP allocated in the next step.


<source lang="shell">$ terraform apply
<source lang="shell">$ terraform apply
Line 450: Line 449:


Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source>
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.</source>
I replaced the actual IP with letters because ''I remember the '''ABCs of hacking.''''' (I’ll probably inadvertently include it somewhere else.)
So, here’s what I created:


<source lang="yaml">- Flavor: p1-3gb
Note that it has an associated floating IP, you could probably SSH into the new VM right now.
  ID: 1f7f73ff-b9b5-40ad-9ddf-d848efe13e42
  Image: CentOS-7-x64-2018-05
  Name: myvm
  Networks: dleske-tenant-net=192.168.2.11, X.Y.Z.W
  Status: ACTIVE</source>
Note that it has an associated floating IP and I could probably SSH into that bad boy right now.


<source lang="shell">$ ssh centos@X.Y.Z.W hostname
<source lang="shell">$ ssh centos@X.Y.Z.W hostname
Line 468: Line 458:
Warning: Permanently added 'X.Y.Z.W' (ECDSA) to the list of known hosts.
Warning: Permanently added 'X.Y.Z.W' (ECDSA) to the list of known hosts.
myvm.novalocal</source>
myvm.novalocal</source>
Boop.


As mentioned before though it’s undesirable to create a persistent instance without a root volume, so let’s do that next.
If not, it may be necessary to add your workstation's IP address to the project's default security group.


== Add a volume ==
== Add a volume ==
cc_staff
44

edits

Navigation menu