Now that all of the required supporting components have been configured, it is time to add an instance to the configuration and put everything together. This example adds a "leader" instance that we can eventually use to control a set of "follower" instances, but on this page we are just treating it as a stand-alone instance. To get started, download the file leader.tf into your configuration directory.

Configuring an Instance

The first resource in the file, of type openstack_compute_instance_v2, defines the instance we would like to have:

resource "openstack_compute_instance_v2" "leader" {
  name            = "terratest_leader"
  image_id        = var.image_id
  flavor_name     = var.leader_flavor
  key_pair        = openstack_compute_keypair_v2.this.name
  security_groups = [openstack_networking_secgroup_v2.ssh_ping.name]

  network {
    name = openstack_networking_network_v2.private.name
  }
}

A few observations about this resource:

• To set argument "image_id" we use variable "image_id". This variable has no default value, but in terratest.tfvars it is set to the ID of the "featured" Ubuntu 22 image at all Jetstream2 locations (available as of this writing). To use a different image, find the image (and version) you want using the Horizon web interface and copy its ID into terratest.tfvars.
• The "key_pair" argument is set from the "name" attribute of the key pair resource in our configuration. It could just as easily be set from the variable "keypair_name" that was used to specify that name in the first place.
• "security_groups" is the first example we've seen of an array argument that holds one or more values, separated by commas. You need to supply the enclosing brackets even if you only have one security group.
• You may notice that many of the component references in this block use the component's name property, not its ID property. The name property corresponds to the "Jetstream" name of the component, so you can see that it is important to avoid duplicates when choosing your components' Jetstream2 names.

Configuring Floating IP Addresses

The second and third resources specify that a floating internet protocol (IP) address should be allocated and then associated with the instance we are creating.

resource "openstack_networking_floatingip_v2" "leader" {
  pool = "public"
}

# NOTE: This resource type is deprecated, but openstack_networking_floatingip_assocate v2 may not work yet
resource "openstack_compute_floatingip_associate_v2" "leader" {
  floating_ip = openstack_networking_floatingip_v2.leader.address
  instance_id = openstack_compute_instance_v2.leader.id
}

A few observations about these resources:

• Our example configuration contains all of the components that we want in our deployment. If we tear down that deployment, our floating IP address will be return to Jetstream's pool. It is very likely that when we later redeploy the configuration, it will be allocated a different floating IP address, which may not be desirable. You may want to allocate some floating IP addresses by hand, outside of your Terraform configuration, and specify them explicitly in your configuration. This would allow you to maintain the same IP addresses for important components across a series of redeployments.
• In a similar way, you may want to create configurations for your infrastructure (like security groups, key pairs and networks) that are separate from your deployments of instances. This would allow multiple instance configurations to share the same infrastructure, which needn't be torn down every time a set of instances are destroyed. However, this approach may require you to explicitly state your infrastructure names in multiple configurations.
• At this writing, the OpenStack provider implementation of the "network" floating IP association resource did not seem to be functioning correctly. So, we use the "computer" version of that resource, which does work, but which has been designated as deprecated, and thus may be removed from the provider in the future.

Output Variables

The last block of code in this file is of a new type: output. These blocks define output variables that will be exported (and printed) by Terraform after it finishes deploying a configuration. They have the form: output NAME { value = REFERENCE }.

output "leader_floatingip" {
  value = openstack_compute_floatingip_associate_v2.leader.floating_ip
}

Let's deploy the updated configuration with terraform apply -var-file=terratest.tfvars. If you ran the "destroy" test on the previous page, this will take longer than previous deployments. Occasionally, Terraform may encounter errors if some of your components are not fully initialized as expected. In these cases, just reissue your terraform apply command, which will hopefully be able to complete the deployment.

When Terraform successfully completes, it will print the values of all outputs that were defined. In our case, that is the very useful floating IP address of our new instance. Terraform also stores "output" values in its state and it will provide them to you with a command like terraform output leader_floatingip (where the command's argument is the name of the output variable you want.

Wait a minute or two for your instance to fully boot up, then try to log into it using the displayed IP address, your private key and the default username for your image type (for the example image that is "ubuntu", but may be different for other images). A command of the form ssh -i should work.