init Command

Note: Packer init does not work with legacy JSON templates. You can upgrade your JSON config files to HCL using the hcl2_upgrade command.

Note: Packer init will only work with multi-component plugins -- that is plugins that are named packer-plugin-*. To install a single-component plugin -- that is packer-provisioner-*, packer-builder-*, etc. -- nothing changes, you will have to install the plugin manually.

The packer init command is used to download Packer plugin binaries. This is the first command that should be executed when working with a new or existing template. This command is always safe to run multiple times. Though subsequent runs may give errors, this command will never delete anything.

You should invoke packer init on either an HCL2 template, or a directory that contains at least a valid HCL2 template, and eventually other related dependencies like varfiles for example.

Example:

$ ls .
template.pkr.hcl varfile.pkrvars.pkr.hcl

$ packer init template.pkr.hcl # You can invoke packer init on a single template in this case
                               # This works if the template is self-contained, but may fail if
                               # the template is meant to be built as a bundle of partials.

$ packer init .                # Alternatively, you can invoke packer init on a directory instead,
                               # which behaves the same in a configuration like this one, but if
                               # the target is a collection ofHCL2 templates, this is the
                               # preferred way to invoke it.

Packer does not currently have the notion of a state like Terraform has. In other words, currently packer init is only in charge of installing Packer plugins.

Currently, packer init can only fetch binaries from public projects on GitHub. GitHub's public API, limits the number of unauthenticated requests per hour one IP can do. Packer will do its best to avoid hitting those limits and in an average local usage this should not be an issue. Otherwise you can set the PACKER_GITHUB_API_TOKEN env var in order to get more requests per hour. Go to your personal access token page to generate a new token.

packer init will list all installed plugins then download the latest versions for the ones that are missing.

packer init -upgrade will try to get the latest versions for all plugins.

Import a plugin using the required_plugin block :

packer {
  required_plugins {
    happycloud = {
      version = ">= 2.7.0"
      source = "github.com/azr/happycloud"
    }
  }
}

HashiCorp does not officially verify third party Packer plugins, plugins not under the HashiCorp namespace hashicorp/*; as with all community tools, please do your own due diligence when using a new tool.

Plugin Selection

Plugin selection depends on the source and version constraints defined within the required_plugins block. For each of the required plugins Packer will query the source repository github.com/azr/happycloud whose fully qualified address is https://github.com/azr/packer-plugin-happycloud for a plugin matching the version constraints for the host operating system.

Packer init will install the latest found version matching the version selection in the required_plugins section. Make sure to set a correct version constraint string. The plugins will be installed in the Plugin Directory.

See Installing Plugins for more information on how plugin installation works.

Options

-upgrade - On top of installing missing plugins, update installed plugins to the latest available version, if there is a new higher one. Note that this still takes into consideration the version constraint of the config.