Using Terraform for "temporary" AWS instances

[Niklaas Baudet von Gersdorff]

Hello,

is it possible to write a configuration that creates an AWS EBS
resource and an EC2 instance when doing `terraform apply` but
when doing `terraform destroy` only destroys the EC2
instance -- leaving the EBS drive alive?

I work on a skeleton [1] that creates a powerful machine for
building/compiling FreeBSD ports. I don't need the machine itself
to run 24/7. However, the data written on the EBS should stay
intact. So each time I spin up the EC2 infrastructure, I would
like to re-attach the EBS drive; and the newly created EC2
instance could continue where the older one stopped.

Thinking about it, one solution might be to separate both
resources in distinct terraform skeletons. Then I would import
the EBS drive into the EC2 skeleton. Thus, issuing `terraform
destroy` within the EC2 instance shouldn't destroy the EBS drive.
This seems a bit hack-ish, though.

Is there some way to configure some type of "temporary" instance
that can only be used when it's needed?

Any help is very much appreciated.

Niklaas

1: https://github.com/niklaas/port-builder

[Philip Nelson]

Using terraform in separate "hackish" skeletons as you call it is really a fully supported technique. We call this layers, and you pull information from one layer into another via a data "terraform_remote_state" resource. I'd be curious if others have unique ways to solve your particular question, there are likely other options. With a layered approach though, in a terraform run you'd create the parts that will linger on and use output blocks to output the arn of the ebs volumes. in your temporary machine layer, you'd use data "terraform_remote_state", retrieve the arn of the previously created output and continue on your way. 

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/hashicorp/terraform/issues
IRC: #terraform-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Terraform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to terraform-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/terraform-tool/20170624120243.4ed6s2rwyushihvv%40box-hlm-03.niklaas.eu.
For more options, visit https://groups.google.com/d/optout.

[David Maze]

On Saturday, June 24, 2017 at 8:52:31 AM UTC-4, Philip Nelson wrote:

Using terraform in separate "hackish" skeletons as you call it is really a fully supported technique. We call this layers, and you pull information from one layer into another via a data "terraform_remote_state" resource.

I'll second this: the last big Terraform project I set up had some persistent data that we really didn't want to accidentally destroy and we split it up in exactly this way (the network was in one Terraform project, the databases in a second, the application in a third) so that if we ran "terraform destroy" on the blue copy of the blue/green application pair there was zero risk of taking the database with it.  The higher layers found the lower layers via terraform_remote_state.

[Rob Coward]

This is exactly how we structure our terraform deploys. One project to deploy the network layer infrastructure, another to create long-lived ebs volumes and a third to create instances mounting the ebs volumes, referencing back to the terraform remote state for previous stacks to dynamically get details about the vpc_id, subnet_id, ebs_volume_id etc.

[Niklaas Baudet von Gersdorff]

Philip Nelson [2017-06-24 07:52 -0500] :

> Using terraform in separate "hackish" skeletons as you call it is
> really a fully supported technique. We call this layers, and you pull
> information from one layer into another via a data
> "terraform_remote_state" resource. I'd be curious if others have
> unique ways to solve your particular question, there are likely other
> options. With a layered approach though, in a terraform run you'd
> create the parts that will linger on and use output blocks to output
> the arn of the ebs volumes. in your temporary machine layer, you'd
> use data "terraform_remote_state", retrieve the arn of the previously
> created output and continue on your way.
> On Sat, Jun 24, 2017 at 7:02 AM, 'Niklaas Baudet von Gersdorff' via

> Terraform <[1]terrafo...@googlegroups.com> wrote:

David Maze [2017-06-24 09:36 -0700] :

> I'll second this: the last big Terraform project I set up had some
> persistent data that we really didn't want to accidentally destroy
> and we split it up in exactly this way (the network was in one
> Terraform project, the databases in a second, the application in a
> third) so that if we ran "terraform destroy" on the blue copy of the
> blue/green application pair there was zero risk of taking the
> database with it. The higher layers found the lower layers via
> terraform_remote_state.

Rob Coward [2017-06-25 00:34 -0700] :

> This is exactly how we structure our terraform deploys. One project
> to deploy the network layer infrastructure, another to create
> long-lived ebs volumes and a third to create instances mounting the
> ebs volumes, referencing back to the terraform remote state for
> previous stacks to dynamically get details about the vpc_id,
> subnet_id, ebs_volume_id etc.
> On Saturday, 24 June 2017 17:36:56 UTC+1, David Maze wrote:

I see. Thanks a lot for your input and the heads-up! Your
feedback is very helpful.

I'll take a closer look on "layers", "output blocks", and
"terraform_remote_state". Glad to see that my initial thought
leads towards the right direction although I didn't see that. :-)

Niklaas