Terraform temporary resources

Question

We use terraform, and I'm trying to enable developers to spin up on-demand resources for development.

A use case is: I've opened a new branch, written some code, and I'd like to run things on an EC2 instance + RDS instance pair. Is there a best-practice way of spinning these resources up dynamically using terraform?

My inclination is to create a terraform module that takes in variables, and then enable developers to supply variables via the command line:

terraform apply -var 'ec2_instance_type=m4.xlarge' -var 'rds_instance_type=db.m4.xlarge' 

But I'm not sure if this is the correct way of going about this.

Does anyone have experience with this? Questions I have are:

• Is it dangerous to have these temporary resources live in remote terraform state?
• Should terraform be used like this, or should I be writing raw awscli scripts?
• Is there a way to automatically tear-down these resource after a set amount of time?

Thanks so much for your help!

Answer 1

Take a look on test kitchen or similar, such as terratest, to run the test automatically.

the test kitchen with terraform plugin will manage the case with automation way more than you need manually set it up.

When run the test kitchen, it will start to run terraform init/plan/apply, run the tests and destroy the whole resources.

Let me know if you have any questions on it.

Answer 2

This is certainly not a usual use-case for Terraform, but you could use Terraform as part of a larger system to deal with the mechanics of actually making the changes happen.

It sounds like the resources for each developer have a separate lifetime and so I'd model this by having a separate state file per developer and then building a custom wrapper tool that ensures that Terraform will only be run in a couple of specific ways:

• Create dev environment: given an identifier (a username?) and values for the input variables, create a new Terraform workspace named after that identifier and run terraform apply in it.
• Update/re-spin dev environment: similar to create, but apply against an existing workspace instead
• Destroy environment: given an identifier, switch to the appropriate workspace and run terraform destroy. If that succeeds, delete the workspace.

If you'd be able to re-supply all of the necessary settings for the update actions then the above could be done with no additional storage beyond a Terraform remote backend. You might optionally wish to have your wrapper save the input values for each environment somewhere so that they can be recalled to apply an update, and finally discarded after destroy succeeds.

Terraform's main workflow is optimized for ongoing maintenance of long-lived infrastructure, but with some extra scripting around it you can make use of its core action of turning a desired result into a set of actions as a component while building a different higher-level workflow around it.