2013-08-09 19:25:13 -04:00
|
|
|
---
|
2017-06-14 21:04:16 -04:00
|
|
|
description: |
|
|
|
|
User variables allow your templates to be further configured with variables
|
|
|
|
from the command-line, environment variables, or files. This lets you
|
|
|
|
parameterize your templates so that you can keep secret tokens,
|
|
|
|
environment-specific data, and other types of information out of your
|
|
|
|
templates. This maximizes the portability and shareability of the template.
|
2015-07-22 22:31:00 -04:00
|
|
|
layout: docs
|
2017-06-14 21:04:16 -04:00
|
|
|
page_title: 'User Variables - Templates'
|
|
|
|
sidebar_current: 'docs-templates-user-variables'
|
2017-03-25 18:13:52 -04:00
|
|
|
---
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-03-25 18:13:52 -04:00
|
|
|
# Template User Variables
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
User variables allow your templates to be further configured with variables from
|
2018-07-24 14:24:08 -04:00
|
|
|
the command-line, environment variables, Vault, or files. This lets you parameterize
|
2015-07-22 22:31:00 -04:00
|
|
|
your templates so that you can keep secret tokens, environment-specific data,
|
|
|
|
and other types of information out of your templates. This maximizes the
|
2017-05-15 15:41:27 -04:00
|
|
|
portability of the template.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
Using user variables expects you to know how [configuration
|
2017-03-28 18:28:34 -04:00
|
|
|
templates](/docs/templates/engine.html) work. If you don't know
|
2015-07-22 22:31:00 -04:00
|
|
|
how configuration templates work yet, please read that page first.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
|
|
|
## Usage
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
User variables must first be defined in a `variables` section within
|
|
|
|
your template. Even if you want a user variable to default to an empty
|
|
|
|
string, it must be defined. This explicitness helps reduce the time it
|
|
|
|
takes for newcomers to understand what can be modified using variables
|
|
|
|
in your template.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
The `variables` section is a key/value mapping of the user variable name
|
|
|
|
to a default value. A default value can be the empty string. An example
|
|
|
|
is shown below:
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` json
|
2013-08-09 19:25:13 -04:00
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"aws_access_key": "",
|
|
|
|
"aws_secret_key": ""
|
|
|
|
},
|
|
|
|
|
|
|
|
"builders": [{
|
|
|
|
"type": "amazon-ebs",
|
|
|
|
"access_key": "{{user `aws_access_key`}}",
|
|
|
|
"secret_key": "{{user `aws_secret_key`}}",
|
2014-10-20 13:55:16 -04:00
|
|
|
// ...
|
2013-08-09 19:25:13 -04:00
|
|
|
}]
|
|
|
|
}
|
2014-10-20 13:55:16 -04:00
|
|
|
```
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
In the above example, the template defines two user variables:
|
|
|
|
`aws_access_key` and `aws_secret_key`. They default to empty values.
|
|
|
|
Later, the variables are used within the builder we defined in order to
|
|
|
|
configure the actual keys for the Amazon builder.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
If the default value is `null`, then the user variable will be
|
|
|
|
*required*. This means that the user must specify a value for this
|
|
|
|
variable or template validation will fail.
|
2013-08-31 20:38:38 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
User variables are used by calling the `{{user}}` function in the form of
|
2017-05-09 14:37:49 -04:00
|
|
|
<code>{{user \`variable\`}}</code>. This function can be used in *any value*
|
2017-05-20 03:53:31 -04:00
|
|
|
but `type` within the template: in builders, provisioners, *anywhere outside
|
|
|
|
the `variables` section*. User variables are available globally within the rest
|
|
|
|
of the template.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2016-02-25 17:21:18 -05:00
|
|
|
## Environment Variables
|
2013-12-28 11:34:17 -05:00
|
|
|
|
2016-02-25 17:21:18 -05:00
|
|
|
Environment variables can be used within your template using user variables.
|
2015-07-22 22:31:00 -04:00
|
|
|
The `env` function is available *only* within the default value of a user
|
2016-02-25 17:21:18 -05:00
|
|
|
variable, allowing you to default a user variable to an environment variable.
|
2015-07-22 22:31:00 -04:00
|
|
|
An example is shown below:
|
2013-12-28 11:34:17 -05:00
|
|
|
|
2018-07-24 14:24:08 -04:00
|
|
|
```json
|
2013-12-28 11:34:17 -05:00
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"my_secret": "{{env `MY_SECRET`}}",
|
2017-03-25 18:13:52 -04:00
|
|
|
}
|
2013-12-28 11:34:17 -05:00
|
|
|
}
|
2014-10-20 13:55:16 -04:00
|
|
|
```
|
2013-12-28 11:34:17 -05:00
|
|
|
|
2016-02-25 17:21:18 -05:00
|
|
|
This will default "my\_secret" to be the value of the "MY\_SECRET" environment
|
2017-05-15 15:41:27 -04:00
|
|
|
variable (or an empty string if it does not exist).
|
2013-12-28 11:34:17 -05:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
-> **Why can't I use environment variables elsewhere?** User variables are
|
2015-07-22 22:31:00 -04:00
|
|
|
the single source of configurable input to a template. We felt that having
|
2016-02-25 17:21:18 -05:00
|
|
|
environment variables used *anywhere* in a template would confuse the user
|
|
|
|
about the possible inputs to a template. By allowing environment variables
|
2015-07-22 22:31:00 -04:00
|
|
|
only within default values for user variables, user variables remain as the
|
|
|
|
single source of input to a template that a user can easily discover using
|
|
|
|
`packer inspect`.
|
2013-12-28 11:34:17 -05:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
-> **Why can't I use `~` for home variable?** `~` is an special variable
|
2017-05-15 15:41:27 -04:00
|
|
|
that is evaluated by shell during a variable expansion. As Packer doesn't run
|
2016-03-14 13:34:26 -04:00
|
|
|
inside a shell, it won't expand `~`.
|
|
|
|
|
2018-08-08 11:44:51 -04:00
|
|
|
## Consul keys
|
|
|
|
|
|
|
|
Consul keys can be used within your template using the `consul_key` function.
|
|
|
|
This function is available *only* within the default value of a user variable,
|
|
|
|
for reasons similar to environment variables above.
|
|
|
|
|
|
|
|
```json
|
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"soft_versions": "{{ consul_key `my_image/softs_versions/next` }}"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This will default `soft_versions` to the value of the key `my_image/softs_versions/next`
|
|
|
|
in consul.
|
|
|
|
|
|
|
|
The configuration for consul (address, tokens, ...) must be specified as environment variables,
|
|
|
|
as specified in the [Documentation](https://www.consul.io/docs/commands/index.html#environment-variables).
|
|
|
|
|
2018-07-24 14:24:08 -04:00
|
|
|
## Vault Variables
|
|
|
|
|
|
|
|
Secrets can be read from [Vault](https://www.vaultproject.io/) and used within
|
|
|
|
your template as user variables. the `vault` function is available *only*
|
|
|
|
within the default value of a user variable, allowing you to default a user
|
|
|
|
variable to an environment variable.
|
|
|
|
|
2018-08-16 19:10:35 -04:00
|
|
|
An example of using a v2 kv engine:
|
|
|
|
|
|
|
|
If you store a value in vault using `vault kv put secret/hello foo=world`, you
|
|
|
|
can access it using the following template engine:
|
2018-07-24 14:24:08 -04:00
|
|
|
|
|
|
|
```json
|
|
|
|
{
|
|
|
|
"variables": {
|
2018-08-16 19:10:35 -04:00
|
|
|
"my_secret": "{{ vault `/secret/data/hello` `foo`}}"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
which will assign "my_secret": "world"
|
|
|
|
|
|
|
|
An example of using a v1 kv engine:
|
|
|
|
|
|
|
|
If you store a value in vault using:
|
|
|
|
|
|
|
|
```
|
|
|
|
vault secrets enable -version=1 -path=secrets kv
|
|
|
|
vault kv put secrets/hello foo=world
|
|
|
|
```
|
|
|
|
|
|
|
|
You can access it using the following template engine:
|
|
|
|
|
|
|
|
```
|
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"VAULT_SECRETY_SECRET": "{{ vault `secrets/hello` `foo`}}"
|
2018-07-24 14:24:08 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
This example accesses the Vault path
|
|
|
|
`secret/data/foo` and returns the value stored at the key `bar`, storing it as
|
|
|
|
"my_secret".
|
|
|
|
|
|
|
|
In order for this to work, you must set the environment variables `VAULT_TOKEN`
|
|
|
|
and `VAULT_ADDR` to valid values.
|
|
|
|
|
2017-10-11 22:36:54 -04:00
|
|
|
## Using array values
|
|
|
|
|
|
|
|
Some templates call for array values. You can use template variables for these,
|
|
|
|
too. For example, the `amazon-ebs` builder has a configuration parameter called
|
|
|
|
`ami_regions`, which takes an array of regions that it will copy the AMI to.
|
|
|
|
You can parameterize this by using a variable that is a list of regions, joined
|
|
|
|
by a `,`. For example:
|
|
|
|
|
|
|
|
```json
|
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"destination_regions": "us-west-1,us-west-2"
|
|
|
|
},
|
|
|
|
"builders": [
|
|
|
|
{
|
|
|
|
"ami_name": "packer-qs-{{timestamp}}",
|
|
|
|
"instance_type": "t2.micro",
|
|
|
|
"region": "us-east-1",
|
|
|
|
"source_ami_filter": {
|
|
|
|
"filters": {
|
|
|
|
"name": "*ubuntu-xenial-16.04-amd64-server-*",
|
|
|
|
"root-device-type": "ebs",
|
|
|
|
"virtualization-type": "hvm"
|
|
|
|
},
|
|
|
|
"most_recent": true,
|
|
|
|
"owners": [
|
|
|
|
"099720109477"
|
|
|
|
]
|
|
|
|
},
|
|
|
|
"ami_regions": "{{user `destination_regions`}}",
|
|
|
|
"ssh_username": "ubuntu",
|
|
|
|
"type": "amazon-ebs"
|
|
|
|
}
|
|
|
|
]
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2013-08-09 19:25:13 -04:00
|
|
|
## Setting Variables
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
Now that we covered how to define and use user variables within a
|
|
|
|
template, the next important point is how to actually set these
|
|
|
|
variables. Packer exposes two methods for setting user variables: from
|
|
|
|
the command line or from a file.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
|
|
|
### From the Command Line
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
To set user variables from the command line, the `-var` flag is used as
|
|
|
|
a parameter to `packer build` (and some other commands). Continuing our
|
|
|
|
example above, we could build our template using the command below. The
|
|
|
|
command is split across multiple lines for readability, but can of
|
|
|
|
course be a single line.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` text
|
2013-08-09 19:25:13 -04:00
|
|
|
$ packer build \
|
|
|
|
-var 'aws_access_key=foo' \
|
|
|
|
-var 'aws_secret_key=bar' \
|
|
|
|
template.json
|
|
|
|
```
|
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
As you can see, the `-var` flag can be specified multiple times in order to set
|
|
|
|
multiple variables. Also, variables set later on the command-line override
|
2017-05-15 15:41:27 -04:00
|
|
|
any earlier set variable of the same name.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2018-10-19 18:50:24 -04:00
|
|
|
**warning**
|
|
|
|
If you are calling Packer from cmd.exe, you should double-quote your variables
|
|
|
|
rather than single-quoting them. For example:
|
|
|
|
|
|
|
|
`packer build -var "aws_secret_key=foo" template.json`
|
|
|
|
|
2013-08-09 19:25:13 -04:00
|
|
|
### From a File
|
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
Variables can also be set from an external JSON file. The `-var-file` flag reads
|
2017-05-09 14:37:49 -04:00
|
|
|
a file containing a key/value mapping of variables to values and sets
|
|
|
|
those variables. An example JSON file may look like this:
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` json
|
2013-08-09 19:25:13 -04:00
|
|
|
{
|
|
|
|
"aws_access_key": "foo",
|
|
|
|
"aws_secret_key": "bar"
|
|
|
|
}
|
2014-10-20 13:55:16 -04:00
|
|
|
```
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
It is a single JSON object where the keys are variables and the values are the
|
|
|
|
variable values. Assuming this file is in `variables.json`, we can build our
|
|
|
|
template using the following command:
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` text
|
2018-06-13 09:52:50 -04:00
|
|
|
On Linux :
|
2013-08-09 19:25:13 -04:00
|
|
|
$ packer build -var-file=variables.json template.json
|
2018-06-13 09:52:50 -04:00
|
|
|
On Windows :
|
|
|
|
packer build -var-file variables.json template.json
|
2013-08-09 19:25:13 -04:00
|
|
|
```
|
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
The `-var-file` flag can be specified multiple times and variables from multiple
|
|
|
|
files will be read and applied. As you'd expect, variables read from files
|
2017-05-15 15:41:27 -04:00
|
|
|
specified later override a variable set earlier.
|
2013-08-09 19:25:13 -04:00
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
Combining the `-var` and `-var-file` flags together also works how you'd
|
|
|
|
expect. Variables set later in the command override variables set
|
|
|
|
earlier. So, for example, in the following command with the above
|
|
|
|
`variables.json` file:
|
2016-11-09 19:05:52 -05:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` text
|
2016-11-09 19:05:52 -05:00
|
|
|
$ packer build \
|
|
|
|
-var 'aws_access_key=bar' \
|
|
|
|
-var-file=variables.json \
|
|
|
|
-var 'aws_secret_key=baz' \
|
|
|
|
template.json
|
|
|
|
```
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
Results in the following variables:
|
2016-11-09 19:05:52 -05:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
| Variable | Value |
|
|
|
|
|------------------|-------|
|
|
|
|
| aws\_access\_key | foo |
|
|
|
|
| aws\_secret\_key | baz |
|
2016-01-22 13:38:25 -05:00
|
|
|
|
2018-08-21 13:40:33 -04:00
|
|
|
# Sensitive Variables
|
|
|
|
|
|
|
|
If you use the environment to set a variable that is sensitive, you probably
|
|
|
|
don't want that variable printed to the Packer logs. You can make sure that
|
|
|
|
sensitive variables won't get printed to the logs by adding them to the
|
|
|
|
"sensitive-variables" list within the Packer template:
|
|
|
|
|
|
|
|
``` json
|
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"my_secret": "{{env `MY_SECRET`}}",
|
|
|
|
"not_a_secret": "plaintext",
|
|
|
|
"foo": "bar"
|
|
|
|
},
|
|
|
|
|
|
|
|
"sensitive-variables": ["my_secret", "foo"],
|
|
|
|
...
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
The above snippet of code will function exactly the same as if you did not set
|
|
|
|
"sensitive-variables", except that the Packer UI and logs will replace all
|
|
|
|
instances of "bar" and of whatever the value of "my_secret" is with
|
|
|
|
`<sensitive>`. This allows you to be confident that you are not printing
|
|
|
|
secrets in plaintext to our logs by accident.
|
|
|
|
|
2016-01-22 13:38:25 -05:00
|
|
|
# Recipes
|
|
|
|
|
|
|
|
## Making a provisioner step conditional on the value of a variable
|
|
|
|
|
|
|
|
There is no specific syntax in Packer templates for making a provisioner
|
|
|
|
step conditional, depending on the value of a variable. However, you may
|
|
|
|
be able to do this by referencing the variable within a command that
|
|
|
|
you execute. For example, here is how to make a `shell-local`
|
|
|
|
provisioner only run if the `do_nexpose_scan` variable is non-empty.
|
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` json
|
2016-01-22 13:38:25 -05:00
|
|
|
{
|
|
|
|
"type": "shell-local",
|
|
|
|
"command": "if [ ! -z \"{{user `do_nexpose_scan`}}\" ]; then python -u trigger_nexpose_scan.py; fi"
|
|
|
|
}
|
|
|
|
```
|
2016-03-14 13:34:26 -04:00
|
|
|
|
|
|
|
## Using HOME Variable
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
In order to use `$HOME` variable, you can create a `home` variable in Packer:
|
2016-03-14 13:34:26 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` json
|
2017-03-25 18:13:52 -04:00
|
|
|
{
|
|
|
|
"variables": {
|
|
|
|
"home": "{{env `HOME`}}"
|
|
|
|
}
|
2016-03-14 13:34:26 -04:00
|
|
|
}
|
|
|
|
```
|
|
|
|
|
2017-05-15 15:41:27 -04:00
|
|
|
And this will be available to be used in the rest of the template, i.e.:
|
2016-03-14 13:34:26 -04:00
|
|
|
|
2017-06-14 21:04:16 -04:00
|
|
|
``` json
|
2016-03-14 13:34:26 -04:00
|
|
|
{
|
2017-03-25 18:13:52 -04:00
|
|
|
"builders": [
|
|
|
|
{
|
|
|
|
"type":"google",
|
|
|
|
"account_file": "{{ user `home` }}/.secrets/gcp-{{ user `env` }}.json"
|
|
|
|
}
|
|
|
|
]
|
2016-03-14 13:34:26 -04:00
|
|
|
}
|
|
|
|
```
|