github.com/hashicorp/packer@v1.14.3/website/content/docs/templates/legacy_json_templates/index.mdx (about)

     1  ---
     2  description: >
     3    JSON templates are files that configure the Packer components that create one or more machine images. Learn how to configure JSON templates.
     4  page_title: JSON templates configuration reference
     5  ---
     6  
     7  # JSON templates configuration reference
     8  
     9  This topic provides reference information for creating JSON templates for Packer.
    10  
    11  `@include 'from-1.5/legacy-json-warning.mdx'`
    12  
    13  ## Introduction
    14  
    15  You can create Packer templates as JSON files that configure the various components
    16  of Packer in order to create one or more machine images. Templates are portable,
    17  static, and readable and writable by both humans and computers. Use the Packer CLI to run builds described in the template to produce any resulting machine images.
    18  
    19  ## JSON Template Structure
    20  
    21  The template is a JSON object that has a set of keys configuring various
    22  components of Packer. The available keys within a template are listed below.
    23  Along with each key, it is noted whether it is required or not.
    24  
    25  - `builders` (_required_) is an array of one or more objects that defines the
    26    builders that will be used to create machine images for this template, and
    27    configures each of those builders. For more information on how to define
    28    and configure a builder, read the sub-section on [configuring builders in
    29    templates](/packer/docs/templates/legacy_json_templates/builders).
    30  
    31  - `description` (optional) is a string providing a description of what the
    32    template does. This output is used only in the [inspect
    33    command](/packer/docs/commands/inspect).
    34  
    35  - `min_packer_version` (optional) is a string that has a minimum Packer
    36    version that is required to parse the template. This can be used to ensure
    37    that proper versions of Packer are used with the template. A max version
    38    can't be specified because Packer retains backwards compatibility with
    39    `packer fix`.
    40  
    41  - `post-processors` (optional) is an array of one or more objects that
    42    defines the various post-processing steps to take with the built images. If
    43    not specified, then no post-processing will be done. For more information
    44    on what post-processors do and how they're defined, read the sub-section on
    45    [configuring post-processors in
    46    templates](/packer/docs/templates/legacy_json_templates/post-processors).
    47  
    48  - `provisioners` (optional) is an array of one or more objects that defines
    49    the provisioners that will be used to install and configure software for
    50    the machines created by each of the builders. If it is not specified, then
    51    no provisioners will be run. For more information on how to define and
    52    configure a provisioner, read the sub-section on [configuring provisioners
    53    in templates](/packer/docs/templates/legacy_json_templates/provisioners).
    54  
    55  - `variables` (optional) is an object of one or more key/value strings that
    56    defines user variables contained in the template. If it is not specified,
    57    then no variables are defined. For more information on how to define and
    58    use user variables, read the sub-section on [user variables in
    59    templates](/packer/docs/templates/legacy_json_templates/user-variables).
    60  
    61  ## Comments
    62  
    63  JSON doesn't support comments and Packer reports unknown keys as validation
    64  errors. If you'd like to comment your template, you can prefix a _root level_
    65  key with an underscore. Example:
    66  
    67  ```json
    68  {
    69    "_comment": "This is a comment",
    70    "builders": [{}]
    71  }
    72  ```
    73  
    74  **Important:** Only _root level_ keys can be underscore prefixed. Keys within
    75  builders, provisioners, etc. will still result in validation errors.
    76  
    77  -> **Note:** Packer supports HCL2 from version 1.6.0. The HashiCorp
    78  Configuration Language does support comments anywhere in template files.
    79  If comments are important to you, consider upgrading your
    80  JSON template to HCL2 using the `packer hcl2_upgrade` command.
    81  
    82  One workaround if you are not ready to upgrade to HCL is to use jq to strip
    83  unsupported comments from a Packer template before you run `packer build`.
    84  
    85  For example, here is a file named `commented_template.json`:
    86  
    87  ```json
    88  {
    89    "_comment": ["this is", "a multi-line", "comment"],
    90    "builders": [
    91      {
    92        "_comment": "this is a comment inside a builder",
    93        "type": "null",
    94        "communicator": "none"
    95      }
    96    ],
    97    "_comment": "this is a root level comment",
    98    "provisioners": [
    99      {
   100        "_comment": "this is a different comment",
   101        "type": "shell",
   102        "_comment": "this is yet another comment",
   103        "inline": ["echo hellooooo"]
   104      }
   105    ]
   106  }
   107  ```
   108  
   109  If you use the following jq command:
   110  
   111  ```shell-session
   112  $ jq 'walk(if type == "object" then del(._comment) else . end)' commented_template.json > uncommented_template.json
   113  ```
   114  
   115  The tool will produce a new file containing:
   116  
   117  ```json
   118  {
   119    "builders": [
   120      {
   121        "type": "null",
   122        "communicator": "none"
   123      }
   124    ],
   125    "provisioners": [
   126      {
   127        "type": "shell",
   128        "inline": ["echo hellooooo"]
   129      }
   130    ]
   131  }
   132  ```
   133  
   134  Once you've got your uncommented file, you can call `packer build` on it like
   135  you normally would.
   136  
   137  If your install of jq does not have the walk function and you get an error like
   138  
   139  ```text
   140  jq: error: walk/1 is not defined at <top-level>,
   141  ```
   142  
   143  You can create a file `~/.jq` and add the [walk function](https://github.com/stedolan/jq/blob/ad9fc9f559e78a764aac20f669f23cdd020cd943/src/builtin.jq#L255-L262) to it by hand.
   144  
   145  ## Example Template
   146  
   147  Below is an example of a basic template that could be invoked with
   148  `packer build`. It would create an instance in AWS, and once running copy a
   149  script to it and run that script using SSH.
   150  
   151  -> **Note:** This example requires an account with Amazon Web Services.
   152  There are a number of parameters which need to be provided for a functional
   153  build to take place. See the [Amazon builder](/packer/plugins/builders/amazon)
   154  documentation for more information.
   155  
   156  ```json
   157  {
   158    "builders": [
   159      {
   160        "type": "amazon-ebs",
   161        "access_key": "...",
   162        "secret_key": "...",
   163        "region": "us-east-1",
   164        "source_ami": "ami-fce3c696",
   165        "instance_type": "t2.micro",
   166        "ssh_username": "ubuntu",
   167        "ami_name": "packer {{timestamp}}"
   168      }
   169    ],
   170  
   171    "provisioners": [
   172      {
   173        "type": "shell",
   174        "script": "setup_things.sh"
   175      }
   176    ]
   177  }
   178  ```