Since the beginning of the project, HashiCorp Packer has supported extending its capabilities through plugins. These plugins are built alongside community contributors and partners to help Packer support building images for many cloud providers and hypervisors. In the past, to help Packer users get up and running quickly, popular plugins were bundled into the main Packer binary. This had advantages, notably that users did not have to install plugins separately in order to use them.
However, as the plugin system grew, bundling all plugins introduced maintenance issues:
- It prevented releasing plugins separately from Packer. Every time someone fixed a bug, they had to open a pull request on Packer, get it approved and merged, then wait until a new release of Packer in order to benefit from this change.
- It made Packer heavier. Bundling the code for the plugins, and their dependencies, had a negative impact on the final binary's size, and therefore the memory usage of Packer itself.
- This workflow made it harder for community-backed plugins to gain traction.
Separating the plugins from Packer allows anyone in the community to implement the components they want, independently from Packer, and make them available to other Packer practitioners.
Because of these advantages, Packer 1.7 started separating plugins from Packer core into multi-component plugin binaries that could be installed manually or through Packer itself, with subcommands like packer init or packer plugins.
Bundled plugins
The separation of plugins from Packer core, if done in a break-once manner, would have caused grief among the community, as Packer would have stopped delivering those plugins and forced users to manage their plugins manually from that point on. So we continued bundling in a subset of plugins and kept them as up-to-date as possible with Packer's release cycle, which differs from the plugins’ cycle. While this solution helped to avoid breaking everyone's configurations, it’s now time to move away from bundled plugins.
Packer users may have noticed that version 1.9 shipped with no community plugins bundled into Packer, leaving only plugins officially supported by HashiCorp as part of the bundled plugins in Packer. With the next minor release of Packer — version 1.10 — we aim to complete this transition away from the bundled plugins, and remove the following plugins from Packer:
- packer-plugin-amazon
- packer-plugin-ansible
- packer-plugin-azure
- packer-plugin-docker
- packer-plugin-googlecompute
- packer-plugin-qemu
- packer-plugin-vagrant
- packer-plugin-vmware
- packer-plugin-vsphere
Once removed, these plugins will have to be managed through local installations.
We understand that some plugins may be critical to existing user workflows, so we are sharing our plans for the removal of bundled plugins to assist users in navigating the change. Users already managing external plugins via packer init or packer plugins install will not be affected by these changes.
Managing plugin installation
Along with the creation of multi-component plugins starting in Packer version 1.7, tooling was added to Packer for managing the installation of external plugins. In recent versions of Packer, we have focused on the tooling to simplify the managing of external plugins for all users regardless of their template.
The commands packer init and packer plugins install will become the standard way to manage local installations of plugins, so users always benefit from the version that best fits their build workflow.
packer init
This command is the preferred way to install plugins for HCL2 templates, as it works in tandem with information linked to your templates directly. In HCL2 templates, you can define which plugins your template relies on, through the required_plugins block. For each plugin defined in this block, you can set a version constraint, which is then leveraged by packer init to get the version of the plugins most appropriate to build your template.
The required_plugins block effectively lets you pin a specific version of the plugin to run your builds on. This way, if a release causes a problem for your builds, you can circumvent the new problem with this construct while a fix is found and a new version is released.
For more information on packer init, and the required_plugins block, please refer to our init command documentation on developer.hashicorp.com.
packer plugins
This command is not limited to HCL2 and does not require any changes to existing templates. Users of the legacy JSON templates can rely on this command to manage their plugin installations. With packer plugins install, you will be able to install any version of a plugin on demand; but you will have to invoke the command for each individual plugin you may wish to install.
As with packer init, you can find more information on the command in our plugins documentation on developer.hashicorp.com.
Next steps
Starting with Packer 1.9.2 (released July 19, 2023), templates relying on the usage of bundled plugins will trigger a warning in Packer's standard output indicating your template's reliance on a bundled plugin, along with steps you can take to resolve the warning. The bundled plugins listed above will be officially removed from Packer in 1.10, tentatively scheduled for November 2023.
from HashiCorp Blog https://bit.ly/3PrWH3u
via IFTTT
No comments:
Post a Comment