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

We will soon provide a programatic way to transpose a v1 buildfile to a v1.5 HCL file. In the meantime we will show how to manually do it.

The following file :

{
  "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:

# 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 correspondance 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" "example" {
    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
    }

    communicator = "ssh"
    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.example"
  ]

  # 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:

"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:

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

The current layout of buildfiles will be supported until we and the community love the new format. Only then the v1 format will be carefully deprecated.