The packer build command takes a template and runs all the builds within it in order to generate a set of artifacts. The various builds specified within a template are executed in parallel, unless otherwise specified. And the artifacts that are created will be outputted at the end of the build.

» Options -color=false - Disables colorized output. Enabled by default.

-debug - Disables parallelization and enables debug mode. Debug mode flags the builders that they should output debugging information. The exact behavior of debug mode is left to the builder. In general, builders usually will stop between each step, waiting for keyboard input before continuing. This will allow the user to inspect state and so on.

-except=foo,bar,baz - Builds all the builds except those with the given comma-separated names. Build names by default are the names of their builders, unless a specific name attribute is specified within the configuration.

-force - Forces a builder to run when artifacts from a previous build prevent a build from running. The exact behavior of a forced build is left to the builder. In general, a builder supporting the forced build will remove the artifacts from the previous build. This will allow the user to repeat a build without having to manually clean these artifacts beforehand.

-on-error=cleanup (default), -on-error=abort, -on-error=ask - Selects what to do when the build fails. cleanup cleans up after the previous steps, deleting temporary files and virtual machines. abort exits without any cleanup, which might require the next build to use -force. ask presents a prompt and waits for you to decide to clean up, abort, or retry the failed step.

-only=foo,bar,baz - Only build the builds with the given comma-separated names. Build names by default are the names of their builders, unless a specific name attribute is specified within the configuration.

-parallel=false - Disable parallelization of multiple builders (on by default).

-var - Set a variable in your packer template. This option can be used multiple times. This is useful for setting version numbers for your build.

-var-file - Set template variables from a file.

The packer fix command takes a template and finds backwards incompatible parts of it and brings it up to date so it can be used with the latest version of Packer. After you update to a new Packer release, you should run the fix command to make sure your templates work with the new release.

The fix command will output the changed template to standard out, so you should redirect standard using standard OS-specific techniques if you want to save it to a file. For example, on Linux systems, you may want to do this:

$ packer fix old.json > new.json If fixing fails for any reason, the fix command will exit with a non-zero exit status. Error messages appear on standard error, so if you're redirecting output, you'll still see error messages.

Even when Packer fix doesn't do anything to the template, the template will be outputted to standard out. Things such as configuration key ordering and indentation may be changed. The output format however, is pretty-printed for human readability.

The full list of fixes that the fix command performs is visible in the help output, which can be seen via packer fix -h.

» Options -validate=false - Disables validation of the fixed template. True by default.

The packer inspect command takes a template and outputs the various components a template defines. This can help you quickly learn about a template without having to dive into the JSON itself. The command will tell you things like what variables a template accepts, the builders it defines, the provisioners it defines and the order they'll run, and more.

This command is extra useful when used with machine-readable output enabled. The command outputs the components in a way that is parseable by machines.

The command doesn't validate the actual configuration of the various components (that is what the validate command is for), but it will validate the syntax of your template by necessity.

» Usage Example Given a basic template, here is an example of what the output might look like:

$ packer inspect template.json Variables and their defaults:

aws_access_key = aws_secret_key =

Builders:

amazon-ebs amazon-instance virtualbox-iso

Provisioners:

shell

The Packer and Artifact Registry features of Atlas will no longer be actively developed or maintained and will be fully decommissioned. Please see our guide on building immutable infrastructure with Packer on CI/CD for ideas on implementing these features yourself.

The packer push command uploads a template and other required files to the Atlas service, which will run your packer build for you. Learn more about Packer in Atlas.

Running builds remotely makes it easier to iterate on packer builds that are not supported on your operating system, for example, building docker or QEMU while developing on Mac or Windows. Also, the hard work of building VMs is offloaded to dedicated servers with more CPU, memory, and network resources.

When you use push to run a build in Atlas, you may also want to store your build artifacts in Atlas. In order to do that you will also need to configure the Atlas post-processor. This is optional, and both the post-processor and push commands can be used independently.

The push command uploads your template and other files, like provisioning scripts, to Atlas. Take care not to upload files that you don't intend to, like secrets or large binaries. If you have secrets in your Packer template, you should move them into environment variables.

Most push behavior is configured in your packer template. You can override or supplement your configuration using the options below.

» Options -token - Your access token for the Atlas API. Login to Atlas to generate an Atlas Token. The most convenient way to configure your token is to set it to the ATLAS_TOKEN environment variable, but you can also use -token on the command line.

-name - The name of the build in the service. This typically looks like hashicorp/precise64, which follows the form /. This must be specified here or in your template.

-sensitive - A comma-separated list of variables that should be marked as sensitive in the Terraform Enterprise ui. These variables' keys will be visible, but their values will be redacted. example usage: -var 'supersecretpassword=mypassword' -sensitive=supersecretpassword1

-var - Set a variable in your packer template. This option can be used multiple times. This is useful for setting version numbers for your build.

-var-file - Set template variables from a file.

» Environment Variables ATLAS_CAFILE (path) - This should be a path to an X.509 PEM-encoded public key. If specified, this will be used to validate the certificate authority that signed certificates used by an Atlas installation.

ATLAS_CAPATH - This should be a path which contains an X.509 PEM-encoded public key file. If specified, this will be used to validate the certificate authority that signed certificates used by an Atlas installation.

» Examples Push a Packer template:

$ packer push template.json Push a Packer template with a custom token:

$ packer push -token ABCD1234 template.json » Limits push is limited to 5gb upload when pushing to Atlas. To be clear, packer can build artifacts larger than 5gb, and Atlas can store artifacts larger than 5gb. However, the initial payload you push to start the build cannot exceed 5gb. If your boot ISO is larger than 5gb (for example if you are building OSX images), you will need to put your boot ISO in an external web service and download it during the packer run.

» Building Private .iso and .dmg Files If you want to build a private .iso file you can upload the .iso to a secure file hosting service like Amazon S3, Google Cloud Storage, or Azure File Service and download it at build time using a signed URL. You should convert .dmg files to .iso and follow a similar procedure.

Once you have added variables in your packer template you can specify credentials or signed URLs using Atlas environment variables, or via the -var flag when you run push.

The packer validate Packer command is used to validate the syntax and configuration of a template. The command will return a zero exit status on success, and a non-zero exit status on failure. Additionally, if a template doesn't validate, any error messages will be outputted.

Example usage:

$ packer validate my-template.json Template validation failed. Errors are shown below.

Errors validating build 'vmware'. 1 error(s) occurred:

• Either a path or inline script must be specified. » Options -syntax-only - Only the syntax of the template is checked. The configuration is not validated.

-except=foo,bar,baz - Builds all the builds except those with the given comma-separated names. Build names by default are the names of their builders, unless a specific name attribute is specified within the configuration.

-only=foo,bar,baz - Only build the builds with the given comma-separated names. Build names by default are the names of their builders, unless a specific name attribute is specified within the configuration.

-var - Set a variable in your packer template. This option can be used multiple times. This is useful for setting version numbers for your build.

-var-file - Set template variables from a file.