github.com/mmcquillan/packer@v1.1.1-0.20171009221028-c85cf0483a5d/website/source/docs/templates/user-variables.html.md (about) 1 --- 2 description: | 3 User variables allow your templates to be further configured with variables 4 from the command-line, environment variables, or files. This lets you 5 parameterize your templates so that you can keep secret tokens, 6 environment-specific data, and other types of information out of your 7 templates. This maximizes the portability and shareability of the template. 8 layout: docs 9 page_title: 'User Variables - Templates' 10 sidebar_current: 'docs-templates-user-variables' 11 --- 12 13 # Template User Variables 14 15 User variables allow your templates to be further configured with variables from 16 the command-line, environment variables, or files. This lets you parameterize 17 your templates so that you can keep secret tokens, environment-specific data, 18 and other types of information out of your templates. This maximizes the 19 portability of the template. 20 21 Using user variables expects you to know how [configuration 22 templates](/docs/templates/engine.html) work. If you don't know 23 how configuration templates work yet, please read that page first. 24 25 ## Usage 26 27 User variables must first be defined in a `variables` section within 28 your template. Even if you want a user variable to default to an empty 29 string, it must be defined. This explicitness helps reduce the time it 30 takes for newcomers to understand what can be modified using variables 31 in your template. 32 33 The `variables` section is a key/value mapping of the user variable name 34 to a default value. A default value can be the empty string. An example 35 is shown below: 36 37 ``` json 38 { 39 "variables": { 40 "aws_access_key": "", 41 "aws_secret_key": "" 42 }, 43 44 "builders": [{ 45 "type": "amazon-ebs", 46 "access_key": "{{user `aws_access_key`}}", 47 "secret_key": "{{user `aws_secret_key`}}", 48 // ... 49 }] 50 } 51 ``` 52 53 In the above example, the template defines two user variables: 54 `aws_access_key` and `aws_secret_key`. They default to empty values. 55 Later, the variables are used within the builder we defined in order to 56 configure the actual keys for the Amazon builder. 57 58 If the default value is `null`, then the user variable will be 59 *required*. This means that the user must specify a value for this 60 variable or template validation will fail. 61 62 User variables are used by calling the `{{user}}` function in the form of 63 <code>{{user \`variable\`}}</code>. This function can be used in *any value* 64 but `type` within the template: in builders, provisioners, *anywhere outside 65 the `variables` section*. User variables are available globally within the rest 66 of the template. 67 68 ## Environment Variables 69 70 Environment variables can be used within your template using user variables. 71 The `env` function is available *only* within the default value of a user 72 variable, allowing you to default a user variable to an environment variable. 73 An example is shown below: 74 75 ``` json 76 { 77 "variables": { 78 "my_secret": "{{env `MY_SECRET`}}", 79 } 80 } 81 ``` 82 83 This will default "my\_secret" to be the value of the "MY\_SECRET" environment 84 variable (or an empty string if it does not exist). 85 86 -> **Why can't I use environment variables elsewhere?** User variables are 87 the single source of configurable input to a template. We felt that having 88 environment variables used *anywhere* in a template would confuse the user 89 about the possible inputs to a template. By allowing environment variables 90 only within default values for user variables, user variables remain as the 91 single source of input to a template that a user can easily discover using 92 `packer inspect`. 93 94 -> **Why can't I use `~` for home variable?** `~` is an special variable 95 that is evaluated by shell during a variable expansion. As Packer doesn't run 96 inside a shell, it won't expand `~`. 97 98 ## Setting Variables 99 100 Now that we covered how to define and use user variables within a 101 template, the next important point is how to actually set these 102 variables. Packer exposes two methods for setting user variables: from 103 the command line or from a file. 104 105 ### From the Command Line 106 107 To set user variables from the command line, the `-var` flag is used as 108 a parameter to `packer build` (and some other commands). Continuing our 109 example above, we could build our template using the command below. The 110 command is split across multiple lines for readability, but can of 111 course be a single line. 112 113 ``` text 114 $ packer build \ 115 -var 'aws_access_key=foo' \ 116 -var 'aws_secret_key=bar' \ 117 template.json 118 ``` 119 120 As you can see, the `-var` flag can be specified multiple times in order to set 121 multiple variables. Also, variables set later on the command-line override 122 any earlier set variable of the same name. 123 124 ### From a File 125 126 Variables can also be set from an external JSON file. The `-var-file` flag reads 127 a file containing a key/value mapping of variables to values and sets 128 those variables. An example JSON file may look like this: 129 130 ``` json 131 { 132 "aws_access_key": "foo", 133 "aws_secret_key": "bar" 134 } 135 ``` 136 137 It is a single JSON object where the keys are variables and the values are the 138 variable values. Assuming this file is in `variables.json`, we can build our 139 template using the following command: 140 141 ``` text 142 $ packer build -var-file=variables.json template.json 143 ``` 144 145 The `-var-file` flag can be specified multiple times and variables from multiple 146 files will be read and applied. As you'd expect, variables read from files 147 specified later override a variable set earlier. 148 149 Combining the `-var` and `-var-file` flags together also works how you'd 150 expect. Variables set later in the command override variables set 151 earlier. So, for example, in the following command with the above 152 `variables.json` file: 153 154 ``` text 155 $ packer build \ 156 -var 'aws_access_key=bar' \ 157 -var-file=variables.json \ 158 -var 'aws_secret_key=baz' \ 159 template.json 160 ``` 161 162 Results in the following variables: 163 164 | Variable | Value | 165 |------------------|-------| 166 | aws\_access\_key | foo | 167 | aws\_secret\_key | baz | 168 169 # Recipes 170 171 ## Making a provisioner step conditional on the value of a variable 172 173 There is no specific syntax in Packer templates for making a provisioner 174 step conditional, depending on the value of a variable. However, you may 175 be able to do this by referencing the variable within a command that 176 you execute. For example, here is how to make a `shell-local` 177 provisioner only run if the `do_nexpose_scan` variable is non-empty. 178 179 ``` json 180 { 181 "type": "shell-local", 182 "command": "if [ ! -z \"{{user `do_nexpose_scan`}}\" ]; then python -u trigger_nexpose_scan.py; fi" 183 } 184 ``` 185 186 ## Using HOME Variable 187 188 In order to use `$HOME` variable, you can create a `home` variable in Packer: 189 190 ``` json 191 { 192 "variables": { 193 "home": "{{env `HOME`}}" 194 } 195 } 196 ``` 197 198 And this will be available to be used in the rest of the template, i.e.: 199 200 ``` json 201 { 202 "builders": [ 203 { 204 "type":"google", 205 "account_file": "{{ user `home` }}/.secrets/gcp-{{ user `env` }}.json" 206 } 207 ] 208 } 209 ```