Automation

Convert Packer Variables JSON to HCL2 for automated vSphere templates

Convert Packer Variables JSON to HCL2 for automated vSphere builds. Convert your JSON variables file into HCL2 format, file names needed, etc

One of the tasks I have been working on lately is getting my Packer vSphere build templates converted over from JSON to the new preferred HCL2 language as of Packer 1.7.2. This is the preferred language to write your Packer build files in moving forward, and you should begin taking that step if you are using the JSON files previously, as I was doing. Until now, I have still been using the JSON templates due to not having the time to rewrite these. I wanted to share with the community a few of the simple yet obscure answers that I had to find by trial and error when moving my files from JSON to HCL2. Let’s look at how to convert Packer variables JSON to HCL2 for automated vSphere builds and see what needs to go where.

HCL2 upgrade process

To upgrade your Packer build JSON file to HCL2, Hasicorp has included an hcl2_upgrade parameter for the packer command. You can feed it your build file, and it will automatically convert the file to HCL2 for you. However, as I found, it does not work with the variables file you may use with Packer. But more on that later.

How do you upgrade your build file? It is simple. Just issue the packer hcl2_upgrade command and pass in your build JSON file. For example:

packer hcl2_upgrade windowsserver2022.json

As you can see below, I have passed in the packer build file and it has successfully created the new .pkr.hcl file. Using the -with-annotations parameter, the conversion will add relevant comments to the new pkr.hcl file which are helpful.

Upgrading packer build json to hcl2
Upgrading packer build json to hcl2

As you can see below, the top of the new .pkr.hcl file contains the variables.

Variables are included as part of the new pkr.hcl file converted from JSON
Variables are included as part of the new pkr.hcl file converted from JSON

The following is what you see if you try to convert the variables.json file you may currently be using to the proper HCL2 format.

I received the error: Failed to parse file as legacy JSON template when looking to Convert Packer Variables JSON to HCL2 using the built-in tool.

Failed to convert variables file with the hcl2 conversion
Failed to convert variables file with the hcl2 conversion

Can you just stick with the single file created from the HCL2 conversion? Yes, you can. You can just use the single file with the declared variables at the top of the file and assign values in these blocks directly. However, this doesn’t scale very well, meaning your variables are hard coded in your main Packer build file.

You can read the official Packer documentation covering variables here:

Convert Packer Variables JSON to HCL2 for automated vSphere builds

So, I had a feeling there was some manual work to do here to convert Packer Variables JSON to HCL2 that would not be handled with the HCL2 conversion process. In looking at the annotations that were added with the -with-annotations parameter, it gives you the following information:

“The HCL2 blocks in this file can be moved to other files. For example, the variable blocks could be moved to their own ‘variables.pkr.hcl’ file, etc. Those files need to be suffixed with ‘.pkr.hcl’ to be visible to Packer. To use multiple files at once, they also need to be in the same folder. ‘packer inspect folder/’ will describe to you what is in that folder.”

For me, the struggle was figuring out exactly how to name the files needed for the packer build command to read them correctly and how to pass in the variables correctly.

As it turns out, the new format I went with in Packer uses three files instead of the two files I had before. Now I have the following:

  • variables.pkr.hcl – houses the variable declaration blocks and any defaults
  • windowsserver2022.auto.pkrvars.hcl – houses the variable values you want to define. What is the significance of the auto in the file? With the auto appended in the front of the pkrvars.hcl extension, Packer knows to include the file with the build run automatically.
  • WindowsServer2022.json.pkr.hcl – the Packer build file

If you use Terraform, this structure is not too different from what we are used to. You will have your main.tf file with the main Terraform code, the variables.tf file declares the variables, and the .tfvars file assigns values to the variables. From that standpoint, I like this new change as it aligns nicely with Terraform.

However, the challenge I ran into was the lack of specifics in one place on how to name your files and which information should be in which file.

Note the example files below so you have a reference (something I didn’t find a great example of anywhere that worked for me):

variables.pkr.hcl

variable "cpu_num" {
  type    = string
  default = ""
}

variable "disk_size" {
  type    = string
  default = ""
}

variable "mem_size" {
  type    = string
  default = ""
}

windowsserver2022.auto.pkrvars.hcl

cpu_num = 4
mem_size = 4096
disk_size = 102400

Putting it altogether

Once you have your files named correctly and in place for your automated vSphere Packer build runs, you can perform a build. You can run your packer command in the following order. Note the trailing period. This tells packer to look at the current directory if that is your focus when running from the command line.

  • packer init .
  • packer validate .
  • packer build .
Running the packer build with the new HCL2 files in place
Running the packer build with the new HCL2 files in place

Convert Packer Variables JSON to HCL2 FAQs

  • What is Hashicorp HCL2 language? It is the new preferred configuration language for Packer moving forward from version 1.7.2 forward. It provides many benefits and helps to align Packer configurations with Terraform at this point. You can have comments in the code now and it is easier to read
  • Why convert from JSON to HCL2? As mentioned, it is the supported and preferred way moving forward for your Packer templates. At some point, I would imagine Hashicorp may deprecate support for JSON. It is probably quite a ways down the road, but it should be expected. So, moving your code over to HCL2 sooner than later is a good idea. Also, there are other advantages such as the fact the HCL2 templates handle EFI much more gracefully. No need to hack the boot.wim file on media to account for EFI boot.
  • How do you convert from JSON to HCL2? Packer has a built-in parameter that converts your main Packer build template from JSON to HCL2 automatically. However, as shown in the post, it does not automatically convert/create your variables file for you if you have been using an external file with your JSON configuration.
  • How do you convert Packer Variables JSON to HCL2? There is a hcl2_upgrade parameter that allows converting your code from JSON to HCL2.

Wrapping Up

I hope this little walkthrough and details of the files and what is contained in each helps others who may be struggling to figure out where your variable need to go and what the names of the files need to be. I found a lot of conflicting information on the file extensions and other details that led to quite a bit of trial and error in transforming my JSON files over to HCL2.

Read some of my previous Packer posts here:

Subscribe to VirtualizationHowto via Email 🔔

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Brandon Lee

Brandon Lee is the Senior Writer, Engineer and owner at Virtualizationhowto.com and has over two decades of experience in Information Technology. Having worked for numerous Fortune 500 companies as well as in various industries, Brandon has extensive experience in various IT segments and is a strong advocate for open source technologies. Brandon holds many industry certifications, loves the outdoors and spending time with family.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.