packer-cn/website/source/docs/templates/user-variables.html.md

210 lines
6.7 KiB
Markdown
Raw Normal View History

2013-08-09 19:25:13 -04:00
---
2015-07-22 22:31:00 -04:00
layout: docs
sidebar_current: docs-templates-user-variables
page_title: User Variables - Templates
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.
---
2013-08-09 19:25:13 -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
the command-line, environment variables, 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
portability of the template.
2013-08-09 19:25:13 -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
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
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-04-18 14:34:47 -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`}}",
// ...
2013-08-09 19:25:13 -04:00
}]
}
```
2013-08-09 19:25:13 -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
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
User variables are used by calling the `{{user}}` function in the form of
<code>{{user \`variable\`}}</code>. This function can be used in *any value*
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
## Environment Variables
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
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:
```json
{
"variables": {
"my_secret": "{{env `MY_SECRET`}}",
}
}
```
This will default "my\_secret" to be the value of the "MY\_SECRET" environment
variable (or an empty string if it does not exist).
-> **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
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`.
-> **Why can't I use `~` for home variable?** `~` is an special variable
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 `~`.
2013-08-09 19:25:13 -04:00
## Setting Variables
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
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
```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
any earlier set variable of the same name.
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
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
```json
2013-08-09 19:25:13 -04:00
{
"aws_access_key": "foo",
"aws_secret_key": "bar"
}
```
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
```text
2013-08-09 19:25:13 -04:00
$ packer build -var-file=variables.json template.json
```
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
specified later override a variable set earlier.
2013-08-09 19:25:13 -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:
```text
$ packer build \
-var 'aws_access_key=bar' \
-var-file=variables.json \
-var 'aws_secret_key=baz' \
template.json
```
Results in the following variables:
| Variable | Value |
| -------- | --------- |
| aws_access_key | foo |
| aws_secret_key | baz |
# 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.
```json
{
"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
In order to use `$HOME` variable, you can create a `home` variable in Packer:
2016-03-14 13:34:26 -04:00
```json
{
"variables": {
"home": "{{env `HOME`}}"
}
2016-03-14 13:34:26 -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
```json
2016-03-14 13:34:26 -04:00
{
"builders": [
{
"type":"google",
"account_file": "{{ user `home` }}/.secrets/gcp-{{ user `env` }}.json"
}
]
2016-03-14 13:34:26 -04:00
}
```