packer-cn/website/content/guides/hcl/from-json-v1.mdx

---
page_title: Transforming Packer v1 files for Packer v1.5.0
sidebar_title: From JSON v1
description: |-
  Learn how to manually move from a Packer v1 working JSON build file to a
  working v1.5.0 HCL file.
---

# Transforming Packer v1 config files to HCL2 for Packer v1.5

@include 'guides/hcl2-beta-note.mdx'

As of v1.6.4, Packer provides a tool to help you convert legacy JSON files to
HCL2 files. To run it, you can use the `hcl2_upgrade` command.

for example,

```sh
packer hcl2_upgrade mytemplate.json
```

will convert your packer template to a new HCL2 file in your current working
directory named mytemplate.json.pkr.hcl. It is not a perfect converter yet;
please open an issue if you find a problem with the conversion. Packer will not
destroy your legacy json template, so this is not a risky command to call.

Following is an explanation of how to manually upgrade a JSON template to an
HCL2 template.

The following file :

```json
{
  "builders": [
    {
      "ami_name": "packer-test",
      "region": "us-east-1",
      "instance_type": "t2.micro",

      "source_ami_filter": {
        "filters": {
          "virtualization-type": "hvm",
          "name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
          "root-device-type": "ebs"
        },
        "owners": ["amazon"],
        "most_recent": true
      },

      "ssh_username": "ubuntu",
      "type": "amazon-ebs"
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": ["sleep 5"]
    }
  ]
}
```

Becomes:

```hcl
# The data block defines a data source that is used to fetch data from outside Packer.
# The amazon-ami data source was generated from the source_ami_filter present in
# the amazon builder from the JSON template.
data "amazon-ami" "autogenerated_1" {
  filters = {
    name                = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
    root-device-type    = "ebs"
    virtualization-type = "hvm"
  }
  most_recent = true
  owners      = ["amazon"]
  region      = "us-east-1"
}

# The source block is what was defined in the builders section and represents a
# reusable way to start a machine. You build your images from that source. All
# sources have a 1:1 correspondence to what currently is a builder. The
# argument name (ie: ami_name) must be unquoted and can be set using the equal
# sign operator (=).
source "amazon-ebs" "autogenerated_1" {
  ami_name      = "packer-test"
  instance_type = "t2.micro"
  region        = "us-east-1"
  source_ami    = "${data.amazon-ami.autogenerated_1.id}"
  ssh_username  = "ubuntu"
}

# A build starts sources and runs provisioning steps on those sources.
build {
  sources = [
    # there can be multiple sources per build
    "source.amazon-ebs.autogenerated_1"
  ]

  # All provisioners and post-processors have a 1:1 correspondence to their
  # current layout. The argument name (ie: inline) must to be unquoted
  # and can be set using the equal sign operator (=).
  provisioner "shell" {
    inline = ["sleep 5"]
  }

  # post-processors work too, example: `post-processor "shell-local" {}`.
}
```

### 1:1 correspondence of components ... except :

All fields of builders, provisioners and post-processors have a 1:1
correspondance except for the following:

- builders:

  - aws ami_block_device_mappings
  - aws launch_block_device_mappings
  - aws run_volume_tags
  - alicloud image_disk_mappings
  - osc omi_block_device_mappings
  - osc launch_block_device_mappings
  - proxmox network_adapters
  - proxmox disks
  - tencentcloud data_disks
  - ucloud image_copy_to_mappings

- provisioner:

  - converge module_dirs

- post-processor:
  - alicloud-import image_disk_mappings

One could think that these are defined as "arrays of blocks" - they are in fact
repeatable blocks with the same identifier. For example:

```json
"builders": [
    {
      "type": "amazon-ebs",
      "launch_block_device_mappings": [
        {
          "device_name": "/dev/xvda",
          "volume_size": "20",
          "volume_type": "gp2",
          "delete_on_termination": "true"
        },
        {
          "device_name": "/dev/xvdf",
          "volume_size": "500",
          "volume_type": "gp2",
          "delete_on_termination": "true",
          "encrypted": true
        }
      ],
    }
]
```

Becomes:

```hcl
source "amazon-ebs" "example" {
    launch_block_device_mappings {
        device_name = "/dev/xvda"
        volume_size = 20
        volume_type = "gp2"
        delete_on_termination = true
    }
    launch_block_device_mappings {
        device_name = "/dev/xvdf"
        volume_size = 500
        volume_type = "gp2"
        delete_on_termination = true
        encrypted = true
    }
}
```

There is soon going to be a PR to drop the `s` at the end of these fields.

### Deprecation

As we become more confident in the new templates, we may add more and more features that are HCL2-only.
As of **1.7.0**, the new Data Source component type is the first HCL2-only feature.
One of our major motivations to moving to the new template format is that HCL2 provides us with the flexibility to implement some
features which would be very difficult to add to the legacy JSON templates.

However, the Packer team will continue to support the main functionality of the
current "legacy JSON" Packer templates alongside the new preferred HCL2 templates.