github.com/aclaygray/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`