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