@ -18,11 +18,11 @@ We recommend running the `packer init` command as the first step when working wi
### Third-party plugin verification
HashiCorp only verifies plugins from GitHub under the`hashicorp/*` namespace. We recommend that you vet and verify any third-party plugins you want to install.
We recommend that you vet and verify any third-party plugins you want to install.
### Installation location
By default, Packer installs plugins into the plugins directory at `$HOME/.config/packer/plugins` on Unix and `%APPDATA%\packer.d\plugins` on Windows, but you can specify a different directory using the `PACKER_PLUGIN_PATH` environment variable. Refer to the [Packer configuration reference](/packer/docs/configure) for additional information.
By default, Packer installs plugins into the plugins directory at `$HOME/.config/packer/plugins` on Unix and `%APPDATA%\packer.d\plugins` on Windows, but you can specify a different directory using the `PACKER_PLUGIN_PATH` environment variable. Refer to the [Packer configuration reference](/packer/docs/configure) for additional information.
## Usage
Use the following syntax to run the `packer init` command:
- `<plugin-binary-source>`: A local or remote source where the plugin binary is available. To download from a remote source, the plugin must be hosted on GitHub. For local binaries, you must also include the `--path` option. Refer to [Installing Plugins](/packer/docs/plugins/install) for additional information about installing plugins.
- `<plugin-binary-source>`: A remote source where the plugin binary is available. To remotely download from a source, the plugin must be hosted on GitHub. For locally-sourced binaries, you must also include the `--path` option. Refer to [Installing Plugins](/packer/docs/plugins/install) for additional information about installing plugins.
- `<plugin version>`: A specific version of the plugin to download and install. Packer accepts semantic version numbers that follow the `<major>.<minor>.<patch>` format. If omitted, the command installs the latest plugin version.
@ -20,7 +20,7 @@ You can place internal configuration files into Packer's `config` directory. Pac
| OS | Path | Notes |
| --- | ---| --- |
| Unix | `${HOME}/.config/packer/` | Packer follows the XDG base directory specification by default. As a result, Packer uses `$HOME/.config/packer` as the default directory when the `PACKER_CONFIG_DIR` environment variable is unset or empty. Packer ignores the XDG specification when the `PACKER_CONFIG_DIR` variable is set or when the installation uses `.packer.d`-style directories, for example `$HOME/.packer.d/`. Refer to the [XDG specification](https://specifications.freedesktop.org/basedir-spec/latest/) for additional information. |
| Unix | `${HOME}/.config/packer/` | Packer follows the XDG base directory specification by default. As a result, Packer uses `$HOME/.config/packer` as the default directory when the `PACKER_CONFIG_DIR` environment variable is unset or empty. Packer ignores the XDG specification when the `PACKER_CONFIG_DIR` variable is set or when the installation uses legacy `.packer.d`-style directories, for example `$HOME/.packer.d/`. Refer to the [XDG specification](https://specifications.freedesktop.org/basedir-spec/latest/) for additional information. |
| Windows | `%APPDATA%\packer.d\` | |
@ -51,7 +51,7 @@ Use basic JSON to configure the file. You can specify the configuration paramete
configuration file. All parameters are optional. None of these are required, since all have defaults.
- `plugin_min_port`: Number that specifies the lowest port that Packer can use for communicating with plugins. Packer communicates with plugins over TCP connections on your local host. Default is `10000`. We recommend setting a wide range between `plugin_min_port` and `plugin_max_port` so that Packer has access to at least 25 ports on a single run.
- `plugin_max_port`: Number that specifies highest port that Packer can for communicating with plugins. Packer communicates with plugins over TCP connections on your local host. Default is `25000`. We recommend setting a wide range between `plugin_min_port` and `plugin_max_port` so that Packer has access to at least 25 ports on a single run.
- `plugin_max_port`: Number that specifies highest port that Packer can for communicating with plugins. Packer communicates with plugins over TCP connections on your local Unix host. Default is `25000`. We recommend setting a wide range between `plugin_min_port` and `plugin_max_port` so that Packer has access to at least 25 ports on a single run.
- `builders`: Specifies a type of object that installs plugins. Refer to [Builders](/packer/docs/builders) for additional information.
- `commands`: Specifies a type of object that installs plugins.
- `post-processors`: Specifies a type of object that installs plugins. Refer to [Post-Processors](/packer/docs/post-processors) for additional information.
@ -10,7 +10,7 @@ This topic provides overview information about installing and loading Packer plu
## Introduction
The Packer binary includes a set of built-in plugins that run automatically, but you also define a list of external plugins in your template for Packer to run and communicate with throughout the build. These external plugins extend Packer functionality without modifying the core source code. Packer launches one plugin process for each component in the build.
The Packer binary includes a set of built-in plugins that run automatically, but you can also define a list of external plugins in your template for Packer to run and communicate with throughout the build. These external plugins extend Packer functionality without modifying the core source code. Packer launches one plugin process for each component in the build.
description: Learn about the changes in Packer v 1.11
---
@ -13,7 +13,7 @@ This release includes the following updates.
### Predictable plugin loading
To boost stability, Packer no longer loads plugin binaries installed outside of its plugin directory. Additionally, Packer now only loads binaries that have accompanying SHA256SUM files. In previous versions, Packer automatically loads plugins placed in one of the known directories when the file is named according to one of the following naming conventions:
To boost stability, Packer no longer loads plugin binaries installed outside of its plugin directory. Additionally, Packer now only loads binaries that have an accompanying SHA256SUM file. In previous versions, Packer automatically loads plugins placed in one of the known directories when the file is named according to one of the following naming conventions:
@ -26,7 +26,7 @@ The following features, workflows, and components are deprecated and are no long
### Legacy single-component plugins
Packer no longer loads single-component plugins, such as legacy plugins that follow the deprecated naming convention of `packer-builder-<name>` or `packer-provisioner-<name>-<name>`. Packer only supports multi-component plugins, such as the Docker plugin for Packer.
Packer no longer supports single-component plugins, such as legacy plugins that follow the deprecated naming convention of `packer-builder-<name>` or `packer-provisioner-<name>`. Packer only supports multi-component plugins, such as the Docker plugin for Packer.
### Loading plugin binaries named `packer-plugin-<name>`
trujillo-adam
2 years ago
committed by
Lucas Bajolet