@hashicorp
The Vagrant multi-component plugin can be used with HashiCorp Packer to create custom images.
- Official
Updated 3 months ago
- GitHub(opens in new tab)
Vagrant Cloud
Type: vagrant-cloud
Artifact BuilderId: pearkes.post-processor.vagrant-cloud
Vagrant Cloud hosts and serves boxes to Vagrant, allowing you to version and distribute boxes to an organization in a simple way.
The Vagrant Cloud post-processor enables the upload of Vagrant boxes to Vagrant Cloud. Currently, the Vagrant Cloud post-processor will accept and upload boxes supplied to it from the Vagrant or Artifice post-processors and the Vagrant builder.
You'll need to be familiar with Vagrant Cloud, have an upgraded account to enable box hosting, and be distributing your box via the shorthand name configuration.
Workflow
It's important to understand the workflow that using this post-processor enforces in order to take full advantage of Vagrant and Vagrant Cloud.
The use of this processor assume that you currently distribute, or plan to distribute, boxes via Vagrant Cloud. It also assumes you create Vagrant Boxes and deliver them to your team in some fashion.
Here is an example workflow:
- You use Packer to build a Vagrant Box for the
virtualbox
provider - The
vagrant-cloud
post-processor is configured to point to the boxhashicorp/foobar
on Vagrant Cloud via thebox_tag
configuration - The post-processor receives the box from the
vagrant
post-processor - It then creates the configured version, or verifies the existence of it, on Vagrant Cloud
- A provider matching the name of the Vagrant provider is then created
- The box is uploaded to Vagrant Cloud
- The upload is verified
- The version is released and available to users of the box
The Vagrant Cloud box (hashicorp/foobar
in this example) must already
exist. Packer will not create the box automatically. If running Packer in
automation, consider using the
Vagrant Cloud API
to create the Vagrant Cloud box if it doesn't already exist.
Configuration
The configuration allows you to specify the target box that you have access to on Vagrant Cloud, as well as authentication and version information.
Required
box_tag
(string) - The shorthand tag for your box that maps to Vagrant Cloud, for examplehashicorp/precise64
, which is short forvagrantcloud.com/hashicorp/precise64
. This box must already exist in Vagrant Cloud. Packer will not create the box automatically.version
(string) - The version number, typically incrementing a previous version. The version string is validated based on Semantic Versioning. The string must match a pattern that could be semver, and doesn't validate that the version comes after your previous versions.access_token
(string) - Your access token for the Vagrant Cloud API. This can be generated on your tokens page. If not specified, the environment will be searched. First,VAGRANT_CLOUD_TOKEN
is checked, and if nothing is found, finallyATLAS_TOKEN
will be used. This is required unless you are using a private hosting solution (i.e.vagrant_cloud_url
has been populated).or
vagrant_cloud_url
(string) - Override the base URL for Vagrant Cloud. This is useful if you're using Vagrant Private Cloud in your own network. Defaults tohttps://vagrantcloud.com/api/v2
. If this value is set to something other than the default thenaccess_token
can be left blank and noAuthorization
header will be added to requests sent by this post-processor.
Optional
architecture
(string) - The architecture of the Vagrant box. This will be detected from the box if possible by default. Supported values: amd64, i386, arm, arm64, ppc64le, ppc64, mips64le, mips64, mipsle, mips, and s390x.default_architecture
(string) - The architecture that should be flagged as the default architecture for this provider. See the Vagrant Cloud documentation for more information.no_release
(boolean) - If set to true, does not release the version on Vagrant Cloud, making it active. You can manually release the version via the API or Web UI. Defaults tofalse
.insecure_skip_tls_verify
(boolean) - If set to true andvagrant_cloud_url
is set to something different than its default, it will set TLS InsecureSkipVerify to true. In other words, this will disable security checks of SSL. You may need to set this option to true if your host atvagrant_cloud_url
is using a self-signed certificate.keep_input_artifact
(boolean) - When true, preserve the local box after uploading to Vagrant cloud. Defaults totrue
.version_description
(string) - Optional Markdown text used as a full-length and in-depth description of the version, typically for denoting changes introducedbox_download_url
(string) - Optional URL for a self-hosted box. If this is set the box will not be uploaded to the Vagrant Cloud. This is a template engine. Therefore, you may use user variables and template functions in this field. The following extra variables are also available in this engine:Architecture
: The architecture of the Vagrant boxProvider
: The Vagrant provider the box is forArtifactId
: The ID of the input artifact.
box_checksum
(string) - Optional checksum for the provider .box file. The type of the checksum is specified within the checksum field as a prefix, ex: "md5:{$checksum}". Valid values are:- null or ""
- "md5:{$checksum}"
- "sha1:{$checksum}"
- "sha256:{$checksum}"
- "sha512:{$checksum}" See https://www.vagrantup.com/vagrant-cloud/api#arguments-7
no_direct_upload
(boolean) - Whentrue
, upload the box artifact through Vagrant Cloud instead of directly to the backend storage.
Use with the Vagrant Post-Processor
An example configuration is shown below. Note the use of the post-processors block that wraps both the Vagrant and Vagrant Cloud post-processor blocks within the post-processor section. Chaining the post-processors together in this way tells Packer that the artifact produced by the Vagrant post-processor should be passed directly to the Vagrant Cloud Post-Processor. It also sets the order in which the post-processors should run.
Failure to chain the post-processors together in this way will result in the wrong artifact being supplied to the Vagrant Cloud post-processor. This will likely cause the Vagrant Cloud post-processor to error and fail.
JSON
HCL2
Use with the Artifice Post-Processor
An example configuration is shown below. Note the use of the nested array that wraps both the Artifice and Vagrant Cloud post-processors within the post-processor section. Chaining the post-processors together in this way tells Packer that the artifact produced by the Artifice post-processor should be passed directly to the Vagrant Cloud Post-Processor. It also sets the order in which the post-processors should run.
Failure to chain the post-processors together in this way will result in the wrong artifact being supplied to the Vagrant Cloud post-processor. This will likely cause the Vagrant Cloud post-processor to error and fail.
Note that the Vagrant box specified in the Artifice post-processor files
array
must end in the .box
extension. It must also be the first file in the array.
Additional files bundled by the Artifice post-processor will be ignored.
JSON
HCL2