Packer provider

[mytototo]

Hi all,

Is there any plan to add a Packer provisioner for Terraform?

Thanks for your support.

[apparentlymart]

Hi @mytototo! Thanks for this question.

This was asked a while back (by me, before I was on the TF team, in fact!) in #1586.

You can see there that the question didn't really close out with any specific conclusion, but I can say that at this time there are no specific plans to do this, though in future we may see concepts from Terraform and Packer start to merge in some as-yet-undefined way.

Since there are no definite plans here I'm going to close this. Right now the recommendation is that one would run packer before Terraform, and then use the resulting artifacts either by passing their ids directly as Terraform variables or by publishing them somewhere and having Terraform access them via a data source.

Thanks again for your interest!

[painty1]

Not sure if this will get seen as the issue is closed but we have a scenario where packer requires the output of a terraform resource in order to bake that into an AMI build. We are provisioning AWS EFS and the DNS name of the EFS mount needs to be passed to Packer so that as a post AMI build step, the instance will mount the EFS using it's DNS name it got from Terraform. Is there any other way round this apart from having Terraform output the dns name to a file that Packer then reads as part of a script?
Thanks

[Defozo]

It would be great to have Packer provider in Terraform. I need it too.

[blckct]

@painty1 Wouldn't it be a better idea to use a private R53 zone inside VPC and point a subdomain to EFS? That way you can have a DNS record in Packer that doesn't change.

[apparentlymart]

Generally-speaking I would suggest inverting the dependency here so that the image is built and fixed before Terraform runs, which then allows you to potentially launch the same image multiple times without modification.

Machines will commonly need access to objects that are provisioned by Terraform. This can be achieved either directly or indirectly, depending on your needs/tastes:

• Indirectly: have Terraform publish information in a location that is hard-coded into the image so that the instance can find it when it launches. DNS is a good candidate for this, since instances usually have auto-configured DNS and as @blckct pointed out you can do this with built-in features in AWS. Another option is to use a tagging scheme for your objects and have the instance reach out to the cloud provider API to find the objects by tag.
• Directly: Serialize the necessary information into a single string and pass it into your instance using the "user data" feature of your cloud provider. For example, in AWS that can be done by setting user_data on the aws_instance resource type. This is actually very similar to the indirect approach at a high level, since the instance user-data is fundamentally just a specific example of a "well-known location", but it has the advantage that it can take the instance's identity into account so you can easily pass entirely separate data to each instance and thus keep things self-contained.

As a general architectural principle we always recommend building images and other artifacts as a separate build step before running Terraform. Terraform is not designed as a build tool, and so it lacks features such as retaining an archive of old artifacts to enable rollback, etc. Terraform is best employed as a final provisioning step at the end of a pipeline of other test and build steps, particularly if the same artifact is e.g. first deployed in a testing environment and then "promoted" to a production environment.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.