Hello,
So relatively new to the Terraform and Packer configs.
I have created Packer collection to build a Linux VM from scratch. That works fine. I have also created multiple Terraform collections to build various objects with vSphere.
What I cannot seem to find is a provider that allows a Terraform collection to call Packer to build the VM(resource object) within the collection. Currently today I run separate commands on Packer (to build the VM), then Terraform to do something with that object.
I am assuming I am missing a provider/resource that allows my Terraform collection to start the Packer collection first, then continue.
If you can confirm it does exist (and the docs) or that it is not possible today.
Environment:
Terraform = 1.0.2
Packer = 1.7.5
Hi @tlb1galaxy,
First I want to say that I’m not totally sure I understand what you mean by “collection” here, but to try to answer your question I’ve guessed that “Packer Collection” means Packer Template and “Terraform Collection” means Terraform Configuration. If I didn’t understand you correctly then the following answer probably won’t make sense.
When thinking about a deployment workflow Packer typically provides all or part of the “build” step, while Terraform can provide the “deploy” step. There isn’t any built-in way to run Packer as part of running Terraform because that would mean running the build step as part of the deploy step, which is not an approach I’d typically recommend when designing a deployment pipeline.
The reason is that typically I’d want the pipeline to “remember” some number of previous build artifacts, in case I learn that a new artifact is somehow broken and need to quickly roll back to a previous one. With Packer and Terraform as the build and deploy steps, that would involve running Terraform and passing it an earlier build artifact (vSphere image, I suppose).
A common way to achieve that is to make your build step end by writing the new image ID somewhere that Terraform can find it using data sources. I don’t know vSphere well enough to suggest a particular strategy here, but perhaps a custom attribute associated with some object that represents your application/service would work, and allow you to retrieve it using the vsphere_custom_attribute data source.
Your “deploy” step, implemented using Terraform, can then read that id and pass it into the appropriate place in your configuration to select the new image. If you need to roll back to an earlier image for a reason like I described earlier, you’d manually reset whatever attribute is storing the current image ID to refer to an earlier image ID and run Terraform again, without re-running the build process first.
Thanks for the detailed reply.
Yes your assumptions on the terminology is correct. I will use these in future correspondence as it makes it easier when every is on the same page.
Having the image ID written somewhere where Terraform can read it, is the type of idea I was looking for (and makes sense now). I should be able to write the name of the VM/template into a file. Within Terraform use null data source file, read that value (as a pseudo variable) to pass to the vphere-virtual-machine.name. That should allow the TF to find the correct VM and continue. [off the top of the head but, will have to play with that approach to see where I get].
tx