Merge pull request #13285 from hashicorp/docs/packer-seo-final-batch

remaining packer content

website/content/docs/commands/build.mdx

@@ -1,13 +1,10 @@
 ---
 description: |
-  The `packer build` command takes a template and runs all the builds within it
-  in order to generate a set of artifacts. The various builds specified within a
-  template are executed in parallel, unless otherwise specified. And the
-  artifacts that are created will be outputted at the end of the build.
+  The `packer build` command builds all of the artifacts defined in a template. Builds can run in parallel or sequentially.
 page_title: packer build - Commands
 ---
 
-# `build` Command
+# `packer build` command reference
 
 The `packer build` command takes a template and runs all the builds within it
 in order to generate a set of artifacts. The various builds specified within a

website/content/docs/commands/console.mdx

@@ -1,11 +1,10 @@
 ---
 description: |
-  The `packer console` command allows you to experiment with Packer variable
-  interpolations.
-page_title: packer console - Commands
+  The `packer console` command starts an interactive console, letting you experiment with Packer variable interpolations.
+page_title: packer console command reference
 ---
 
-# `console` Command
+# `packer console` command reference
 
 The `packer console` command allows you to experiment with Packer variable
 interpolations. You may access variables in the Packer config you called the

website/content/docs/commands/fix.mdx

@@ -1,21 +1,19 @@
 ---
 description: |
-  The `packer fix` command takes a template and finds backwards incompatible
-  parts of it and brings it up to date so it can be used with the latest version
-  of Packer. After you update to a new Packer release, you should run the fix
-  command to make sure your templates work with the new release.
-page_title: packer fix - Commands
+  The `packer fix` command updates backward incompatible templates for the running version of Packer. 
+page_title: packer fix command reference
 ---
 
-# `fix` Command
+# `packer fix` command reference
 
--> **Note** This command is not available on HCL2 templates yet, it will be added when we need to introduce the first 'fix'.
 
-The `packer fix` command takes a template and finds backwards incompatible
+The `packer fix` command takes a template and finds backward incompatible
 parts of it and brings it up to date so it can be used with the latest version
 of Packer. After you update to a new Packer release, you should run the fix
 command to make sure your templates work with the new release.
 
+-> **JSON template-only command**: You cannot use the `packer fix` command to update HCL2 templates.
+
 The fix command will output the changed template to standard out, so you should
 redirect standard out using standard OS-specific techniques if you want to save it
 to a file. For example, on Linux systems, you may want to do this:

website/content/docs/commands/fmt.mdx

@@ -1,11 +1,10 @@
 ---
 description: |
-  The `packer fmt` Packer command is used to format HCL2
-  configuration files to a canonical format and style.
-page_title: packer fmt - Commands
+  The `packer fmt` Packer command formats HCL2 configuration files to a canonical format and style to help you prevent coding errors.
+page_title: packer fmt command reference
 ---
 
-# `fmt` Command
+# `packer fmt` command reference
 
 The `packer fmt` Packer command is used to format HCL2 configuration files to
 a canonical format and style. JSON files (.json) are not modified. This command

website/content/docs/commands/hcl2_upgrade.mdx

@@ -1,23 +1,20 @@
 ---
 description: |
-  The `packer hcl2_upgrade` Packer command is used to transpile a JSON
-  configuration template to its formatted HCL2 counterpart. The command will
-  return a zero exit status on success, and a non-zero exit status on failure.
-page_title: packer hcl2_upgrade - Commands
+  The `packer hcl2_upgrade` Packer command transpiles a JSON
+  configuration template into HCL2 so you can transition to HCL templates.
+page_title: packer hcl2_upgrade command reference
 ---
 
--> **Note:** This command is Beta, and currently being improved upon; do not
-hesitate [opening a new
-issue](https://github.com/hashicorp/packer/issues/new/choose) if you find
-something wrong.
+# `packer hcl2_upgrade` command reference
 
-# `hcl2_upgrade` Command
+The `packer hcl2_upgrade` Packer command transpiles a JSON
+configuration template to it's formatted HCL2 counterpart. The command
+returns a zero exit status on success and a non-zero exit status on failure.
 
-The `packer hcl2_upgrade` Packer command is used to transpile a JSON
-configuration template to it's formatted HCL2 counterpart. The command will
-return a zero exit status on success, and a non-zero exit status on failure.
+-> **This command is beta**. We do not recommend using beta functionality in production environments. To report an issue and provide feedback, [open a GitHub
+issue](https://github.com/hashicorp/packer/issues/new/choose).
 
-Example usage:
+## Usage
 
 ```shell-session
 $ packer hcl2_upgrade my-template.json

website/content/docs/commands/index.mdx

@@ -1,14 +1,10 @@
 ---
 description: |
-  Packer is controlled using a command-line interface. All interaction with
-  Packer is done via the `packer` tool. Like many other command-line tools, the
-  `packer` tool takes a subcommand to execute, and that subcommand may have
-  additional options as well. Subcommands are executed with `packer SUBCOMMAND`,
-  where "SUBCOMMAND" is the actual command you wish to execute.
-page_title: Commands
+  The Packer command-line interface lets you perform Packer operations. Use the `packer` CLI command with subcommands, flags, and options to build and manage artifacts and install and manage plugins.
+page_title: Packer commands overview
 ---
 
-# Packer Commands (CLI)
+# Packer Commands Overview
 
 Packer is controlled using a command-line interface. All interaction with
 Packer is done via the `packer` tool. Like many other command-line tools, the

website/content/docs/commands/init.mdx

@@ -1,10 +1,10 @@
 ---
 description: |
-    Reference information about the `packer init` command, which downloads and installs one or more plugin binaries specified in a Packer template written in HCL.
-page_title: packer init command line reference
+    The `packer init` command downloads and installs the plugins specified in a Packer template.
+page_title: packer init command reference
 ---
 
-# `init` command reference
+# `packer init` command reference
 
 The `packer init` command initializes Packer according to an HCL template configuration. Refer to [Installing Plugins](/packer/docs/plugins/install) for additional information about installing plugins.
 

website/content/docs/commands/inspect.mdx

@@ -1,19 +1,10 @@
 ---
 description: >
-  The `packer inspect` command takes a template and outputs the various
-
-  components a template defines. This can help you quickly learn about a
-  template
-
-  without having to dive into the HCL itself. The command will tell you things
-
-  like what variables a template accepts, the builders it defines, the
-
-  provisioners it defines and the order they'll run, and more.
-page_title: packer inspect - Commands
+  The `packer inspect` command outputs the variables, builders, and provisioners a template uses so you can review the template without reading the HCL.
+page_title: packer inspect command reference
 ---
 
-# `inspect` Command
+# `packer inspect` command reference
 
 The `packer inspect` command takes a template and outputs the various
 components a template defines. This can help you quickly learn about a template
@@ -29,7 +20,7 @@ The command doesn't validate the actual configuration of the various components
 (that is what the `validate` command is for), but it will validate the syntax
 of your template by necessity.
 
-## Usage Example
+## Example
 
 Given a basic template, here is an example of what the output might look like:
 

website/content/docs/commands/plugins/index.mdx

@@ -1,13 +1,12 @@
 ---
 description: |
-  The "plugin" command groups subcommands for interacting with
-  Packer's plugin and the plugin catalog.
-page_title: plugins Command
+  The `packer plugins` command group contains subcommands for managing Packer plugins.
+page_title: packer plugins command reference
 ---
 
-# `plugins`
+# `packer plugins` command reference
 
-The `plugins` command groups subcommands for interacting with Packers' plugins.
+The `plugins` command group contains subcommands for installing, uninstalling, and viewing Packer plugins.
 
 ```shell-session
 $ packer plugins -h

website/content/docs/commands/plugins/install.mdx

@@ -1,6 +1,6 @@
 ---
 description: |
-  Reference information about the `packer plugins install` command which downloads and installs Packer plugin binaries without a Packer template
+  The `packer plugins install` command manually downloads and installs Packer plugins without having to update and initialize a build template. 
 page_title: packer plugins install command reference
 ---
 

website/content/docs/commands/plugins/installed.mdx

@@ -1,12 +1,12 @@
 ---
 description: |
-  The "plugins installed" command will list installed plugins.
-page_title: plugins Command
+  The `packer plugins installed` command lists the installed Packer plugins.
+page_title: packer plugins installed command reference
 ---
 
-# `plugins installed`
+# `packer plugins installed` command reference
 
-The `plugins installed` subcommand lists installed Packer plugins
+The `plugins installed` subcommand lists installed Packer plugins.
 
 ```shell-session
 $ packer plugins installed -h

website/content/docs/commands/plugins/remove.mdx

@@ -1,12 +1,12 @@
 ---
 description: |
-  The "plugins remove" command can remove a plugin at a version constraint.
-page_title: plugins Command
+  The `packer plugins remove` command removes one or more versions of an installed Packer plugin.
+page_title: packer plugin remove command reference
 ---
 
-# `plugins remove`
+# `packer plugins remove` command reference
 
-The `plugins remove` subcommand removes one or more versions of an installed Packer plugin.
+The `packer plugins remove` subcommand removes one or more versions of an installed Packer plugin.
 
 The command is flexible enough to remove all versions at once or just a single version at a time. 
 - If a plugin's source address is specified, without a version constraint, all the versions of that plugin will be removed.

website/content/docs/commands/plugins/required.mdx

@@ -1,12 +1,12 @@
 ---
 description: |
-  The "plugins required" command lists all plugins required in a Packer configuration.
-page_title: plugins Command
+  The `packer plugins required` command lists all of the plugins required by a Packer configuration and any installed binaries that satisfy the requirements.
+page_title: packer plugins required command reference
 ---
 
-# `plugins required`
+# `packer plugins required` command reference
 
-The `plugins required` command lists all plugins required by a Packer config and
+The `plugins required` command lists all plugins required by a Packer configuration and
 all the installed binaries that match the constraint. The first binary 
 is the most up-to-date installed version and will be  the one picked by Packer in a build.
 
@@ -27,4 +27,4 @@ Usage: packer plugins required <path>
 
 ## Related
 
-- [`packer init`](/packer/docs/commands/init) will install all required plugins.
+- [`packer init`](/packer/docs/commands/init) will install all required plugins.

website/content/docs/commands/validate.mdx

@@ -1,13 +1,11 @@
 ---
 description: |
-  The `packer validate` Packer command is used to validate the syntax and
-  configuration of a template. The command will return a zero exit status on
-  success, and a non-zero exit status on failure. Additionally, if a template
-  doesn't validate, any error messages will be outputted.
-page_title: packer validate - Commands
+  The `packer validate` command validates the syntax and
+  configuration in a Packer template, helping you prevent errors.
+page_title: packer validate command reference
 ---
 
-# `validate` Command
+# `packer validate` command reference
 
 The `packer validate` Packer command is used to validate the syntax and
 configuration of a [template](/packer/docs/templates). The command will

website/content/docs/communicators/index.mdx

@@ -1,11 +1,10 @@
 ---
 description: |
-  Communicators are the mechanism Packer uses to upload files, execute
-  scripts, etc. with the machine being created.
-page_title: Communicators
+  Communicators are remote-access programs Packer uses to perform actions, such as upload files and execute scripts, on the machines Packer creates.
+page_title: Communicators overview
 ---
 
-# Communicators
+# Communicators overview
 
 Communicators are the mechanism Packer uses to upload files, execute scripts,
 etc. with the machine being created.
@@ -14,13 +13,9 @@ Communicators are configured within the
 [builder](/packer/docs/templates/legacy_json_templates/builders) section. Packer currently supports
 three kinds of communicators:
 
-- `none` - No communicator will be used. If this is set, most provisioners
-  also can't be used.
-
-- [ssh](/packer/docs/communicators/ssh) - An SSH connection will be established to the machine. This is
-  usually the default.
-
-- [winrm](/packer/docs/communicators/winrm) - A WinRM connection will be established.
+- `none`: Packer does not use a communicator and cannot use most provisioners.
+- [`ssh`](/packer/docs/communicators/ssh): Packer establishes an SSH connection to the machine. This is usually the default.
+- [`winrm`](/packer/docs/communicators/winrm): Packer establishes a WinRM connection. 
 
 In addition to the above, some builders have custom communicators they can use.
 For example, the Docker builder has a "docker" communicator that uses

website/content/docs/communicators/ssh.mdx

@@ -1,26 +1,29 @@
 ---
 description: |
-  The SSH communicator uses SSH to upload files, execute scripts, etc. on
-  the machine being created.
-page_title: Communicators - SSH
+  The `ssh` communicator establishes an SSH connection so that Packer can perform actions, such as upload files and execute scripts, on the machine it creates. 
+page_title: Establish an SSH connection
 ---
 
-# SSH Communicator
+# Establish an SSH Connection
+
+This topic describes how to use the `ssh` communicator to establish an SSH connection to the machine it creates so that Packer can perform actions, such as upload files and execute scripts. 
+
+## Introduction
 
 Communicators are the mechanism Packer uses to upload files, execute scripts,
 etc. on the machine being created, and are configured within the
 [builder](/packer/docs/templates/legacy_json_templates/builders) section.
 
-The SSH communicator does this by using the SSH protocol. It is the default
+The `ssh` communicator does this by using the SSH protocol. It is the default
 communicator for a majority of builders.
 
 If you have an SSH agent configured on the host running Packer, and SSH agent
 authentication is enabled in the communicator config, Packer will automatically
 forward the SSH agent to the remote host.
 
-## Getting Ready to Use the SSH Communicator
+## Getting Ready to Use the `ssh` Communicator
 
-The SSH communicator is the default communicator for a majority of builders, but
+The `ssh` communicator is the default communicator for a majority of builders, but
 depending on your builder it may not work "out of the box".
 
 If you are building from a cloud image (for example, building on Amazon), there
@@ -47,14 +50,14 @@ image bootstrapping, or research automatic configuration for your specific
 guest operating system. Knowing how to automatically initalize your operating
 system is critical for being able to successfully use Packer.
 
-## SSH Communicator
+## `ssh` Communicator Reference
 
-The SSH communicator connects to the host via SSH. If you have an SSH agent
+The `ssh` communicator connects to the host via SSH. If you have an SSH agent
 configured on the host running Packer, and SSH agent authentication is enabled
 in the communicator config, Packer will automatically forward the SSH agent to
 the remote host.
 
-The SSH communicator has the following options:
+The `ssh` communicator has the following options:
 
 @include "packer-plugin-sdk/communicator/SSH-not-required.mdx"
 
@@ -71,7 +74,7 @@ The SSH communicator has the following options:
 communicator; however, they may not be supported for every builder. Please refer
 to the builder documentation for supported options.
 
-### SSH Communicator Details
+### `ssh` Communicator Details
 
 Packer will only use one authentication method, either `publickey` or if
 `ssh_password` is used Packer will offer `password` and `keyboard-interactive`
@@ -87,4 +90,4 @@ Packer supports the following MACs:
 - `hmac-sha2-256-etm@openssh.com`
 
 For more information on the ciphers that Packer supports, check the docs for
-the [ssh_ciphers](/packer/docs/communicators/ssh#ssh_ciphers) template option.
+the [ssh_ciphers](/packer/docs/communicators/ssh#ssh_ciphers) template option.

website/content/docs/communicators/winrm.mdx

@@ -1,19 +1,22 @@
 ---
 description: |
-  Communicators are the mechanism Packer uses to upload files, execute scripts,
-  etc. with the machine being created.
-page_title: Communicators - Templates
+  The `winrm` communicator establishes a WinRM connection, letting Packer upload files or execute scripts on the machine it creates. 
+page_title: Establish a WinRM Connection
 ---
 
-# WinRM Communicator
+# Establish a WinRM Connection
+
+This topic describes how to use the `winrm` communicator to establish a WinRM connection to the machine it creates so that Packer can perform actions, such as upload files and execute scripts.
+
+## Introduction 
 
 Communicators are the mechanism Packer uses to upload files, execute scripts,
-etc. with the machine being created. The WinRM communicator uses the
+etc. with the machine being created. The `winrm` communicator uses the
 Windows Remote Management protocol to do this.
 
-## Getting Ready to Use the WinRM Communicator
+## Getting Ready to Use the `winrm` Communicator
 
-The WinRM communicator is not the default communicator, so you will always have
+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
@@ -32,7 +35,7 @@ If you are unfamiliar with how to use an autounattend file, take a look at our
 how to automatically initalize your operating system is critical for being able
 to successfully use Packer to build from an iso.
 
-## WinRM Communicator Options
+## `winrm` Communicator Options
 
 @include "packer-plugin-sdk/communicator/WinRM-not-required.mdx"
 

website/content/docs/configure.mdx

@@ -1,10 +1,10 @@
 ---
 description: |
-  Learn how to use environment variables when running Packer that configure global behaviors.
-page_title: Configuring Packer
+  Learn how to configure Packer's global behavior using environment variables.
+page_title: Configure Packer
 ---
 
-# Configuring Packer
+# Configure Packer
 
 This topic describes how to configure Packer. The default configurations are suitable for learning how to get started, but you should refer to this topic for guidance as you become more familiar with Packer.
 

website/content/docs/post-processors/artifice.mdx

@@ -1,27 +1,15 @@
 ---
 description: >
-  The artifice post-processor overrides the artifact list from an upstream
-
-  builder or post-processor. All downstream post-processors will see the new
-
-  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
-
-  container -- and then extracting the Docker container and throwing away the
-  EC2
-
-  instance.
-page_title: Artifice - Post-Processors
+  The `artifice` post-processor overrides the artifact list from an upstream builder or post-processor. Use it to build artifacts inside a Packer builder, such as starting an EC2 instance to build a Docker container, but only keep the Docker container's artifacts.
+page_title: artifice post-processor reference
 ---
 
 <BadgesHeader>
   <PluginBadge type="official" />
 </BadgesHeader>
 
-# Artifice Post-Processor
+# `artifice` post-processor
 
-Type: `artifice`
 Artifact BuilderId: `packer.post-processor.artifice`
 
 The artifice post-processor overrides the artifact list from an upstream

website/content/docs/post-processors/checksum.mdx

@@ -1,21 +1,16 @@
 ---
 description: >
-  The checksum post-processor computes specified checksum for the artifact list
-  from an upstream builder or post-processor. All downstream post-processors
-  will see the new artifacts. The primary use-case is compute checksum for
-  artifacts allows to verify it later. So firstly this post-processor get
-  artifact, compute it checksum and pass to next post-processor original
-  artifacts and checksum files.
-page_title: Checksum - Post-Processors
+  The `checksum` post-processor computes the checksum for the artifact list
+  from an upstream builder or post-processor so that you can verify artifacts. 
+page_title: checksum post-processor reference
 ---
 
 <BadgesHeader>
   <PluginBadge type="official" />
 </BadgesHeader>
 
-# Checksum Post-Processor
+# `checksum` post-processor
 
-Type: `checksum`
 Artifact BuilderId: `packer.post-processor.checksum`
 
 The checksum post-processor computes specified checksum for the artifact list

website/content/docs/post-processors/community-supported.mdx

@@ -1,16 +1,13 @@
 ---
 description: >
-  Community-maintained post-processors are not part of the core Packer binary,
-  but
-
-  can run alongside Packer with minimal extra effort.
-page_title: Community - Post-Processors
+  Community-maintained post-processors are not part of the core Packer binary. You can run community post-processors with Packer post-processors.
+page_title: Community post-processors overview
 ---
 
-# Community Post-Processors
+# Community Post-processors Overview
 
 The following post-processors are developed and maintained by various members of the
 Packer community, not by HashiCorp. For more information on how to use community
-post-processors, see our docs on [extending Packer](/packer/docs/plugins/creation).
+post-processors, refer to our documentation on [extending Packer](/packer/docs/plugins/creation).
 
 @include 'post-processors/community_post-processors.mdx'

website/content/docs/post-processors/compress.mdx

@@ -1,21 +1,19 @@
 ---
 description: |
-  The Packer compress post-processor takes an artifact with files (such as from
-  VMware or VirtualBox) and compresses the artifact into a single archive.
-page_title: Compress - Post-Processors
+  The `compress` post-processor compresses an artifact that contains multiple files, such as VMware of VirtualBox builds, into a single archive.
+page_title: compress post-processor reference
 ---
 
 <BadgesHeader>
   <PluginBadge type="official" />
 </BadgesHeader>
 
-# Compress Post-Processor
+# `compress` post-processor
 
-Type: `compress`
 Artifact BuilderId: `packer.post-processor.compress`
 
-The Packer compress post-processor takes an artifact with files (such as from
-VMware or VirtualBox) and compresses the artifact into a single archive.
+The Packer compress post-processor takes an artifact with files, such as from
+VMware or VirtualBox, and compresses the artifact into a single archive.
 
 ## Configuration
 

website/content/docs/post-processors/index.mdx

@@ -1,11 +1,10 @@
 ---
 description: |
-  Post-processors run after the image is built by the builder and provisioned by
-  the provisioner(s).
-page_title: Post-Processors
+  Post-processors are programs that you can run after Packer builds and provisions an image. Use post-processors to upload artifacts and repackage files.
+page_title: Post-processors overview
 ---
 
-# Post-Processors
+# Post-processors overview
 
 Post-processors run after builders and provisioners. Post-processors are optional, and you can use them to upload artifacts, re-package files, and more. The documentation includes a page for each type of post-processor.
 

website/content/docs/post-processors/manifest.mdx

@@ -1,17 +1,15 @@
 ---
 description: >
-  The manifest post-processor writes a JSON file with the build artifacts and
-  IDs from a packer run.
-page_title: Manifest - Post-Processors
+  The `manifest` post-processor creates a JSON file that contains data about a Packer build's artifacts, letting you track a run's outputs.
+page_title: manifest post-processor reference
 ---
 
 <BadgesHeader>
   <PluginBadge type="official" />
 </BadgesHeader>
 
-# Manifest Post-Processor
+# `manifest` post-processor
 
-Type: `manifest`
 Artifact BuilderId: `packer.post-processor.manifest`
 
 The manifest post-processor writes a JSON file with a list of all of the

website/content/docs/post-processors/shell-local.mdx

@@ -1,19 +1,16 @@
 ---
 description: |
-  The shell-local Packer post processor enables users to do some post processing
-  after artifacts have been built.
-page_title: Local Shell - Post-Processors
+  The `shell-local` post-processor starts a local shell, letting you automate post-build actions after Packer builds your artifacts.
+page_title: shell-local post-processor reference
 ---
 
 <BadgesHeader>
   <PluginBadge type="official" />
 </BadgesHeader>
 
-# Local Shell Post Processor
+# `shell-local` post-processor
 
-Type: `shell-local`
-
-The local shell post processor executes scripts locally during the post
+The `shell-local` post processor executes scripts locally during the post
 processing stage. Shell local provides a convenient way to automate executing
 some task with packer outputs and variables.