github.com/StackPointCloud/packer@v0.10.2-0.20180716202532-b28098e0f79b/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  -&gt; **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  -&gt; **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  ## Using array values
    99  
   100  Some templates call for array values. You can use template variables for these,
   101  too. For example, the `amazon-ebs` builder has a configuration parameter called
   102  `ami_regions`, which takes an array of regions that it will copy the AMI to.
   103  You can parameterize this by using a variable that is a list of regions, joined
   104  by a `,`. For example:
   105  
   106  ```json
   107  {
   108   "variables": {
   109          "destination_regions": "us-west-1,us-west-2"
   110      },
   111      "builders": [
   112          {
   113              "ami_name": "packer-qs-{{timestamp}}",
   114              "instance_type": "t2.micro",
   115              "region": "us-east-1",
   116              "source_ami_filter": {
   117                  "filters": {
   118                      "name": "*ubuntu-xenial-16.04-amd64-server-*",
   119                      "root-device-type": "ebs",
   120                      "virtualization-type": "hvm"
   121                  },
   122                  "most_recent": true,
   123                  "owners": [
   124                      "099720109477"
   125                  ]
   126              },
   127              "ami_regions": "{{user `destination_regions`}}",
   128              "ssh_username": "ubuntu",
   129              "type": "amazon-ebs"
   130          }
   131      ]
   132  }
   133  ```
   134  
   135  ## Setting Variables
   136  
   137  Now that we covered how to define and use user variables within a
   138  template, the next important point is how to actually set these
   139  variables. Packer exposes two methods for setting user variables: from
   140  the command line or from a file.
   141  
   142  ### From the Command Line
   143  
   144  To set user variables from the command line, the `-var` flag is used as
   145  a parameter to `packer build` (and some other commands). Continuing our
   146  example above, we could build our template using the command below. The
   147  command is split across multiple lines for readability, but can of
   148  course be a single line.
   149  
   150  ``` text
   151  $ packer build \
   152      -var 'aws_access_key=foo' \
   153      -var 'aws_secret_key=bar' \
   154      template.json
   155  ```
   156  
   157  As you can see, the `-var` flag can be specified multiple times in order to set
   158  multiple variables. Also, variables set later on the command-line override
   159  any earlier set variable of the same name.
   160  
   161  ### From a File
   162  
   163  Variables can also be set from an external JSON file. The `-var-file` flag reads
   164  a file containing a key/value mapping of variables to values and sets
   165  those variables. An example JSON file may look like this:
   166  
   167  ``` json
   168  {
   169    "aws_access_key": "foo",
   170    "aws_secret_key": "bar"
   171  }
   172  ```
   173  
   174  It is a single JSON object where the keys are variables and the values are the
   175  variable values. Assuming this file is in `variables.json`, we can build our
   176  template using the following command:
   177  
   178  ``` text
   179  On Linux :
   180  $ packer build -var-file=variables.json template.json
   181  On Windows :
   182  packer build -var-file variables.json template.json
   183  ```
   184  
   185  The `-var-file` flag can be specified multiple times and variables from multiple
   186  files will be read and applied. As you'd expect, variables read from files
   187  specified later override a variable set earlier.
   188  
   189  Combining the `-var` and `-var-file` flags together also works how you'd
   190  expect. Variables set later in the command override variables set
   191  earlier. So, for example, in the following command with the above
   192  `variables.json` file:
   193  
   194  ``` text
   195  $ packer build \
   196      -var 'aws_access_key=bar' \
   197      -var-file=variables.json \
   198      -var 'aws_secret_key=baz' \
   199      template.json
   200  ```
   201  
   202  Results in the following variables:
   203  
   204  | Variable         | Value |
   205  |------------------|-------|
   206  | aws\_access\_key | foo   |
   207  | aws\_secret\_key | baz   |
   208  
   209  # Recipes
   210  
   211  ## Making a provisioner step conditional on the value of a variable
   212  
   213  There is no specific syntax in Packer templates for making a provisioner
   214  step conditional, depending on the value of a variable. However, you may
   215  be able to do this by referencing the variable within a command that
   216  you execute. For example, here is how to make a `shell-local`
   217  provisioner only run if the `do_nexpose_scan` variable is non-empty.
   218  
   219  ``` json
   220  {
   221    "type": "shell-local",
   222    "command": "if [ ! -z \"{{user `do_nexpose_scan`}}\" ]; then python -u trigger_nexpose_scan.py; fi"
   223  }
   224  ```
   225  
   226  ## Using HOME Variable
   227  
   228  In order to use `$HOME` variable, you can create a `home` variable in Packer:
   229  
   230  ``` json
   231  {
   232    "variables": {
   233      "home": "{{env `HOME`}}"
   234    }
   235  }
   236  ```
   237  
   238  And this will be available to be used in the rest of the template, i.e.:
   239  
   240  ``` json
   241  {
   242    "builders": [
   243      {
   244        "type":"google",
   245        "account_file": "{{ user `home` }}/.secrets/gcp-{{ user `env` }}.json"
   246      }
   247    ]
   248  }
   249  ```