github.com/phobos182/packer@v0.2.3-0.20130819023704-c84d2aeffc68/website/source/intro/getting-started/vagrant.html.markdown (about) 1 --- 2 layout: "intro" 3 page_title: "Vagrant Boxes" 4 prev_url: "/intro/getting-started/parallel-builds.html" 5 next_url: "/intro/getting-started/next.html" 6 next_title: "Next Steps" 7 --- 8 9 # Vagrant Boxes 10 11 Packer also has the ability to take the results of a builder (such as 12 an AMI or plain VMware image) and turn it into a [Vagrant](http://www.vagrantup.com) 13 box. 14 15 This is done using [post-processors](/docs/templates/post-processors.html). 16 These take an artifact created by a previous builder or post-processor and 17 transforms it into a new one. In the case of the Vagrant post-processor, it 18 takes an artifact from a builder and transforms it into a Vagrant box file. 19 20 Post-processors are a generally very useful concept. While the example on 21 this getting-started page will be creating Vagrant images, post-processors 22 have many interesting use cases. For example, you can write a post-processor 23 to compress artifacts, upload them, test them, etc. 24 25 Let's modify our template to use the Vagrant post-processor to turn our 26 AWS AMI into a Vagrant box usable with the [vagrant-aws plugin](https://github.com/mitchellh/vagrant-aws). If you followed along in the previous page and setup DigitalOcean, 27 Packer can't currently make Vagrant boxes for DigitalOcean, but will be able 28 to soon. 29 30 ## Enabling the Post-Processor 31 32 Post-processors are added in the `post-processors` section of a template, which 33 we haven't created yet. Modify your `example.json` template and add the section. 34 Your template should look like the following: 35 36 <pre class="prettyprint"> 37 { 38 "builders": [...], 39 40 "provisioners": [...], 41 42 "post-processors": ["vagrant"] 43 } 44 </pre> 45 46 In this case, we're enabling a single post-processor named "vagrant". This 47 post-processor is built-in to Packer and will create Vagrant boxes. You 48 can always create [new post-processors](/docs/extend/post-processor.html), however. 49 The details on configuring post-processors is covered in the 50 [post-processors](/docs/templates/post-processors.html) documentation. 51 52 Validate the configuration using `packer validate`. 53 54 ## Using the Post-Processor 55 56 Just run a normal `packer build` and it will now use the post-processor. 57 Since Packer can't currently make a Vagrant box for DigitalOcean anyways, 58 I recommend passing the `-only=amazon-ebs` flag to `packer build` so it only 59 builds the AMI. The command should look like the following: 60 61 ``` 62 $ packer build -only=amazon-ebs example.json 63 ``` 64 65 As you watch the output, you'll notice at the end in the artifact listing 66 that a Vagrant box was made (by default at `packer_aws.box` in the current 67 directory). Success! 68 69 But where did the AMI go? When using post-processors, Vagrant removes 70 intermediary artifacts since they're usually not wanted. Only the final 71 artifact is preserved. This behavior can be changed, of course. Changing 72 this behavior is covered [in the documentation](/docs/templates/post-processors.html). 73 74 Typically when removing intermediary artifacts, the actual underlying 75 files or resources of the artifact are also removed. For example, when 76 building a VMware image, if you turn it into a Vagrant box, the files of 77 the VMware image will be deleted since they were compressed into the Vagrant 78 box. With creating AWS images, however, the AMI is kept around, since Vagrant 79 needs it to function.