Abox File Packer
This also creates the packer user with a default password so that packer can easily connect to the instance to do stuff. Also note the insert_key parameter that will prevent replacing the vagrant default insecure key with a secure one and allow subsequent vagrant setups to properly connect via SSH to the new images (after packer is done).
Abox file packer
A common reason DevOps engineers pick up Packer and Vagrant is ultimately to create a Vagrant base box, which contains the minimum setup for Vagrant to operate. Additional configuration instructions for an image, such as the shell scripts it must run and networking connections, are added via the Vagrantfile.
There are several options to create a Vagrant box, in terms of parameters. For example, a DevOps engineer might add a Vagrantfile template that specifies the networking, port mapping and hardware to use, which get implemented during the initial provisioning of a Vagrant box on a client. In addition, users can configure a compression level and paths to files to include in the Vagrant box.
In the Vagrant post-processor in the Packer template below, we configure the type as Vagrant, as well as the template file and the output path of the box, which is prefixed with windows_10 and the Packer provider VirtualBox.
Run the command packer build. There is no need for variables, since they are hardcoded in this template. The only other necessary parameter in packer build is the path to the JSON template file. With Scherer's GitHub repository for the Windows 10 Vagrant box cloned locally to the C:\Scripts\packer\test directory (see below), all of the required files are included in C:\Scripts\packer\test> packer build .\windows_10.json.
The Vagrant box post-processing task shuts down the Packer VM, removes the floppy drives and port mapping, and then creates the Vagrant Open Virtualization Format file, which contains metadata on the Vagrant box. Finally, multiple files are compressed in a Vagrant box file. The box contains the VM disk file (hard disk), JSON information (metadata) and the Vagrantfile template file (instructions to provision the Vagrant VM).
In the last post we covered copying our existing CentOS 6.7 template and adding the Puppet agent in order to generate a new Packer template. In this post we will be covering how to use ovftool to convert Packer generated virtual machines into Vagrant .box files. This post will be going over the manual steps on purpose, since I feel it will make more sense when we start to cover automating the steps that you can already performed by hand.
After the files are exported, we can then compress the .ovf files into a vmware_ovf compatible .box file. Using the vmware_ovf format will provide a generic .box file that can be deployed to vCenter, vCloud Director or vCloud Air Vagrant providers.
Each of the exported template directories will need a metadata.js and Vagrantfile created. After creating the metadata.js and Vagrantfile files, we will tar all of the files in each directory into a .box file.
I am trying to create a box file (for vagrant testing of Windows 2012 R2 from an ISO), within our organisation we use desktops for sys admins to test. The box is built using packer, it goes to windows update pulls down the update and then shuts down and a .box file is created (I am happy to share the assets, they aren't exactly proprietary ).
So, you're using Vagrant, and maybe you've even read my earlier post on it, but your Vagrant box doesn't have everything you need. Or maybe it has too much, and you need something simpler. For instance, do you find yourself installing or removing packages or fixing packages to specific versions to get parity with your production platform? Or maybe you need more extensive auditing over your environment, such as when you (or your customer) can't trust a third-party box vendor. Or you need a way to clone a virtual machine for parity with the production environment. What are your options? In this blog post, I will explain what a box file is and how you can have more control over your Vagrant workflow by creating your own box. I will also introduce Packer as a tool to create a Vagrant box, and I will finish with an example for managing Vagrant box versions and distributing updates in a team setting.
Why would a development team want more control over its Vagrant boxes or want to create a custom box? This scenario may arise when a specific OS distribution or configuration is not available through the normal channels. There are various reasons for needing a custom box, such as if the virtual machine should be loaded with a special application "run" user, configured with specific yum mirrors, or have the firewall configured in a certain way.. Many customizations are simple to apply with a shell provisioner called from Vagrantfile or a Chef recipe, but many are not. The approach here is all about managing your environment and planning ahead. Distributing and maintaining a "company Vagrant box" that supports every team and project is cleaner than policing each project's Vagrantfile to be sure that customization scripts are updated regularly and applied consistently.. A network proxy illustrates this decision: Does your team have a Vagrant box with the company's proxy preconfigured, or does every Vagrantfile configure the proxy individually for each project?
Before we go any further, let's understand what, exactly, a Vagrant box is and how your system uses it. A Vagrant box is literally just an archive containing a virtual machine configuration, a virtual disk, and some other metadata files. You can see this for yourself by viewing the contents of any .box file using the tar command in a Linux or Mac OSX terminal:
When you add a box to your system with vagrant box add .. Vagrant not only copies a .box file to a special location on your hard drive, but also looks for additional metadata to extract and use. In fact, the canonical method for adding a box to inventory does not target the actual .box file directly at all, although it is capable of doing so. The natural target for the command vagrant box add is a JSON definition for the box, wherein the location of the .box file is stored and used to copy the .box file. The JSON definition also states the box name and a description field, along with listing the available versions of that box, each version potentially supporting multiple providers. Each provider section states the location of the .box file and a checksum for that version and provider. This is why, when adding a .box file directly (which does NOT contain this metadata), Vagrant requires the additional command line argument --name. (The other fields can be assumed with a default, and the box version is not supported in this case.) As a fun exercise, you can verify that adding Vagrant boxes from Atlas using the common box naming convention (e.g., hashicorp/precise64) actually downloads the metadata JSON, not a .box file. First, run vagrant box add and look in the first few output lines:
Look at the contents of the file that is saved; it is metadata JSON. Of course, the very first thing Vagrant does when it encounters this file is to search the JSON for the latest available version, find the URL of the .box file, and download it, but we are spared these details and only see the resulting Vagrant box being added to our environment.
Note that the metadata.json file contained in the .box file archive and the box definition metadata file, often itself named metadata.json, are entirely different, unrelated files. The file contained in the .box archive only states the provider for which the box was built and is inconsequential in our discussion of creating and handling custom boxes.
Below is an example of a box metadata file (named metadata.json) listing three different versions of the box. When adding such a metadata with vagrant box add .., Vagrant looks only at the latest available version, in this case 0.3.0 --Vagrant does not add all versions. A Vagrantfile behaves in the same way: for this example, setting the box value to "cert/centos7_x86_64" in Vagrantfile will use version 0.3.0 unless box_version is specified and set to an older version.
My recommendation is to use Packer. Creating the .box file by hand is really just an exercise in installing an operating system and making rote modifications to it so that it can function as Vagrant box. While it is enlightening to read Vagrant's documentation to have an understanding of just what a Vagrant box requires, the advantages of using Packer to actually create the box are numerous. The most obvious advantage is that the box itself will have been generated by a repeatable script that can be shared with the team by way of a version control system.
Should you take the manual route and generate the .box file by hand, you will at some point be left with a virtual machine from which Vagrant packaged the .box file. It is important that you keep this virtual machine around and have it named well--should you want to modify the box, all you need to do is boot up that machine, make any adjustments, and re-package it.
Many, if not all, Vagrant boxes available on Atlas are built using Packer. Think of Packer as a "Vagrant for Vagrant boxes." Vagrant and Packer perform similar tasks: both facilitate the operation of provisioning tools to customize a virtual machine. It is each tool's position in the development workflow that set them apart. While Vagrant uses a Vagrant box as a starting point for creating a virtual machine as a development platform, Packer creates that Vagrant box. While Vagrant needs a Vagrant box in a specific format to do it's job, Packer starts from nothing and builds just about anything. Enabling interoperability with provisioning tools such as Ansible, Chef, and Puppet, Packer can produce an Open Virtualization Format (OVF) file, a Docker image, an Amazon Machine Image (AMI), or a host of other artifacts. Generating a Vagrant box is just one option when running a Packer build, and actually a Vagrant box artifact is not even a primary artifact but the result of an otherwise optional post-processing step.