The Packer team is excited to announce the release of the Packer Plugin SDK, a standalone Go module for developing Packer plugins.
In Packer, a component is a builder, provisioner, or post-processor. Packer has many built-in components, and historically many users of Packer have depended purely on the built-ins to run their builds. Plugins are standalone binaries that can supply extra, specialized components. Packer’s main codebase loads and runs these plugins, which can then work together with the Packer built-ins to create highly customizable Packer builds. Packer plugins are a key feature that allows Packer to build images on almost any infrastructure type using a wide range of provisioning tools.
As Packer has grown in adoption, it has become apparent that the reliance upon built-in components limits community developers who want to create their own builders, provisioners, and post-processors. Contributors who have gotten their community components merged with the Packer must wait for a maintainer to review, merge, and release changes before their users can benefit from updates to their components.
To support Packer’s continued evolution and growing ecosystem, we are excited to announce the Packer plugin SDK as part of its v1.7.0 release. The SDK makes it easier for third-party developers to create, maintain, release, and share their components as plugins.
Previously, when developing a plugin, you had to use a number of convenience tools embedded within the codebase with little documentation. As a result, plugin development could be difficult to follow and many unused dependencies were imported.
This complex set of embedded tools made the barrier to entry for creating and maintaining Packer plugins higher than it needed to be.
The Packer Plugin SDK extracts the required plugin interfaces from the Packer repository into a standalone Go module. Packer plugins can now import the Packer Plugin SDK and use its API, which is explicitly available for Packer plugin functionality. We hope this change lowers the barrier to entry for creating Packer plugins.
Packer Plugin SDK v0.1.0 is designed for compatibility with Packer v1.7.0. In future versions, the SDK will be versioned separately from the main Packer codebase. Improvements to the SDK will start from the 0.1.0 baseline and follow a semantic versioning scheme compatible with Go modules. The informal SDK within the Core repository has been removed.
The new SDK offers some new features, including support for plugins that contain multiple components. A single plugin can bundle together builders, post-processors, and provisioners that are all specific to a certain technology. This feature will hopefully reduce the maintenance burden for a plugin.
Finally, the new SDK supports the new
packer init command. Users can declare their desired plugins and plugin versions and Packer will automatically download them.
If you only use components currently built into the Packer, nothing changes for you.
If you use community-built plugins, you will need to obtain a new version of the plugin when you upgrade to Packer v1.7.0. Previous versions of the plugin will not be compatible.
If you maintain a community-plugin, you will need to upgrade your plugin to use the SDK. We have an upgrade guide and a CLI tool to help you.
If you’re interested in getting started creating a plugin of your own, check out our updated documentation for writing plugins. To see a presentation and demo of the Packer Plugin Repository and the
packer init command, watch our recent HashiTalk: The Packer Plugin Repository, What’s init?
HashiCorp adopts the community-created HCL Extension for Visual Studio Code and adds HCL 2.0 support.
The HashiCorp Releases API is now available. This API is your one-stop shop for finding and viewing extended metadata about HashiCorp product releases.
Several of this year’s HashiTalks speakers presented useful Terraform, Packer, and CI/CD tips and tricks. Learn from this list of highlights.