This follows #8232 which added the code to generate the code required to parse
HCL files for each packer component.
All old config files of packer will keep on working the same. Packer takes one
argument. When a directory is passed, all files in the folder with a name
ending with “.pkr.hcl” or “.pkr.json” will be parsed using the HCL2 format.
When a file ending with “.pkr.hcl” or “.pkr.json” is passed it will be parsed
using the HCL2 format. For every other case; the old packer style will be used.
## 1. the hcl2template pkg can create a packer.Build from a set of HCL (v2) files
I had to make the packer.coreBuild (which is our one and only packer.Build ) a public struct with public fields
## 2. Components interfaces get a new ConfigSpec Method to read a file from an HCL file.
This is a breaking change for packer plugins.
a packer component can be a: builder/provisioner/post-processor
each component interface now gets a `ConfigSpec() hcldec.ObjectSpec`
which allows packer to tell what is the layout of the hcl2 config meant
to configure that specific component.
This ObjectSpec is sent through the wire (RPC) and a cty.Value is now
sent through the already existing configuration entrypoints:
Provisioner.Prepare(raws ...interface{}) error
Builder.Prepare(raws ...interface{}) ([]string, error)
PostProcessor.Configure(raws ...interface{}) error
close#1768
Example hcl files:
```hcl
// file amazon-ebs-kms-key/run.pkr.hcl
build {
sources = [
"source.amazon-ebs.first",
]
provisioner "shell" {
inline = [
"sleep 5"
]
}
post-processor "shell-local" {
inline = [
"sleep 5"
]
}
}
// amazon-ebs-kms-key/source.pkr.hcl
source "amazon-ebs" "first" {
ami_name = "hcl2-test"
region = "us-east-1"
instance_type = "t2.micro"
kms_key_id = "c729958f-c6ba-44cd-ab39-35ab68ce0a6c"
encrypt_boot = true
source_ami_filter {
filters {
virtualization-type = "hvm"
name = "amzn-ami-hvm-????.??.?.????????-x86_64-gp2"
root-device-type = "ebs"
}
most_recent = true
owners = ["amazon"]
}
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
}
ami_regions = ["eu-central-1"]
run_tags {
Name = "packer-solr-something"
stack-name = "DevOps Tools"
}
communicator = "ssh"
ssh_pty = true
ssh_username = "ec2-user"
associate_public_ip_address = true
}
```
* Adding NSG to the ARM eployment template when needed
* Adding tests and fixing bugs
* Removing denyall rule
* Fixing logic to determine which port to open
* Fixing config description
Export a configuration knob to change the disk caching setting. The
default value remains ReadWrite. This seems the most appropriate value
given Packer. Certain disk sizes require that disk caching be disable,
and this knob allows the user to do just that.
Location is required by default because you must specify where to create
the resource group containing the packer resources.
When using build_resource_group_name you are specifying that packer
should use an existing resource group and so the location that resources
are in can be determined by fetching the information from the existing
group.
It is forbidden to pass both variables as it is easier and more
intuitive that the location comes from the group rather than ignore a
parameter.
Closes: #5655
* More unit testing to assert customer's configuration.
* Further reduce the options that are needed to power an Azure build.
This seems like a much more manageable level.
* Update all of the examples to use a more current VM sku.
* Add an example for RHEL.
* Move from OpenSuSE to SuSE.
* Update the docs.
Two new configuration options have been exposed to allow users to specify
an existing virtual network: virtual_network_name and
virtual_network_resource_group_name.
* virtual_network_name: name of the virtual network to attach a Packer VM
to.
* virtual_network_resource_group_name: name of the resource group that
contains the virtual network. This value is optional. If the value is
not specified, the builder queries Azure for the appropriate value. If
the builder cannot disambiguate the value, a value must be provided for
this setting.
* virtual_network_subnet_name: name of the subnet attached to the virtual
network. This value is optional. If the value is not specified, the
builder queries Azure for the appropriate value. If the builder cannot
disambiguate the value, a value must be provided for this setting.