mirror of https://github.com/hashicorp/packer
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
116 lines
4.9 KiB
116 lines
4.9 KiB
---
|
|
page_title: HCL syntax reference
|
|
description: |-
|
|
HCL syntax combines declarative structure with expressions into Packer templates. Learn how to use HCL syntax to define infrastructure as code.
|
|
---
|
|
|
|
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
|
> [!IMPORTANT]
|
|
> **Documentation Update:** Product documentation previously located in `/website` has moved to the [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs) repository, where all product documentation is now centralized. Please make contributions directly to `web-unified-docs`, since changes to `/website` in this repository will not appear on developer.hashicorp.com.
|
|
⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️⚠️
|
|
|
|
# HCL syntax reference
|
|
|
|
This topic provides reference information about the native HashiCorp configuration language (HCL) syntax you can use to create Packer templates. For information about HCL constructs in JSON, refer to the [JSON syntax reference](/packer/docs/templates/hcl_templates/syntax-json).
|
|
|
|
## Introduction
|
|
|
|
Learning the HCL syntax helps you understand the building blocks that Packer template constructs
|
|
are built from. HCL is a rich language designed to be easy for humans to read and write.
|
|
Otherwhich is also used by configuration languages in other applications, and in
|
|
particular other HashiCorp products. It is not necessary to know all of the
|
|
details of HCL in order to use Packer, and so this page summarizes the most
|
|
important details. If you are interested, you can find a full definition of HCL
|
|
syntax in [the HCL native syntax
|
|
specification](https://github.com/hashicorp/hcl/blob/hcl2/hclsyntax/spec.md).
|
|
|
|
## Arguments and Blocks
|
|
|
|
HCL syntax is built around two key syntax constructs:
|
|
arguments and blocks.
|
|
|
|
### Arguments
|
|
|
|
An _argument_ assigns a value to a particular name:
|
|
|
|
```hcl
|
|
image_id = "abc123"
|
|
```
|
|
|
|
The identifier before the equals sign is the _argument name_, and the expression
|
|
after the equals sign is the argument's value.
|
|
|
|
The context where the argument appears determines what value types are valid
|
|
(for example, each source type has a schema that defines the types of its
|
|
arguments), but many arguments accept arbitrary
|
|
[expressions](/packer/docs/templates/hcl_templates/expressions), which allow the value to
|
|
either be specified literally or generated from other values programmatically.
|
|
|
|
### Blocks
|
|
|
|
A _block_ is a container for other content:
|
|
|
|
```hcl
|
|
source "amazon-ebs" "example" {
|
|
ami_name = "abc123"
|
|
|
|
tags = {
|
|
# ...
|
|
}
|
|
}
|
|
```
|
|
|
|
A block has a _type_ (`source` in this example). Each block type defines
|
|
how many _labels_ must follow the type keyword. The `source` block type
|
|
expects two labels, which are `amazon-ebs` and `example` in the example above.
|
|
A particular block type may have any number of required labels, or it may
|
|
require none as with the nested `tags` block type.
|
|
|
|
After the block type keyword and any labels, the block _body_ is delimited
|
|
by the `{` and `}` characters. Within the block body, further arguments
|
|
and blocks may be nested, creating a hierarchy of blocks and their associated
|
|
arguments.
|
|
|
|
HCL uses a limited number of _top-level block types,_ which
|
|
are blocks that can appear outside of any other block in a configuration file.
|
|
Most of Packer's features (including resources, input variables, output
|
|
values, data sources, etc.) are implemented as top-level blocks.
|
|
|
|
## Identifiers
|
|
|
|
Argument names, block type names, and the names of most Packer-specific
|
|
constructs like resources, input variables, etc. are all _identifiers_.
|
|
|
|
Identifiers can contain letters, digits, underscores (`_`), and hyphens (`-`).
|
|
The first character of an identifier must not be a digit, to avoid ambiguity
|
|
with literal numbers.
|
|
|
|
For complete identifier rules, Packer implements
|
|
[the Unicode identifier syntax](http://unicode.org/reports/tr31/), extended to
|
|
include the ASCII hyphen character `-`.
|
|
|
|
## Comments
|
|
|
|
HCL supports three different syntaxes for comments:
|
|
|
|
- `#` begins a single-line comment, ending at the end of the line.
|
|
- `//` also begins a single-line comment, as an alternative to `#`.
|
|
- `/*` and `*/` are start and end delimiters for a comment that might span
|
|
over multiple lines.
|
|
|
|
The `#` single-line comment style is the default comment style and should be
|
|
used in most cases. Automatic configuration formatting tools may automatically
|
|
transform `//` comments into `#` comments, since the double-slash style is
|
|
not idiomatic.
|
|
|
|
## Character Encoding and Line Endings
|
|
|
|
Packer configuration files must always be UTF-8 encoded. While the
|
|
delimiters of the language are all ASCII characters, Packer accepts
|
|
non-ASCII characters in identifiers, comments, and string values.
|
|
|
|
Packer accepts configuration files with either Unix-style line endings
|
|
(LF only) or Windows-style line endings (CR then LF), but the idiomatic style
|
|
is to use the Unix convention, and so automatic configuration formatting tools
|
|
may automatically transform CRLF endings to LF.
|