github.com/ratanraj/packer@v1.3.2/website/source/docs/post-processors/vagrant.html.md (about)

     1  ---
     2  description: |
     3      The Packer Vagrant post-processor takes a build and converts the artifact into
     4      a valid Vagrant box, if it can. This lets you use Packer to automatically
     5      create arbitrarily complex Vagrant boxes, and is in fact how the official
     6      boxes distributed by Vagrant are created.
     7  layout: docs
     8  page_title: 'Vagrant - Post-Processors'
     9  sidebar_current: 'docs-post-processors-vagrant-box'
    10  ---
    11  
    12  # Vagrant Post-Processor
    13  
    14  Type: `vagrant`
    15  
    16  The Packer Vagrant post-processor takes a build and converts the artifact into a
    17  valid [Vagrant](https://www.vagrantup.com) box, if it can. This lets you use
    18  Packer to automatically create arbitrarily complex Vagrant boxes, and is in fact
    19  how the official boxes distributed by Vagrant are created.
    20  
    21  If you've never used a post-processor before, please read the documentation on
    22  [using post-processors](/docs/templates/post-processors.html) in templates. This
    23  knowledge will be expected for the remainder of this document.
    24  
    25  Because Vagrant boxes are
    26  [provider-specific](https://docs.vagrantup.com/v2/boxes/format.html), the Vagrant
    27  post-processor is hardcoded to understand how to convert the artifacts of
    28  certain builders into proper boxes for their respective providers.
    29  
    30  Currently, the Vagrant post-processor can create boxes for the following
    31  providers.
    32  
    33  -   AWS
    34  -   Azure
    35  -   DigitalOcean
    36  -   Azure
    37  -   Hyper-V
    38  -   LXC
    39  -   Parallels
    40  -   QEMU
    41  -   VirtualBox
    42  -   VMware
    43  -   Docker
    44  
    45  -> **Support for additional providers** is planned. If the Vagrant
    46  post-processor doesn't support creating boxes for a provider you care about,
    47  please help by contributing to Packer and adding support for it.
    48  
    49  ## Configuration
    50  
    51  The simplest way to use the post-processor is to just enable it. No
    52  configuration is required by default. This will mostly do what you expect and
    53  will build functioning boxes for many of the built-in builders of Packer.
    54  
    55  However, if you want to configure things a bit more, the post-processor does
    56  expose some configuration options. The available options are listed below, with
    57  more details about certain options in following sections.
    58  
    59  -   `compression_level` (number) - An integer representing the compression
    60      level to use when creating the Vagrant box. Valid values range from 0 to 9,
    61      with 0 being no compression and 9 being the best compression. By default,
    62      compression is enabled at level 6.
    63  
    64  -   `include` (array of strings) - Paths to files to include in the Vagrant box.
    65      These files will each be copied into the top level directory of the Vagrant
    66      box (regardless of their paths). They can then be used from the Vagrantfile.
    67  
    68  -   `keep_input_artifact` (boolean) - If set to true, do not delete the
    69      `output_directory` on a successful build. Defaults to false.
    70  
    71  -   `output` (string) - The full path to the box file that will be created by
    72      this post-processor. This is a [configuration
    73      template](/docs/templates/engine.html). The variable
    74      `Provider` is replaced by the Vagrant provider the box is for. The variable
    75      `ArtifactId` is replaced by the ID of the input artifact. The variable
    76      `BuildName` is replaced with the name of the build. By default, the value of
    77      this config is `packer_{{.BuildName}}_{{.Provider}}.box`.
    78  
    79  -   `vagrantfile_template` (string) - Path to a template to use for the
    80      Vagrantfile that is packaged with the box.
    81  
    82  ## Provider-Specific Overrides
    83  
    84  If you have a Packer template with multiple builder types within it, you may
    85  want to configure the box creation for each type a little differently. For
    86  example, the contents of the Vagrantfile for a Vagrant box for AWS might be
    87  different from the contents of the Vagrantfile you want for VMware. The
    88  post-processor lets you do this.
    89  
    90  Specify overrides within the `override` configuration by provider name:
    91  
    92  ``` json
    93  {
    94    "type": "vagrant",
    95    "compression_level": 1,
    96    "override": {
    97      "vmware": {
    98        "compression_level": 0
    99      }
   100    }
   101  }
   102  ```
   103  
   104  In the example above, the compression level will be set to 1 except for VMware,
   105  where it will be set to 0.
   106  
   107  The available provider names are:
   108  
   109  - `aws`
   110  - `azure`
   111  - `digitalocean`
   112  - `google`
   113  - `hyperv`
   114  - `parallels`
   115  - `libvirt`
   116  - `lxc`
   117  - `scaleway`
   118  - `virtualbox`
   119  - `vmware`
   120  - `docker`
   121  
   122  ## Input Artifacts
   123  
   124  By default, Packer will delete the original input artifact, assuming you only
   125  want the final Vagrant box as the result. If you wish to keep the input artifact
   126  (the raw virtual machine, for example), then you must configure Packer to keep
   127  it.
   128  
   129  Please see the [documentation on input
   130  artifacts](/docs/templates/post-processors.html#toc_2) for more information.
   131  
   132  ### Docker
   133  
   134  Using a Docker input artifact will include a reference to the image in the
   135  `Vagrantfile`. If the image tag is not specified in the post-processor, the
   136  sha256 hash will be used.
   137  
   138  The following Docker input artifacts are supported:
   139  
   140   - `docker` builder with `commit: true`, always uses the sha256 hash
   141   - `docker-import`
   142   - `docker-tag`
   143   - `docker-push`