9408d6d0ad
* hcl2template: pass user variable values to plugins as packer_user_variables (#13686) HCL2 builds do not send the packer_user_variables config key to the builder, provisioner and post-processor plugins. Legacy JSON builds send this key (through CoreBuild.packerConfig()). Without the key, the plugin SDK keeps interpolate.Context.UserVariables nil. Then the template function {{ user "name" }} fails with 'error calling user: test'. This failure occurs in each string that a plugin interpolates at run time, for example the contents of the vagrant post-processor's vagrantfile_template. Add the function PackerConfig.userVariableValues(). This function converts the input variable values to strings, equivalent to the legacy user variables. The core sends the map at each plugin handoff point: builder, provisioner, post-processor, and enforced provisioner. The map does not contain the sensitive variables. A sensitive value goes to a plugin only if the template refers to it explicitly. The map does not contain values that are not primitive (lists, maps, objects). Legacy user variables were always strings. Co-authored-by: Claude Fable 5 <[email protected]> * Dependency upgrade (#13689) * go.mod version upgrade * actions upgrade * plugin-getter: install plugins from non-GitHub HTTP sources (#13691) Packer can only install plugins from github.com, with releases.hashicorp.com consulted first for HashiCorp-published plugins. This has been a long-standing gap for air-gapped and policy-restricted environments (#11164): the source address parser already accepts any hostname, but both existing getters reject non-github.com sources at install time. Add a remote plugin getter that installs plugins from the host named in a required_plugins source address. The host serves the directory structure of releases.hashicorp.com under the source's path: an index.json listing versions, and per version a SHA256SUMS file, the zips it lists, and - when the zip names carry no plugin protocol version - the version's manifest.json. A plugin published on releases.hashicorp.com is therefore mirrored as a verbatim copy of its tree, with every checksum file and signature upstream-authored. A plugin published as GitHub release assets is mirrored by copying each release's assets into a version directory, renaming their SHA256SUMS file to the unprefixed convention with content unchanged, and writing an index.json listing the versions. Both kinds of content can be served side by side by one host. Getter selection happens per source address: github.com sources keep the release and github getters unchanged, while any other host is served by the remote getter over HTTPS. Sources with three or more components are supported, up to the existing 16-component limit, so nested artifact-repository paths and hosts that embed the upstream origin in their path all resolve. Version discovery, constraint solving, checksum verification, and the binary naming rules match the existing getters. The installed filename is rebuilt from validated checksum-file fields and never taken from the server's response, checksum entries matching neither known naming shape are rejected rather than guessed at, and nothing the remote metadata supplies is used to fetch from another origin or path. index.json parsing is covered by fixtures captured from the live releases API, so a format change there fails tests rather than user installs. Closes #11164 * fix: update link to CONTRIBUTING.md for consistency with main branch * Merge pull request #13701 from hashicorp/sanya-hashicorp/fix-vuln Module Dependency update * build(deps): bump google.golang.org/grpc (#13704) Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.1 to 1.83.2. - [Release notes](https://github.com/grpc/grpc-go/releases) - [Commits](https://github.com/grpc/grpc-go/compare/v1.83.1...v1.83.2) --- updated-dependencies: - dependency-name: google.golang.org/grpc dependency-version: 1.83.2 dependency-type: indirect ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * [COMPLIANCE] Add/Update Copyright Headers (#13699) * [COMPLIANCE] Add/Update Copyright Headers * make generate update * make generate --------- Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com> Co-authored-by: sanya <[email protected]> Co-authored-by: Sanya <[email protected]> * Packer release 1.16.1 (#13705) * Module upgrade (#13707) --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: Erik Berg <[email protected]> Co-authored-by: Claude Fable 5 <[email protected]> Co-authored-by: Benjamin Holmes <[email protected]> Co-authored-by: elomito <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: hashicorp-copywrite[bot] <110428419+hashicorp-copywrite[bot]@users.noreply.github.com>
3.3 KiB
Packer
Packer is a tool for building identical machine images for multiple platforms from a single source configuration.
Packer is lightweight, runs on every major operating system, and is highly performant, creating machine images for multiple platforms in parallel. Packer supports various platforms through external plugin integrations, the full list of which can be found at https://developer.hashicorp.com/packer/integrations.
The images that Packer creates can easily be turned into Vagrant boxes.
Quick Start
Packer
There is a great introduction and getting started guide for building a Docker image on your local machine without using any paid cloud resources.
Alternatively, you can refer to getting started with AWS to learn how to build a machine image for an external cloud provider.
HCP Packer
HCP Packer registry stores Packer image metadata, enabling you to track your image lifecycle.
To get started with building an AWS machine image to HCP Packer for referencing in Terraform refer to the collection of HCP Packer Tutorials.
Documentation
Comprehensive documentation is viewable on the Packer website at https://developer.hashicorp.com/packer/docs.
Contributing to Packer
See CONTRIBUTING.md for best practices and instructions on setting up your development environment to work on Packer.
Contributing to Documentation
Important: Packer documentation has moved to the hashicorp/web-unified-docs repository.
To contribute documentation changes:
- Make contributions directly to the
web-unified-docsrepository - See the Updating Documentation section in CONTRIBUTING.md for detailed instructions
Unmaintained Plugins
As contributors' circumstances change, development on a community maintained plugin can slow. When this happens, HashiCorp may use GitHub's option to archive the plugin’s repository, to clearly signal the plugin's status to users.
What does unmaintained mean?
- The code repository and all commit history will still be available.
- Documentation will remain on the Packer website.
- Issues and pull requests are monitored as a best effort.
- No active development will be performed by HashiCorp.
If you are interested in maintaining an unmaintained or archived plugin, please reach out to us at [email protected].