upstream/packer
1
0
Fork 0
mirror of https://github.com/hashicorp/packer.git synced 2026-05-28 04:35:38 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

Fix capitalizations in docs

Browse source 
* Brands (HashiCorp, VMware)
* Various OS/languages (Windows, Unix, Linux, POSIX, Python, PowerShell)
* Various abbreviations (ID, VM, HTTP)
This commit is contained in:
Dan Barr 2022-08-04 18:42:53 -04:00 committed by Wilken Rivera
parent 0c9c3fe48c
commit ab29b187b1
40 changed files with 119 additions and 119 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
website/README.md
View file

@ -45,7 +45,7 @@ The website can be run locally through node.js or [Docker](https://www.docker.co
Running the site locally is simple. Provided you have Docker installed, clone this repo, run `make`, and then visit `http://localhost:3000`.
The docker image is pre-built with all the website dependencies installed, which is what makes it so quick and simple, but also means if you need to change dependencies and test the changes within Docker, you'll need a new image. If this is something you need to do, you can run `make build-image` to generate a local Docker image with updated dependencies, then `make website-local` to use that image and preview.
The Docker image is pre-built with all the website dependencies installed, which is what makes it so quick and simple, but also means if you need to change dependencies and test the changes within Docker, you'll need a new image. If this is something you need to do, you can run `make build-image` to generate a local Docker image with updated dependencies, then `make website-local` to use that image and preview.
### With Node

4
website/content/community-tools.mdx
View file

@ -65,8 +65,8 @@ contribution here!
- [packer-config](https://github.com/ianchesal/packer-config) - a Ruby model that lets you build Packer configurations in Ruby
- [racker](https://github.com/aspring/racker) - an opinionated Ruby DSL for generating Packer templates
- [packerlicious](https://github.com/mayn/packerlicious) - a python library for generating Packer templates
- [packer.py](https://github.com/mayn/packer.py) - a python library for executing Packer CLI commands
- [packerlicious](https://github.com/mayn/packerlicious) - a Python library for generating Packer templates
- [packer.py](https://github.com/mayn/packer.py) - a Python library for executing Packer CLI commands
## Other

4
website/content/docs/commands/hcl2_upgrade.mdx
View file

@ -75,7 +75,7 @@ variable "aws_secret_key" {
## Go template functions
`hcl2_upgrade` will do its best to transform your go _template calls_ to HCL2,
`hcl2_upgrade` will do its best to transform your Go _template calls_ to HCL2,
here is the list of calls that should get transformed:
- `` {{ user `my_var` }} `` becomes `${var.my_var}`.
@ -87,7 +87,7 @@ here is the list of calls that should get transformed:
will be created for all generated files.
- `` {{ build `ID` }} `` becomes `${build.ID}`.
The rest of the calls should remain go template calls for now, this will be
The rest of the calls should remain Go template calls for now, this will be
improved over time.
-> **Note**: The `hcl2_upgrade` command does its best to transform template

10
website/content/docs/communicators/winrm.mdx
View file

@ -17,7 +17,7 @@ The WinRM communicator is not the default communicator, so you will always have
to set the `"communicator": "winrm",` template option explicitly. In addition,
you will almost always have to provide a pre-run script that enables and
configures WinRM on the guest machine. This will generally be in the form of a
powershell script or a batch file.
PowerShell script or a batch file.
If you are building from a brand-new and unconfigured operating system
image, you will need to provide this pre-run script as part of your
@ -58,7 +58,7 @@ to be able to connect via WinRM
6. If necessary, generate a self-signed certificate or provide a real certificate
to the WinRM listener.
#### Configuring WinRM in VMWare
#### Configuring WinRM in VMware
If you are configuring WinRM using an Autounattend.xml, the simplest way to set
up WinRM is to put the configuration commands directly into the Autounattend
@ -84,7 +84,7 @@ Autounattend file.
</FirstLogonCommands>
```
It is also possible to call powershell scripts in a similar manner.
It is also possible to call PowerShell scripts in a similar manner.
The winrmConfig.bat referenced above can be as simple as
@ -108,7 +108,7 @@ Please note that the above batch file is _extremely_ simplistic, and not secure.
It is intended to be an example of the bare minimum configuration. Below, you'll
find a more complicated example of a more secure WinRM configuration process.
This batch file will only work for http connections, not https, but will enable
This batch file will only work for HTTP connections, not HTTPS, but will enable
you to connect using only the username and password created earlier in the
Autounattend file. The above batchfile will allow you to connect using a very
simple Packer config:
@ -119,7 +119,7 @@ simple Packer config:
"winrm_password": "SecretPassword"
```
A more complex example of a powershell script used for configuration can be seen
A more complex example of a PowerShell script used for configuration can be seen
below.
```powershell

16
website/content/docs/configure.mdx
View file

@ -19,7 +19,7 @@ Plugins and core configuration files can exist in the home directory of Packer.
The home directory of Packer will be the first one of the following env values
to be set :
| unix | windows |
| Unix | Windows |
| ---------------------- | --------------------- |
| `${PACKER_CONFIG_DIR}` | `%PACKER_CONFIG_DIR%` |
| `${APPDATA}` | `%APPDATA%` |
@ -34,7 +34,7 @@ to be set :
Packer can optionally read a JSON file for the end user to set core settings.
The config file of Packer will be looked up on the following paths:
| unix | windows |
| Unix | Windows |
| ------------------------------- | -------------------------------- |
| `${PACKER_CONFIG}` | `%PACKER_CONFIG%` |
| `PACKER_HOME_DIR/.packerconfig` | `PACKER_HOME_DIR/packer.config/` |
@ -46,18 +46,18 @@ The config file of Packer will be looked up on the following paths:
Packer's configuration directory can potentially contain plugins and internal
Packer files. The config dir of Packer will be looked up on the following paths:
| unix | windows |
| Unix | Windows |
| --------------------------- | --------------------------- |
| `PACKER_HOME_DIR/.packer.d` | `PACKER_HOME_DIR/packer.d/` |
Examples:
- On a 'unix' system, if the `$PACKER_CONFIG_DIR` env var is set to
- On a Unix system, if the `$PACKER_CONFIG_DIR` env var is set to
`/home/packer`, the config directory will be: `/home/packer/.packer.d/` and
other values will not be checked.
- On a 'unix' system, if the `HOME` env var is `/home/azr` or the `USER` env var
- On a Unix system, if the `HOME` env var is `/home/azr` or the `USER` env var
is `azr`, then the config directory will default to `/home/azr/.packer.d/`.
- On a 'windows' system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the
- On a Windows system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the
config directory will be: `C:/packer.d/` and other values will not be checked.
## Packer's plugin directory
@ -139,8 +139,8 @@ each can be found below:
- `PACKER_PLUGIN_PATH` - a PATH variable for finding third-party packer
plugins. For example: `~/custom-dir-1:~/custom-dir-2`. Separate directories in
the PATH string using a colon (`:`) on posix systems and a semicolon (`;`) on
windows systems. The above example path would be able to find a provisioner
the PATH string using a colon (`:`) on POSIX systems and a semicolon (`;`) on
Windows systems. The above example path would be able to find a provisioner
named `packer-provisioner-foo` in either
`~/custom-dir-1/packer-provisioner-foo` or
`~/custom-dir-2/packer-provisioner-foo`. See the documentation on [plugin

6
website/content/docs/debugging.mdx
View file

@ -81,7 +81,7 @@ homed in on the problem is usually enough.
### Debugging Packer in Powershell/Windows
In Windows you can set the detailed logs environmental variable `PACKER_LOG` or
the log variable `PACKER_LOG_PATH` using powershell environment variables. For
the log variable `PACKER_LOG_PATH` using PowerShell environment variables. For
example:
```powershell
@ -138,10 +138,10 @@ On Unix systems, you can check what your file descriptor limit is with
## Issues when using long temp directory
Packer uses unix sockets internally, which are created inside the default
Packer uses Unix sockets internally, which are created inside the default
directory for temporary files. Some operating systems place a limit on the
length of the socket name, usually between 80 and 110 characters. If you get an
error like this (for any builder, not just docker):
error like this (for any builder, not just Docker):
```text
Failed to initialize build 'docker': error initializing builder 'docker': plugin exited before we could connect

2
website/content/docs/index.mdx
View file

@ -8,7 +8,7 @@ page_title: Documentation
[Packer](https://www.packer.io/) is an open source tool that enables you to create identical machine images for multiple platforms from a single source template. A common use case is creating "golden images" that teams across an organization can use in cloud infrastructure.
To install Packer and learn the standard Packer workflow, try the [Get Started tutorials](https://learn.hashicorp.com/packer) on Hashicorp Learn.
To install Packer and learn the standard Packer workflow, try the [Get Started tutorials](https://learn.hashicorp.com/packer) on HashiCorp Learn.
## HCP Packer

2
website/content/docs/partnerships.mdx
View file

@ -38,7 +38,7 @@ Main Packer categories for partners to integrate with include:
- **Data Sources**
- Data Sources allow users to retrieve values from a remote API and store them as variables in the Packer configuration template. An example is the [AWS secrets manager](/docs/datasources/amazon/secretsmanager) data source.
- **Builders**
- Builders manage the VM lifecycle. They manage launching a vm/instance, running provisioners against that instance, shutting the instance down, and saving an artifact image from that instance. Your builder handles all of the setup and cleanup costs associated with creating the output image artifact.
- Builders manage the VM lifecycle. They manage launching a VM/instance, running provisioners against that instance, shutting the instance down, and saving an artifact image from that instance. Your builder handles all of the setup and cleanup costs associated with creating the output image artifact.
- **Provisioners**
- Provisioners are run against the instance launched by the builder. They generally provide an interface for interacting with a particular provisioning tool, such as Ansible, Puppet, or Chef.
- **Post-Processors**

2
website/content/docs/plugins/creation/custom-builders.mdx
View file

@ -11,7 +11,7 @@ Packer Builders are the components of Packer responsible for creating a
virtual machine, bringing it to a point where it can be provisioned, and then
turning that provisioned virtual machine into a machine image. Several builders
are officially maintained and distributed by the HashiCorp Packer team -- among
these are builders for creating images on Amazon EC2, VMWare, Google
these are builders for creating images on Amazon EC2, VMware, Google
Compute Engine, and many more. You can find documentation for how to use these
official builders [here](/docs/builders). It is also possible to write custom
builders using the Packer plugin interface, and this page documents how to do

2
website/content/docs/plugins/creation/index.mdx
View file

@ -28,7 +28,7 @@ recommend getting a bit more comfortable before you dive into writing plugins.
### Plugin System Architecture
A Packer plugin is just a go binary. Instead of loading plugins directly into a
A Packer plugin is just a Go binary. Instead of loading plugins directly into a
running application, Packer runs each plugin as a _separate application_.
The multiple separate Packer plugin processes communicate with the Core using
an RPC defined in the packer-plugin SDK. The Packer core itself is responsible

2
website/content/docs/plugins/hcp-support.mdx
View file

@ -46,7 +46,7 @@ type Image struct {
// Labels represents additional details about an image that a builder or post-processor may with to provide for a given build.
// Any additional metadata will be made available as build labels within a HCP Packer registry iteration.
Labels map[string]string
// SourceImageID is the cloud image id of the image that was used as the
// SourceImageID is the cloud image ID of the image that was used as the
// source for this image. If set, the HCP Packer registry will be able
// link the parent and child images for ancestry visualizations and
// dependency tracking.

8
website/content/docs/post-processors/artifice.mdx
View file

@ -6,9 +6,9 @@ description: >
artifacts you specify. The primary use-case is to build artifacts inside a
packer builder -- for example, spinning up an EC2 instance to build a docker
packer builder -- for example, spinning up an EC2 instance to build a Docker
container -- and then extracting the docker container and throwing away the
container -- and then extracting the Docker container and throwing away the
EC2
instance.
@ -35,7 +35,7 @@ post-processors.
A major benefit of this is that you can modify builder
artifacts using shell-local and pass those modified artifacts into
post-processors that may not have worked with the original builder.
For example, maybe you want to export a docker container from an amazon-ebs
For example, maybe you want to export a Docker container from an amazon-ebs
builder and then use Docker-push to put that Docker container into your Docker
Hub account.
@ -170,4 +170,4 @@ result.
```
You can create multiple post-processor chains to handle multiple builders (for
example, building linux and windows binaries during the same build).
example, building Linux and Windows binaries during the same build).

4
website/content/docs/post-processors/manifest.mdx
View file

@ -17,7 +17,7 @@ Artifact BuilderId: `packer.post-processor.manifest`
The manifest post-processor writes a JSON file with a list of all of the
artifacts packer produces during a run. If your Packer template includes
multiple builds, this helps you keep track of which output artifacts (files,
AMI IDs, docker containers, etc.) correspond to each build.
AMI IDs, Docker containers, etc.) correspond to each build.
The manifest post-processor is invoked each time a build completes and
_updates_ data in the manifest file. Builds are identified by name and type,
@ -194,7 +194,7 @@ Example usage:
The manifest can be very useful for cleaning up old artifacts, or printing
important values to logs. The following example uses jq, a command-line tool for
parsing json output, to find and echo the AWS ami-id of an ami created by a
parsing json output, to find and echo the AWS ami-id of an AMI created by a
build.
```bash

20
website/content/docs/post-processors/shell-local.mdx
View file

@ -173,17 +173,17 @@ Optional parameters:
on specific operating systems. By default, shell-local will always run if
`only_on` is not set."
- `use_linux_pathing` (bool) - This is only relevant to windows hosts. If you
- `use_linux_pathing` (bool) - This is only relevant to Windows hosts. If you
are running Packer in a Windows environment with the Windows Subsystem for
Linux feature enabled, and would like to invoke a bash script rather than
invoking a Cmd script, you'll need to set this flag to true; it tells
Packer to use the linux subsystem path for your script rather than the
Packer to use the Linux subsystem path for your script rather than the
Windows path. (e.g. /mnt/c/path/to/your/file instead of
C:/path/to/your/file). Please see the example below for more guidance on
how to use this feature. If you are not on a Windows host, or you do not
intend to use the shell-local post-processor to run a bash script, please
ignore this option. If you set this flag to true, you still need to provide
the standard windows path to the script when providing a `script`. This is
the standard Windows path to the script when providing a `script`. This is
a beta feature.
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
@ -389,7 +389,7 @@ _must_ be extra careful to `exit 0` when necessary.
### Windows Host
Example of running a .cmd file on windows:
Example of running a .cmd file on Windows:
<Tabs>
<Tab heading="HCL2">
@ -419,7 +419,7 @@ Contents of `test_cmd.cmd`:
echo %SHELLLOCALTEST%
Example of running an inline command on windows: Required customization:
Example of running an inline command on Windows: Required customization:
tempfile_extension
<Tabs>
@ -448,7 +448,7 @@ post-processor "shell-local" {
</Tab>
</Tabs>
Example of running a bash command on windows using WSL: Required
Example of running a bash command on Windows using WSL: Required
customizations: `use_linux_pathing` and `execute_command`:
<Tabs>
@ -515,7 +515,7 @@ post-processor "shell-local" {
</Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
Example of running a PowerShell script on Windows as "inline": Required
customizations: `env_var_format`, `tempfile_extension`, and `execute_command`
<Tabs>
@ -550,7 +550,7 @@ post-processor "shell-local" {
### Unix Host
Example of running a Shell script on unix:
Example of running a Shell script on Unix:
<Tabs>
<Tab heading="HCL2">
@ -576,7 +576,7 @@ post-processor "shell-local" {
</Tab>
</Tabs>
Example of running a bash "inline" on unix:
Example of running a bash "inline" on Unix:
<Tabs>
<Tab heading="HCL2">
@ -603,7 +603,7 @@ post-processor "shell-local" {
</Tab>
</Tabs>
Example of running a python script on unix:
Example of running a Python script on Unix:
<Tabs>
<Tab heading="HCL2">

2
website/content/docs/provisioners/file.mdx
View file

@ -188,5 +188,5 @@ using the file provisioner on Windows, it's suggested that you set up an SSH
server and use the [ssh communicator](/docs/communicators/ssh). If you only want
to transfer files to your guest, and if your builder supports it, you may also
use the `http_directory` or `http_content` directives. This will cause that
directory to be available to the guest over http, and set the environment
directory to be available to the guest over HTTP, and set the environment
variable `PACKER_HTTP_ADDR` to the address.

12
website/content/docs/provisioners/powershell.mdx
View file

@ -205,9 +205,9 @@ provisioner "powershell" {
</Tab>
</Tabs>
- `execution_policy` - To run ps scripts on windows packer defaults this to
- `execution_policy` - To run ps scripts on Windows, Packer defaults this to
"bypass" and wraps the command to run. Setting this to "none" will prevent
wrapping, allowing to see exit codes on docker for windows. Possible values
wrapping, allowing to see exit codes on Docker for Windows. Possible values
are `bypass`, `allsigned`, `default`, `remotesigned`, `restricted`,
`undefined`, `unrestricted`, and `none`.
@ -244,7 +244,7 @@ provisioner "powershell" {
exists in order to deal with times when SSH may restart, such as a system
reboot. Set this to a higher value if reboots take a longer amount of time.
- `pause_after` (string) - Wait the amount of time after provisioning a powershell
- `pause_after` (string) - Wait the amount of time after provisioning a PowerShell
script, this pause be taken if all previous steps were successful.
@include 'provisioners/common-config.mdx'
@ -371,7 +371,7 @@ The above snippet should result in the following output on the Packer console:
```shell-session
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner508190439
==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner508190439
amazon-ebs: A literal dollar $ must be escaped
amazon-ebs: A literal backtick ` must be escaped
amazon-ebs: Here "double quotes" must be escaped
@ -468,10 +468,10 @@ The above snippet should result in the following output on the Packer console:
```shell-session
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner961728919
==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner961728919
amazon-ebs: The dollar in the elevated_password is interpreted correctly
==> amazon-ebs: Provisioning with Powershell...
==> amazon-ebs: Provisioning with powershell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner142826554
==> amazon-ebs: Provisioning with PowerShell script: /var/folders/15/d0f7gdg13rnd1cxp7tgmr55c0000gn/T/packer-powershell-provisioner142826554
amazon-ebs: In the following examples the special character is interpreted correctly:
amazon-ebs: The dollar in VAR1: A$Dollar
amazon-ebs: The backtick in VAR2: A`Backtick

28
website/content/docs/provisioners/shell-local.mdx
View file

@ -80,7 +80,7 @@ Exactly _one_ of the following is required:
- `command` (string) - This is a single command to execute. It will be
written to a temporary file and run using the `execute_command` call below.
If you are building a windows vm on AWS, Azure, Google Compute, or OpenStack
If you are building a Windows VM on AWS, Azure, Google Compute, or OpenStack
and would like to access the generated password that Packer uses to connect
to the instance via WinRM, you can use the template variable `{{.WinRMPassword}}`
to set this as an environment variable.
@ -112,7 +112,7 @@ Optional parameters:
inject prior to the `execute_command`. The format should be `key=value`.
Packer injects some environmental variables by default into the
environment, as well, which are covered in the section below. If you are
building a windows vm on AWS, Azure, Google Compute, or OpenStack and would
building a Windows VM on AWS, Azure, Google Compute, or OpenStack and would
like to access the generated password that Packer uses to connect to the
instance via WinRM, you can use the template variable `{{.WinRMPassword}}`
to set this as an environment variable. For example:
@ -127,7 +127,7 @@ Optional parameters:
- `execute_command` (array of strings) - The command used to execute the
script. By default this is `["/bin/sh", "-c", "{{.Vars}}", "{{.Script}}"]`
on unix and `["cmd", "/c", "{{.Vars}}", "{{.Script}}"]` on windows. This is
on Unix and `["cmd", "/c", "{{.Vars}}", "{{.Script}}"]` on Windows. This is
treated as a [template engine](/docs/templates/legacy_json_templates/engine). There are two
available variables: `Script`, which is the path to the script to run, and
`Vars`, which is the list of `environment_vars`, if configured.
@ -147,7 +147,7 @@ Optional parameters:
sake of clarity, as even when you set only a single `command` to run,
Packer writes it to a temporary file and then runs it as a script.
If you are building a windows vm on AWS, Azure, Google Compute, or OpenStack
If you are building a Windows VM on AWS, Azure, Google Compute, or OpenStack
and would like to access the generated password that Packer uses to connect
to the instance via WinRM, you can use the template variable `{{.WinRMPassword}}`
to set this as an environment variable.
@ -166,11 +166,11 @@ Optional parameters:
on specific operating systems. By default, shell-local will always run if
`only_on` is not set."
- `use_linux_pathing` (bool) - This is only relevant to windows hosts. If you
- `use_linux_pathing` (bool) - This is only relevant to Windows hosts. If you
are running Packer in a Windows environment with the Windows Subsystem for
Linux feature enabled, and would like to invoke a bash script rather than
invoking a Cmd script, you'll need to set this flag to true; it tells
Packer to use the linux subsystem path for your script rather than the
Packer to use the Linux subsystem path for your script rather than the
Windows path. (e.g. /mnt/c/path/to/your/file instead of
C:/path/to/your/file). Please see the example below for more guidance on
how to use this feature. If you are not on a Windows host, or you do not
@ -316,7 +316,7 @@ _must_ be extra careful to `exit 0` when necessary.
### Windows Host
Example of running a .cmd file on windows:
Example of running a .cmd file on Windows:
<Tabs>
<Tab heading="HCL2">
@ -346,7 +346,7 @@ Contents of "test_cmd.cmd":
echo %SHELLLOCALTEST%
Example of running an inline command on windows: Required customization:
Example of running an inline command on Windows: Required customization:
tempfile_extension
<Tabs>
@ -375,7 +375,7 @@ provisioner "shell-local" {
</Tab>
</Tabs>
Example of running a bash command on windows using WSL: Required
Example of running a bash command on Windows using WSL: Required
customizations: use_linux_pathing and execute_command
<Tabs>
@ -411,7 +411,7 @@ Contents of `example_bash.sh`:
#!/bin/bash
echo $SHELLLOCALTEST
Example of running a powershell script on windows: Required customizations:
Example of running a PowerShell script on Windows: Required customizations:
`env_var_format` and `execute_command`
<Tabs>
@ -442,7 +442,7 @@ provisioner "shell-local" {
</Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
Example of running a PowerShell script on Windows as "inline": Required
customizations: `env_var_format`, `tempfile_extension`, and `execute_command`
<Tabs>
@ -477,7 +477,7 @@ provisioner "shell-local" {
### Unix Host
Example of running a Shell script on unix:
Example of running a Shell script on Unix:
<Tabs>
<Tab heading="HCL2">
@ -503,7 +503,7 @@ provisioner "shell-local" {
</Tab>
</Tabs>
Example of running a Shell script "inline" on unix:
Example of running a Shell script "inline" on Unix:
<Tabs>
<Tab heading="HCL2">
@ -530,7 +530,7 @@ provisioner "shell-local" {
</Tab>
</Tabs>
Example of running a Python script on unix:
Example of running a Python script on Unix:
<Tabs>
<Tab heading="HCL2">

4
website/content/docs/templates/hcl_templates/blocks/build/hcp_packer_registry.mdx vendored
View file

@ -59,12 +59,12 @@ Some nice description about the image which artifact is being published to HCP P
`HCP_PACKER_BUCKET_NAME` is set.
- `bucket_labels` (map[string]string) - Map of labels. Can provide any information,
such as tools versions (e.g. go 1.17, python 3.5, etc...). The bucket labels will
such as tools versions (e.g. Go 1.17, Python 3.5, etc...). The bucket labels will
appear at the image's main page and will be updated whenever it is changed
and a new iteration for the bucket is pushed to the HCP Packer registry.
- `build_labels` (map[string]string) - Map of labels. Can provide any information,
such as tools versions (e.g. go 1.17, python 3.5, etc...). The build labels will
such as tools versions (e.g. Go 1.17, Python 3.5, etc...). The build labels will
appear in the build section of an iteration. Build labels are specific to an iteration
and will be added to a build when is pushed to the HCP Packer registry.
Updates to build labels on a completed iteration is not allowed.

12
website/content/docs/templates/hcl_templates/contextual-variables.mdx vendored
View file

@ -39,19 +39,19 @@ Here is the list of available build variables:
- **name** Represents the name of the build block being run. This is different
than the name of the source block being run.
- **ID**: Represents the vm being provisioned. For example, in Amazon it is the instance id; in digitalocean,
it is the droplet id; in Vmware, it is the vm name.
- **ID**: Represents the VM being provisioned. For example, in Amazon it is the instance ID; in DigitalOcean,
it is the Droplet ID; in VMware, it is the VM name.
- **Host**, **Port**, **User** and **Password**: The host, port, user, and password that Packer uses to access the machine.
Useful for using the shell local provisioner to run Ansible or Inspec against the provisioned instance.
- **ConnType**: Type of communicator being used. For example, for SSH communicator this will be "ssh".
- **PackerRunUUID**: Current build's unique id. Can be used to specify build artifacts.
- **PackerRunUUID**: Current build's unique ID. Can be used to specify build artifacts.
An example of that, is when multiple builds runs at the same time producing the same artifact.
It's possible to differentiate these artifacts by naming them with the builds' unique ids.
It's possible to differentiate these artifacts by naming them with the builds' unique IDs.
- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the vm. The HTTP address is displayed in the format `IP:PORT`.
- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the VM. The HTTP address is displayed in the format `IP:PORT`.
- **SSHPublicKey** and **SSHPrivateKey**: The public and private key that Packer uses to connect to the instance.
These are unique to the SSH communicator and are unset when using other communicators.
@ -162,4 +162,4 @@ You can also add this value to post-processors, for example to add to a manifest
}
}
```
```

4
website/content/docs/templates/hcl_templates/expressions.mdx vendored
View file

@ -203,7 +203,7 @@ A _splat expression_ provides a more concise way to express a common operation
that could otherwise be performed with a `for` expression.
If `var.list` is a list of objects that all have an attribute `id`, then a list
of the ids could be produced with the following `for` expression:
of the IDs could be produced with the following `for` expression:
```hcl
[for o in var.list : o.id]
@ -248,7 +248,7 @@ may not produce a tuple value:
aws_instance.example[*].id
```
The above will produce a list of ids whether `aws_instance.example` has `count`
The above will produce a list of IDs whether `aws_instance.example` has `count`
set or not, avoiding the need to revise various other expressions in the
configuration when a particular resource switches to and from having `count`
set.

4
website/content/docs/templates/hcl_templates/functions/encoding/csvdecode.mdx vendored
View file

@ -43,7 +43,7 @@ You can use the result of `csvdecode` with
to describe a collection of similar objects whose differences are
described by the rows in the given CSV file.
There must be one column in the CSV file that can serve as a unique id for each
There must be one column in the CSV file that can serve as a unique ID for each
row, which we can then use as the tracking key for the individual instances in
the `for_each` expression. For example:
@ -91,5 +91,5 @@ then you could instead use
to define an object for each CSV row, with each one identified by its index into
the list returned by `csvdecode`. However, in that case any future updates to
the CSV may be disruptive if they change the positions of particular objects in
the list. We recommend using `for_each` with a unique id column to make
the list. We recommend using `for_each` with a unique ID column to make
behavior more predictable on future changes.

4
website/content/docs/templates/hcl_templates/functions/uuid/uuidv4.mdx vendored
View file

@ -1,13 +1,13 @@
---
page_title: v4 - uuid - Functions - Configuration Language
description: The uuidv4 function generates a unique id.
description: The uuidv4 function generates a unique ID.
---
# `uuidv4` Function
`uuidv4` generates a unique identifier string.
The id is a generated and formatted as required by [RFC 4122 section
The ID is a generated and formatted as required by [RFC 4122 section
4.4](https://tools.ietf.org/html/rfc4122#section-4.4), producing a Version 4
UUID. The result is a UUID generated only from pseudo-random numbers.

2
website/content/docs/templates/hcl_templates/index.mdx vendored
View file

@ -10,7 +10,7 @@ description: |-
`@include 'from-1.5/beta-hcl2-note.mdx'`
Packer uses the Hashicorp Configuration Language - HCL - designed to allow
Packer uses the HashiCorp Configuration Language - HCL - designed to allow
concise descriptions of the required steps to get to a build file. This page
describes the features of HCL2 exhaustively, if you would like to give a quick
try to HCL2, you can also read the quicker [HCL2 getting started

2
website/content/docs/templates/hcl_templates/variables.mdx vendored
View file

@ -155,7 +155,7 @@ argument:
```hcl
variable "image_id" {
type = string
description = "The id of the machine image (AMI) to use for the server."
description = "The ID of the machine image (AMI) to use for the server."
}
```

10
website/content/docs/templates/legacy_json_templates/engine.mdx vendored
View file

@ -74,19 +74,19 @@ Here is a full list of the available functions for reference.
Valid variables to request are:
- **ID**: Represents the vm being provisioned. For example, in Amazon it is the instance id; in digitalocean,
it is the droplet id; in Vmware, it is the vm name.
- **ID**: Represents the VM being provisioned. For example, in Amazon it is the instance ID; in DigitalOcean,
it is the Droplet ID; in VMware, it is the VM name.
- **Host**, **Port**, **User** and **Password**: The host, port, user, and password that Packer uses to access the machine.
Useful for using the shell local provisioner to run Ansible or Inspec against the provisioned instance.
- **ConnType**: Type of communicator being used. For example, for SSH communicator this will be "ssh".
- **PackerRunUUID**: Current build's unique id. Can be used to specify build artifacts.
- **PackerRunUUID**: Current build's unique ID. Can be used to specify build artifacts.
An example of that, is when multiple builds runs at the same time producing the same artifact.
It's possible to differentiate these artifacts by naming them with the builds' unique ids.
It's possible to differentiate these artifacts by naming them with the builds' unique IDs.
- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the vm. The HTTP address is displayed in the format `IP:PORT`.
- **PackerHTTPIP**, **PackerHTTPPort**, and **PackerHTTPAddr**: HTTP IP, port, and address of the file server Packer creates to serve items in the "http" dir to the VM. The HTTP address is displayed in the format `IP:PORT`.
- **SSHPublicKey** and **SSHPrivateKey**: The public and private key that Packer uses to connect to the instance.
These are unique to the SSH communicator and are unset when using other communicators.

2
website/content/docs/templates/legacy_json_templates/index.mdx vendored
View file

@ -79,7 +79,7 @@ key with an underscore. Example:
**Important:** Only _root level_ keys can be underscore prefixed. Keys within
builders, provisioners, etc. will still result in validation errors.
-> **Note:** Packer supports HCL2 from version 1.6.0. The Hashicorp
-> **Note:** Packer supports HCL2 from version 1.6.0. The HashiCorp
Configuration Language does support comments anywhere in template files.
If comments are important to you, consider upgrading your
JSON template to HCL2 using the `packer hcl2_upgrade` command.

2
website/content/guides/1.7-plugin-upgrade.mdx
View file

@ -83,7 +83,7 @@ func main() {
The implementation is similar, but now we use the "NewSet" function to create the component Server, and call Run() instead of Serve().
You build it as you would any go binary:
You build it as you would any Go binary:
```go
go build -o packer-plugin-bar

10
website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx
View file

@ -2,7 +2,7 @@
page_title: Unattended Windows Installation
description: |-
Learn how to use an autounattend file to automatically answer installation
questions and enable Packer to connect to your windows instance.
questions and enable Packer to connect to your Windows instance.
---
# Unattended Installation for Windows
@ -57,21 +57,21 @@ If you want to be able to use provisioners, the Answer file must also contain
a script that sets up SSH or WinRM so that Packer can connect to the instance.
Finally, your Packer build will be much smoother if the Answer File handles or
disables windows updates rather than you trying to run them using a Packer
disables Windows updates rather than you trying to run them using a Packer
provisioner. This is because the winrm communicator does not handle the
disconnects caused by automatic reboots in Windows updates well, and the
disconnections can fail a build.
## Examples
The chef-maintained bento boxes are a great example of a windows build that
The chef-maintained bento boxes are a great example of a Windows build that
sets up openssh as part of the unattended installation so that Packer can
connect using the SSH communicator. The functioning answer files for every
modern Windows version can be found [here](https://github.com/chef/bento/tree/master/packer_templates/windows/answer_files).
Stefan Scherer's [packer-windows repo](https://github.com/StefanScherer/packer-windows)
is a great example of windows builds that set up WinRM as part of the unattended
installation so that Packer can connect using the winrm communicator:
is a great example of Windows builds that set up WinRM as part of the unattended
installation so that Packer can connect using the `winrm` communicator:
```json
{

2
website/content/guides/automatic-operating-system-installs/preseed_ubuntu.mdx
View file

@ -49,7 +49,7 @@ You then reference the file using a `boot_command` to kick off the installation.
In the example below, see how the `preseed/url` command line option is being
used in the `/install/vmlinuz command`. The `{{ .HTTPIP }}` and
`{{ .HTTPPort }}` options are special Packer template options that will get set
by Packer to point to the http server we create, so that your boot command can
by Packer to point to the HTTP server we create, so that your boot command can
access it. For an example of a working boot_command, see the Examples section
below. For more information on how boot_command works, see the
boot_command section of the docs for whatever builder you are using.

2
website/content/guides/packer-on-cicd/build-virtualbox-image.mdx
View file

@ -12,7 +12,7 @@ The Packer VirtualBox builder requires access to VirtualBox. Virtualization is
not universally supported on cloud instances, so we recommend you run these
builds on either a bare metal server, or cloud instances which support nested
virtualization, such as Azure or GCP. This is also true for the
[VMWare](/docs/builders/vmware) and the [QEMU](/docs/builders/qemu)
[VMware](/docs/builders/vmware) and the [QEMU](/docs/builders/qemu)
Packer builders.
We will use Chef's [Bento boxes](https://github.com/chef/bento) to provision an

4
website/content/guides/packer-on-cicd/pipelineing-builds.mdx
View file

@ -287,7 +287,7 @@ sources.pkr.hcl
source "docker" "example" {
commit = true
// any other configuration you want for your docker containers
// any other configuration you want for your Docker containers
}
```
@ -314,7 +314,7 @@ build {
}
// Make sure that the output from your build can be used in the next build.
// In this example, we're tagging the docker image so that the step-2
// In this example, we're tagging the Docker image so that the step-2
// builder can find it without us having to track it down in a manifest.
post-processor "docker-tag" {
repository = "ubuntu"

4
website/content/partials/datasource/hcp-packer-image/DatasourceOutput.mdx
View file

@ -7,11 +7,11 @@
- `created_at` (string) - The date and time at which the image was created.
- `build_id` (string) - The id of the build that created the image. This is a ULID, which is a
- `build_id` (string) - The ID of the build that created the image. This is a ULID, which is a
unique identifier similar to a UUID. It is created by the HCP Packer
Registry when an build is first created, and is unique to this build.
- `iteration_id` (string) - The iteration id. This is a ULID, which is a unique identifier similar
- `iteration_id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an iteration is
first created, and is unique to this iteration.

2
website/content/partials/datasource/hcp-packer-iteration/DatasourceOutput.mdx
View file

@ -15,7 +15,7 @@
- `fingerprint` (string) - The fingerprint of the build; this could be a git sha or other unique
identifier as set by the Packer build that created this iteration.
- `id` (string) - The iteration id. This is a ULID, which is a unique identifier similar
- `id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an iteration is
first created, and is unique to this iteration.

4
website/content/partials/datasource/packer-image-iteration/DatasourceOutput.mdx
View file

@ -1,6 +1,6 @@
<!-- Code generated from the comments of the DatasourceOutput struct in datasource/packer-image-iteration/data.go; DO NOT EDIT MANUALLY -->
- `Id` (string) - The iteration id. This is a ULID, which is a unique identifier similar
- `Id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an iteration is
first created, and is unique to this iteration.
@ -13,6 +13,6 @@
- `created_at` (string) - The date the iteration was created.
- `builds` ([]ParBuild) - A list of builds that are stored in the iteration. These builds can be
parsed using HCL to find individual image ids for specific providers.
parsed using HCL to find individual image IDs for specific providers.
<!-- End of code generated from the comments of the DatasourceOutput struct in datasource/packer-image-iteration/data.go; -->

4
website/content/partials/datasource/packer-image-iteration/ParBuild-not-required.mdx
View file

@ -7,14 +7,14 @@
- `created_at` (string) - The date and time at which the build was run.
- `id` (string) - The build id. This is a ULID, which is a unique identifier similar
- `id` (string) - The build ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an build is
first created, and is unique to this build.
- `images` ([]ParImage) - A list of images as stored in the HCP Packer registry. See the ParImage
docs for more information.
- `iteration_id` (string) - The iteration id. This is a ULID, which is a unique identifier similar
- `iteration_id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an iteration is
first created, and is unique to this iteration.

2
website/content/partials/datasource/packer-image-iteration/ParImage-not-required.mdx
View file

@ -2,7 +2,7 @@
- `created_at` (string) - The date and time at which the build was last updated.
- `id` (string) - The iteration id. This is a ULID, which is a unique identifier similar
- `id` (string) - The iteration ID. This is a ULID, which is a unique identifier similar
to a UUID. It is created by the HCP Packer Registry when an iteration is
first created, and is unique to this iteration.

8
website/content/partials/from-1.5/variables/custom-validation.mdx
View file

@ -7,11 +7,11 @@ within the corresponding `variable` block:
```hcl
variable "image_id" {
type = string
description = "The id of the machine image (AMI) to use for the server."
description = "The ID of the machine image (AMI) to use for the server."
validation {
condition = length(var.image_id) > 4 && substr(var.image_id, 0, 4) == "ami-"
error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
error_message = "The image_id value must be a valid AMI ID, starting with \"ami-\"."
}
}
```
@ -27,12 +27,12 @@ If the failure of an expression is the basis of the validation decision, use
```hcl
variable "image_id" {
type = string
description = "The id of the machine image (AMI) to use for the server."
description = "The ID of the machine image (AMI) to use for the server."
validation {
# regex(...) fails if it cannot find a match
condition = can(regex("^ami-", var.image_id))
error_message = "The image_id value must be a valid AMI id, starting with \"ami-\"."
error_message = "The image_id value must be a valid AMI ID, starting with \"ami-\"."
}
}
```

2
website/content/partials/packer-plugin-sdk/multistep/commonsteps/HTTPConfig.mdx
View file

@ -1,6 +1,6 @@
<!-- Code generated from the comments of the HTTPConfig struct in multistep/commonsteps/http_config.go; DO NOT EDIT MANUALLY -->
Packer will create an http server serving `http_directory` when it is set, a
Packer will create an HTTP server serving `http_directory` when it is set, a
random free port will be selected and the architecture of the directory
referenced will be available in your builder.

20
website/content/partials/plugins/installing-plugins.mdx
View file

@ -180,19 +180,19 @@ later, it will take precedence over one found earlier.
1. The directory where `packer` is, or the executable directory.
2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (unix)
2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (Unix)
3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (windows)
3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (Windows)
4. The `%USERPROFILE%/packer.d/plugins` if `%USERPROFILE%` is defined
(windows)
(Windows)
5. The current working directory.
6. The directory defined in the env var `PACKER_PLUGIN_PATH`. There can be more
than one directory defined; for example, `~/custom-dir-1:~/custom-dir-2`.
Separate directories in the PATH string using a colon (`:`) on posix systems and
a semicolon (`;`) on windows systems. The above example path would be able to
Separate directories in the PATH string using a colon (`:`) on POSIX systems and
a semicolon (`;`) on Windows systems. The above example path would be able to
find a provisioner named `packer-provisioner-foo` in either
`~/custom-dir-1/packer-provisioner-foo` or
`~/custom-dir-2/packer-provisioner-foo`.
@ -226,19 +226,19 @@ later, it will take precedence over one found earlier.
1. The directory where `packer` is, or the executable directory.
2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (unix)
2. The `$HOME/.packer.d/plugins` directory, if `$HOME` is defined (Unix)
3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (windows)
3. The `%APPDATA%/packer.d/plugins` if `%APPDATA%` is defined (Windows)
4. The `%USERPROFILE%/packer.d/plugins` if `%USERPROFILE%` is defined
(windows)
(Windows)
5. The current working directory.
6. The directory defined in the env var `PACKER_PLUGIN_PATH`. There can be more
than one directory defined; for example, `~/custom-dir-1:~/custom-dir-2`.
Separate directories in the PATH string using a colon (`:`) on posix systems and
a semicolon (`;`) on windows systems. The above example path would be able to
Separate directories in the PATH string using a colon (`:`) on POSIX systems and
a semicolon (`;`) on Windows systems. The above example path would be able to
find a provisioner named `packer-provisioner-foo` in either
`~/custom-dir-1/packer-provisioner-foo` or
`~/custom-dir-2/packer-provisioner-foo`.

2
website/content/partials/provisioners/community_provisioners.mdx
View file

@ -5,5 +5,5 @@
comments.
- [Windows Update provisioner](https://github.com/rgl/packer-plugin-windows-update) -
A provisioner for gracefully handling windows updates and the reboots they
A provisioner for gracefully handling Windows updates and the reboots they
cause.