website/content/docs/templates/hcl_templates/index.mdx
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
[!IMPORTANT]
Documentation Update: Product documentation previously located in/websitehas moved to thehashicorp/web-unified-docsrepository, where all product documentation is now centralized. Please make contributions directly toweb-unified-docs, since changes to/websitein this repository will not appear on developer.hashicorp.com. ⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
This topic provides overview information about HashiCorp configuration language (HCL) templates for Packer.
Packer reads and applies configurations defined in HCL template files. HCL templates provide concise descriptions of the required steps to get to a build file. You can add arguments, blocks, and expressions to your HCL templates to define your build as code. Refer to Introduction to Packer HCL2 for additional information.
The main purpose of the HCL language is defining builds and sources. All other language features exist only to make the definition of builds more flexible and convenient.
packer build 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 schema. For every other case; the JSON only old
packer schema will be used.
The syntax of the HCL language consists of only a few basic elements:
source "amazon-ebs" "main" {
ami_name = "main-ami"
}
<BLOCK TYPE> "<BLOCK LABEL>" "<BLOCK LABEL>" {
# Block body
<IDENTIFIER> = <EXPRESSION> # Argument
}
For full details about Packer's syntax, see:
The HCL language uses configuration files that are named with the .pkr.hcl
file extension. There is also a JSON-based variant of the
language that is named with the .pkr.json file
extension.
Configuration files must always use UTF-8 encoding, and by convention are usually maintained with Unix-style line endings (LF) rather than Windows-style line endings (CRLF), though both are accepted.
The ordering of root blocks is not significant. The order of provisioner or
post-processor blocks within a build is the only major feature where block
order matters.