iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

switches JSON and HCL2 tabs (#10888) 

* switches JSON and HCL2 tabs for all provisioners

* corrects `packer` to `Packer`

* corrects `http` to `HTTP`

* corrects typos and highlighting consistency issues

* corrects typos and highlighting consistency issues

* corrects typos and highlighting consistency issues

* `ansible` -> `Ansible`

* `packer fmt` for HCL2 blocks in provisioners

* linting and spelling

* fixes formatting

* fixes formatting

* Update website/content/docs/provisioners/ansible.mdx

Co-authored-by: Adrien Delorme <azr@users.noreply.github.com>

* fixes formatting

* improves example

* generate stuff

Co-authored-by: Adrien Delorme <azr@users.noreply.github.com>
This commit is contained in:
Kerim Satirli 2021-04-08 15:02:57 +02:00 committed by GitHub
parent 15a2e59bba
commit cf94fd1778
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
42 changed files with 901 additions and 880 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
website/content/community-tools.mdx
View File

@ -47,7 +47,7 @@ contribution here!
Packer Templates Packer Templates
- [packer-baseboxes](https://github.com/taliesins/packer-baseboxes) - Templates - [packer-baseboxes](https://github.com/taliesins/packer-baseboxes) - Templates
for packer to build base boxes for Packer to build base boxes
- [cbednarski/packer-ubuntu](https://github.com/cbednarski/packer-ubuntu) - - [cbednarski/packer-ubuntu](https://github.com/cbednarski/packer-ubuntu) -
Ubuntu LTS Virtual Machines for Vagrant Ubuntu LTS Virtual Machines for Vagrant

2
website/content/docs/builders/alicloud-ecs.mdx
View File

@ -139,4 +139,4 @@ for details.
See the See the
[examples/alicloud](https://github.com/hashicorp/packer/tree/master/builder/alicloud/examples) [examples/alicloud](https://github.com/hashicorp/packer/tree/master/builder/alicloud/examples)
folder in the packer project for more examples. folder in the Packer project for more examples.

8
website/content/docs/builders/azure/arm.mdx
View File

@ -33,7 +33,7 @@ options. In addition to the options listed here, a [communicator](/docs/template
#### Managed Identity #### Managed Identity
If you're running packer on an Azure VM with a [managed identity](/docs/builders/azure#azure-managed-identity) you don't need to specify any additional configuration options. As Packer will attempt to use the Managed Identity and subscription of the VM that Packer is running on. If you're running Packer on an Azure VM with a [managed identity](/docs/builders/azure#azure-managed-identity) you don't need to specify any additional configuration options. As Packer will attempt to use the Managed Identity and subscription of the VM that Packer is running on.
#### Interactive User Authentication #### Interactive User Authentication
@ -123,7 +123,7 @@ By using an existing resource group you can scope the provided credentials to
just this group, however failed builds are more likely to leave unused just this group, however failed builds are more likely to leave unused
artifacts. artifacts.
To have packer create a resource group you **must** provide: To have Packer create a resource group you **must** provide:
- `location` (string) Azure datacenter in which your VM will build. - `location` (string) Azure datacenter in which your VM will build.
@ -360,7 +360,7 @@ Packer from cleaning up any helper scripts uploaded to the VM during the build.
The Azure builder attempts to pick default values that provide for a just works The Azure builder attempts to pick default values that provide for a just works
experience. These values can be changed by the user to more suitable values. experience. These values can be changed by the user to more suitable values.
- The default user name is packer not root as in other builders. Most distros - The default user name is Packer not root as in other builders. Most distros
on Azure do not allow root to SSH to a VM hence the need for a non-root on Azure do not allow root to SSH to a VM hence the need for a non-root
default user. Set the ssh_username option to override the default value. default user. Set the ssh_username option to override the default value.
- The default VM size is Standard_A1. Set the vm_size option to override - The default VM size is Standard_A1. Set the vm_size option to override
@ -493,4 +493,4 @@ minimal, so overall impact is small.
See the See the
[examples/azure](https://github.com/hashicorp/packer/tree/master/builder/azure/examples) [examples/azure](https://github.com/hashicorp/packer/tree/master/builder/azure/examples)
folder in the packer project for more examples. folder in the Packer project for more examples.

2
website/content/docs/builders/azure/index.mdx
View File

@ -41,7 +41,7 @@ following methods are available and are explained below:
- Azure CLI - Azure CLI
-> **Don't know which authentication method to use?** Go with interactive -> **Don't know which authentication method to use?** Go with interactive
login to try out the builders. If you need packer to run automatically, login to try out the builders. If you need Packer to run automatically,
switch to using a Service Principal or Managed Identity. switch to using a Service Principal or Managed Identity.
No matter which method you choose, the identity you use will need the No matter which method you choose, the identity you use will need the

8
website/content/docs/builders/googlecompute.mdx
View File

@ -104,7 +104,7 @@ straightforwarded, it is documented here.
Packer looks for credentials in the following places, preferring the first Packer looks for credentials in the following places, preferring the first
location found: location found:
1. An `account_file` option in your packer file. 1. An `account_file` option in your Packer file.
2. A JSON file (Service Account) whose path is specified by the 2. A JSON file (Service Account) whose path is specified by the
`GOOGLE_APPLICATION_CREDENTIALS` environment variable. `GOOGLE_APPLICATION_CREDENTIALS` environment variable.
@ -178,7 +178,7 @@ using the gcloud command.
Or alternatively by navigating to [https://console.cloud.google.com/networking/firewalls/list](https://console.cloud.google.com/networking/firewalls/list). Or alternatively by navigating to [https://console.cloud.google.com/networking/firewalls/list](https://console.cloud.google.com/networking/firewalls/list).
Once this is set up, the following is a complete working packer config after Once this is set up, the following is a complete working Packer config after
setting a valid `project_id`: setting a valid `project_id`:
<Tabs> <Tabs>
@ -402,8 +402,8 @@ The GCS location must be writeable by the service account of the instance that P
### Gotchas ### Gotchas
CentOS and recent Debian images have root ssh access disabled by default. Set CentOS and recent Debian images have root SSH access disabled by default. Set
`ssh_username` to any user, which will be created by packer with sudo access. `ssh_username` to any user, which will be created by Packer with sudo access.
The machine type must have a scratch disk, which means you can't use an The machine type must have a scratch disk, which means you can't use an
`f1-micro` or `g1-small` to build images. `f1-micro` or `g1-small` to build images.

2
website/content/docs/builders/hetzner-cloud.mdx
View File

@ -74,7 +74,7 @@ builder.
for more info. for more info.
- `most_recent` (boolean) - Selects the newest created image when true. - `most_recent` (boolean) - Selects the newest created image when true.
This is most useful if you base your image on another packer build image. This is most useful if you base your image on another Packer build image.
You may set this in place of `image`, but not both. You may set this in place of `image`, but not both.

2
website/content/docs/builders/hyperv/iso.mdx
View File

@ -842,7 +842,7 @@ d-i pkgsel/update-policy select none
choose-mirror-bin mirror/http/proxy string choose-mirror-bin mirror/http/proxy string
``` ```
-> **Note for \*nix guests:** Please note that packer requires the VM to be -> **Note for \*nix guests:** Please note that Packer requires the VM to be
running a hyper-v KVP daemon in order to detect the IP address of the guest VM. running a hyper-v KVP daemon in order to detect the IP address of the guest VM.
On RHEL based machines this may require installing the package `hyperv-daemons` On RHEL based machines this may require installing the package `hyperv-daemons`
and ensuring the `hypervkvpd` service is started at boot. On Debian based and ensuring the `hypervkvpd` service is started at boot. On Debian based

2
website/content/docs/builders/lxc.mdx
View File

@ -88,7 +88,7 @@ Below is a fully functioning example.
`packer-<BuildName>`. `packer-<BuildName>`.
- `command_wrapper` (string) - Allows you to specify a wrapper command, such - `command_wrapper` (string) - Allows you to specify a wrapper command, such
as `ssh` so you can execute packer builds on a remote host. Defaults to as `ssh` so you can execute Packer builds on a remote host. Defaults to
Empty. Empty.
- `init_timeout` (string) - The timeout in seconds to wait for the the - `init_timeout` (string) - The timeout in seconds to wait for the the

6
website/content/docs/builders/ncloud.mdx
View File

@ -120,7 +120,7 @@ Here is a basic example for linux server.
## Requirements for creating Windows images ## Requirements for creating Windows images
You should include the following code in the packer configuration file for You should include the following code in the Packer configuration file for
provision when creating a Windows server. provision when creating a Windows server.
"builders": [ "builders": [
@ -148,7 +148,7 @@ provision when creating a Windows server.
instances you own. Before running Packer, please make sure that the number instances you own. Before running Packer, please make sure that the number
of public IP addresses previously created is not larger than the number of of public IP addresses previously created is not larger than the number of
server instances (including those to be used to create server images). server instances (including those to be used to create server images).
- When you forcibly terminate the packer process or close the terminal - When you forcibly terminate the Packer process or close the terminal
(command) window where the process is running, the resources may not be (command) window where the process is running, the resources may not be
cleaned up as the packer process no longer runs. In this case, you should cleaned up as the Packer process no longer runs. In this case, you should
manually clean up the resources associated with the process. manually clean up the resources associated with the process.

2
website/content/docs/builders/outscale/bsusurrogate.mdx
View File

@ -218,7 +218,7 @@ builder.
- `temporary_key_pair_name` (string) - The name of the temporary key pair to generate. By default, Packer generates a name that looks like `packer_<UUID>`, where &lt;UUID&gt; is a 36 character unique identifier. - `temporary_key_pair_name` (string) - The name of the temporary key pair to generate. By default, Packer generates a name that looks like `packer_<UUID>`, where &lt;UUID&gt; is a 36 character unique identifier.
- `temporary_security_group_source_cidr` (string) - An IPv4 CIDR block to be authorized access to the VM, when packer is creating a temporary security group. The default is `0.0.0.0/0` (i.e., allow any IPv4 source). This is only used when `security_group_id` or `security_group_ids` is not specified. - `temporary_security_group_source_cidr` (string) - An IPv4 CIDR block to be authorized access to the VM, when Packer is creating a temporary security group. The default is `0.0.0.0/0` (i.e., allow any IPv4 source). This is only used when `security_group_id` or `security_group_ids` is not specified.
- `user_data` (string) - User data to apply when launching the VM. Note that you need to be careful about escaping characters due to the templates being JSON. It is often more convenient to use `user_data_file`, instead. Packer will not automatically wait for a user script to finish before shutting down the VM this must be handled in a provisioner. - `user_data` (string) - User data to apply when launching the VM. Note that you need to be careful about escaping characters due to the templates being JSON. It is often more convenient to use `user_data_file`, instead. Packer will not automatically wait for a user script to finish before shutting down the VM this must be handled in a provisioner.

2
website/content/docs/builders/outscale/chroot.mdx
View File

@ -338,7 +338,7 @@ services:
### Ansible provisioner ### Ansible provisioner
Running ansible against `osc-chroot` requires changing the Ansible connection Running `ansible` against `osc-chroot` requires changing the Ansible connection
to chroot and running Ansible as root/sudo. to chroot and running Ansible as root/sudo.
## Building From Scratch ## Building From Scratch

4
website/content/docs/builders/outscale/index.mdx
View File

@ -79,9 +79,9 @@ Usage:
### x509 Certificate Authentication ### x509 Certificate Authentication
Outscale API now supports x509 Client certificate authentication, in addition of traditional AK/SK HMAC based auth. Outscale API now supports x509 Client certificate authentication, in addition of traditional AK/SK HMAC based auth.
This adds an additional layer of security, especially desirable on SecNumCloud compliant regions (cloudgouv-eu-west-1). This adds an additional layer of security, especially desirable on SecNumCloud compliant regions (`cloudgouv-eu-west-1`).
You can set this certificates either by environment variables or by the static credentials inside the packer configuration file. You can set this certificates either by environment variables or by the static credentials inside the Packer configuration file.
#### Environment variables #### Environment variables

2
website/content/docs/builders/proxmox/clone.mdx
View File

@ -60,7 +60,7 @@ in the image's Cloud-Init settings for provisioning.
- `node` (string) - Which node in the Proxmox cluster to start the virtual - `node` (string) - Which node in the Proxmox cluster to start the virtual
machine on during creation. machine on during creation.
- `clone_vm` (string) - The name of the VM packer should clone and build from. - `clone_vm` (string) - The name of the VM Packer should clone and build from.
### Optional: ### Optional:

4
website/content/docs/builders/qemu.mdx
View File

@ -95,7 +95,7 @@ this build to run. We recommend you check out the
for a practical usage example. for a practical usage example.
Note that you will need to set `"headless": true` if you are running Packer Note that you will need to set `"headless": true` if you are running Packer
on a Linux server without X11; or if you are connected via ssh to a remote on a Linux server without X11; or if you are connected via SSH to a remote
Linux server and have not enabled X11 forwarding (`ssh -X`). Linux server and have not enabled X11 forwarding (`ssh -X`).
## Qemu Specific Configuration Reference ## Qemu Specific Configuration Reference
@ -199,7 +199,7 @@ necessary for this build to succeed and can be found further down the page.
Some users have experienced errors complaining about invalid keymaps. This Some users have experienced errors complaining about invalid keymaps. This
seems to be related to having a `common` directory or file in the directory seems to be related to having a `common` directory or file in the directory
they've run Packer in, like the packer source directory. This appears to be an they've run Packer in, like the Packer source directory. This appears to be an
upstream bug with qemu, and the best solution for now is to remove the upstream bug with qemu, and the best solution for now is to remove the
file/directory or run in another directory. file/directory or run in another directory.

6
website/content/docs/builders/tencentcloud-cvm.mdx
View File

@ -98,14 +98,14 @@ a [communicator](/docs/templates/legacy_json_templates/communicator) can be conf
- `vpc_id` (string) - Specify vpc your cvm will be launched by. - `vpc_id` (string) - Specify vpc your cvm will be launched by.
- `vpc_name` (string) - Specify vpc name you will create. if `vpc_id` is not set, packer will - `vpc_name` (string) - Specify vpc name you will create. if `vpc_id` is not set, Packer will
create a vpc for you named this parameter. create a vpc for you named this parameter.
- `cidr_block` (boolean) - Specify cider block of the vpc you will create if `vpc_id` is not set. - `cidr_block` (boolean) - Specify cider block of the vpc you will create if `vpc_id` is not set.
- `subnet_id` (string) - Specify subnet your cvm will be launched by. - `subnet_id` (string) - Specify subnet your cvm will be launched by.
- `subnet_name` (string) - Specify subnet name you will create. if `subnet_id` is not set, packer will - `subnet_name` (string) - Specify subnet name you will create. if `subnet_id` is not set, Packer will
create a subnet for you named this parameter. create a subnet for you named this parameter.
- `subnect_cidr_block` (boolean) - Specify cider block of the subnet you will create if - `subnect_cidr_block` (boolean) - Specify cider block of the subnet you will create if
@ -183,4 +183,4 @@ Here is a basic example for Tencentcloud.
See the See the
[examples/tencentcloud](https://github.com/hashicorp/packer/tree/master/builder/tencentcloud/examples) [examples/tencentcloud](https://github.com/hashicorp/packer/tree/master/builder/tencentcloud/examples)
folder in the packer project for more examples. folder in the Packer project for more examples.

2
website/content/docs/builders/vagrant.mdx
View File

@ -204,7 +204,7 @@ by Packer. You will now be able to connect to the new box with provisioned chang
## A note on SSH connections ## A note on SSH connections
Currently this builder only works for SSH connections, and automatically fills Currently this builder only works for SSH connections, and automatically fills
in all information needed for the ssh communicator using vagrant's ssh-config. in all information needed for the SSH communicator using vagrant's ssh-config.
If you would like to connect via a different username or authentication method If you would like to connect via a different username or authentication method
than is produced when you call `vagrant ssh-config`, then you must provide the than is produced when you call `vagrant ssh-config`, then you must provide the

4
website/content/docs/builders/vmware/iso.mdx
View File

@ -252,9 +252,9 @@ an open port, we try to connect to ports in the range of `vnc_port_min` to
`vnc_port_max`. If we notice something is listening on a port in the range, we `vnc_port_max`. If we notice something is listening on a port in the range, we
try to connect to the next one, and so on until we find a port that has nothing try to connect to the next one, and so on until we find a port that has nothing
listening on it. If you have many clients building on the ESXi host, there listening on it. If you have many clients building on the ESXi host, there
might be competition for the VNC ports. You can adjust how long packer waits might be competition for the VNC ports. You can adjust how long Packer waits
for a connection timeout by setting `PACKER_ESXI_VNC_PROBE_TIMEOUT`. This for a connection timeout by setting `PACKER_ESXI_VNC_PROBE_TIMEOUT`. This
defaults to 15 seconds. Set this shorter if vnc connections are refused, and defaults to 15 seconds. Set this shorter if VNC connections are refused, and
set it longer if Packer can't find an open port. This is intended as an set it longer if Packer can't find an open port. This is intended as an
advanced configuration option. Please make sure your firewall settings are advanced configuration option. Please make sure your firewall settings are
correct before adjusting. correct before adjusting.

2
website/content/docs/commands/build.mdx
View File

@ -54,7 +54,7 @@ artifacts that are created will be outputted at the end of the build.
- `-timestamp-ui` - Enable prefixing of each ui output with an RFC3339 - `-timestamp-ui` - Enable prefixing of each ui output with an RFC3339
timestamp. timestamp.
- `-var` - Set a variable in your packer template. This option can be used - `-var` - Set a variable in your Packer template. This option can be used
multiple times. This is useful for setting version numbers for your build. multiple times. This is useful for setting version numbers for your build.
- `-var-file` - Set template variables from a file. - `-var-file` - Set template variables from a file.

2
website/content/docs/commands/console.mdx
View File

@ -31,7 +31,7 @@ help output, which can be seen via `packer console -h`.
## Options ## Options
- `-var` - Set a variable in your packer template. This option can be used - `-var` - Set a variable in your Packer template. This option can be used
multiple times. This is useful for setting version numbers for your build. multiple times. This is useful for setting version numbers for your build.
example: `-var "myvar=asdf"` example: `-var "myvar=asdf"`

2
website/content/docs/commands/init.mdx
View File

@ -20,7 +20,7 @@ template. This command is always safe to run multiple times. Though subsequent
runs may give errors, this command will never delete anything. runs may give errors, this command will never delete anything.
Packer does not currently have the notion of a state like Terraform has. In other words, Packer does not currently have the notion of a state like Terraform has. In other words,
currently `packer init` is only in charge of installing packer plugins. currently `packer init` is only in charge of installing Packer plugins.
Currently, `packer init` can only fetch binaries from public projects on **GitHub**. GitHub's public API, [limits the number of unauthenticated requests Currently, `packer init` can only fetch binaries from public projects on **GitHub**. GitHub's public API, [limits the number of unauthenticated requests
per hour one IP can per hour one IP can

2
website/content/docs/commands/validate.mdx
View File

@ -50,7 +50,7 @@ Errors validating build 'vmware'. 1 error(s) occurred:
- `-machine-readable` Sets all output to become machine-readable on stdout. - `-machine-readable` Sets all output to become machine-readable on stdout.
Logging, if enabled, continues to appear on stderr. Logging, if enabled, continues to appear on stderr.
- `-var` - Set a variable in your packer template. This option can be used - `-var` - Set a variable in your Packer template. This option can be used
multiple times. This is useful for setting version numbers for your build. multiple times. This is useful for setting version numbers for your build.
- `-var-file` - Set template variables from a file. - `-var-file` - Set template variables from a file.

12
website/content/docs/configure.mdx
View File

@ -16,7 +16,7 @@ core configuration for now.
## Packer's home directory ## Packer's home directory
Plugins and core configuration files can exist in the home directory of Packer. 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 The home directory of Packer will be the first one of the following env values
to be set : to be set :
| unix | windows | | unix | windows |
@ -32,7 +32,7 @@ to be set :
## Packer's config file ## Packer's config file
Packer can optionally read a JSON file for the end user to set core settings. 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: The config file of Packer will be looked up on the following paths:
| unix | windows | | unix | windows |
| ------------------------------- | -------------------------------- | | ------------------------------- | -------------------------------- |
@ -43,8 +43,8 @@ It is not an error if no config file was found.
## Packer's config directory ## Packer's config directory
Packer's configuration directory can potentialy contain plugins and internal 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: Packer files. The config dir of Packer will be looked up on the following paths:
| unix | windows | | unix | windows |
| --------------------------- | --------------------------- | | --------------------------- | --------------------------- |
@ -69,9 +69,9 @@ The format of the configuration file is basic JSON.
## Packer's cache directory ## Packer's cache directory
Packer uses a cache directory to download large files and for logistics around Packer uses a cache directory to download large files and for logistics around
large file download. By default, Packer caches things in the curret directory, large file download. By default, Packer caches things in the current directory,
under: `./packer_cache/`. This can be changed by setting the `PACKER_CACHE_DIR` under: `./packer_cache/`. This can be changed by setting the `PACKER_CACHE_DIR`
env var. It is recommended to share the same packer cache dir accross your env var. It is recommended to share the same Packer cache dir across your
builds if you have multiple builds doing similar things to avoid downloading the builds if you have multiple builds doing similar things to avoid downloading the
same ISO twice for example. same ISO twice for example.

10
website/content/docs/debugging.mdx
View File

@ -21,10 +21,10 @@ usually will stop between each step, waiting for keyboard input before
continuing. This will allow you to inspect state and so on. continuing. This will allow you to inspect state and so on.
In debug mode once the remote instance is instantiated, Packer will emit to the In debug mode once the remote instance is instantiated, Packer will emit to the
current directory an ephemeral private ssh key as a .pem file. Using that you current directory an ephemeral private SSH key as a .pem file. Using that you
can `ssh -i <key.pem>` into the remote build instance and see what is going on can `ssh -i <key.pem>` into the remote build instance and see what is going on
for debugging. The key will only be emitted for cloud-based builders. The for debugging. The key will only be emitted for cloud-based builders. The
ephemeral key will be deleted at the end of the packer run during cleanup. ephemeral key will be deleted at the end of the Packer run during cleanup.
For a local builder, the SSH session initiated will be visible in the detail For a local builder, the SSH session initiated will be visible in the detail
provided when `PACKER_LOG=1` environment variable is set prior to a build, and provided when `PACKER_LOG=1` environment variable is set prior to a build, and
@ -34,10 +34,10 @@ the kickstart or preseed associated with initializing the local VM.
It should be noted that one of the options `-on-error` is to `retry`, the retry It should be noted that one of the options `-on-error` is to `retry`, the retry
of the step in question has limitations: of the step in question has limitations:
- the template packer is building is **not** reloaded from file. - the template Packer is building is **not** reloaded from file.
- the resources specified from builders **are** reloaded from file. - the resources specified from builders **are** reloaded from file.
Check the specfics on your builder to confirm their behavior. Check the specifics on your builder to confirm their behavior.
### Windows ### Windows
@ -108,7 +108,7 @@ successfully as the proper packages cannot be provisioned correctly. The
problem arises when cloud-init has not finished fully running on the source AMI problem arises when cloud-init has not finished fully running on the source AMI
by the time that packer starts any provisioning steps. by the time that packer starts any provisioning steps.
Adding the following provisioner to the packer template, allows for the Adding the following provisioner to the Packer template, allows for the
cloud-init process to fully finish before packer starts provisioning the source cloud-init process to fully finish before packer starts provisioning the source
AMI. AMI.

2
website/content/docs/post-processors/manifest.mdx
View File

@ -11,7 +11,7 @@ Type: `manifest`
Artifact BuilderId: `packer.post-processor.manifest` Artifact BuilderId: `packer.post-processor.manifest`
The manifest post-processor writes a JSON file with a list of all of the 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 artifacts packer produces during a run. If your Packer template includes
multiple builds, this helps you keep track of which output artifacts (files, 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.

298
website/content/docs/post-processors/shell-local.mdx
View File

@ -18,6 +18,25 @@ some task with packer outputs and variables.
The example below is a fully functional self-contained build. The example below is a fully functional self-contained build.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "file" "example" {
content = "example content"
}
build {
source "source.file.example" {
target = "./test_artifact.txt"
}
post-processor "shell-local" {
inline = ["echo foo"]
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -39,25 +58,6 @@ The example below is a fully functional self-contained build.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "file" "example" {
content = "example content"
}
build {
source "source.file.example" {
target = "./test_artifact.txt"
}
post-processor "shell-local" {
inline = ["echo foo"]
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -178,7 +178,7 @@ Optional parameters:
a beta feature. a beta feature.
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By - `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
default this is just 0. default this is `0`.
## Execute Command ## Execute Command
@ -209,6 +209,34 @@ likely not work unless both Packer and the scripts you want to run are both on
the C drive. the C drive.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
post-processor "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
scripts = ["C:/Users/me/scripts/example_bash.sh"]
}
post-processor "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "C:/Users/me/scripts/example_bash.sh"
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -238,34 +266,6 @@ the C drive.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
post-processor "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
scripts = ["C:/Users/me/scripts/example_bash.sh"]
}
post-processor "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "C:/Users/me/scripts/example_bash.sh"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -294,7 +294,7 @@ you much time in the process.
### Once Per Builder ### Once Per Builder
The `shell-local` script(s) you pass are run once per builder. That means that The `shell-local` script(s) you pass are run once per builder. This means that
if you have an `amazon-ebs` builder and a `docker` builder, your script will be if you have an `amazon-ebs` builder and a `docker` builder, your script will be
run twice. If you have 3 builders, it will run 3 times, once for each builder. run twice. If you have 3 builders, it will run 3 times, once for each builder.
@ -343,21 +343,21 @@ tarball, you might write this:
```hcl ```hcl
source "file" "example" { source "file" "example" {
content = "Lorem ipsum dolor sit amet" content = "Lorem ipsum dolor sit amet"
target = "dummy_artifact.txt" target = "dummy_artifact.txt"
} }
build { build {
sources = [ sources = [
"source.file.example" "source.file.example"
] ]
post-processor "manifest" { post-processor "manifest" {
output = "manifest.json" output = "manifest.json"
strip_path = true strip_path = true
} }
post-processor "shell-local" { post-processor "shell-local" {
inline = [ inline = [
"jq \".builds[].files[].name\" manifest.json | xargs tar cfz artifacts.tgz" "jq \".builds[].files[].name\" manifest.json | xargs tar cfz artifacts.tgz"
] ]
} }
} }
``` ```
@ -383,6 +383,16 @@ _must_ be extra careful to `exit 0` when necessary.
Example of running a .cmd file on windows: Example of running a .cmd file on windows:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
scripts = ["./scripts/test_cmd.cmd"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -393,20 +403,10 @@ Example of running a .cmd file on windows:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
scripts = ["./scripts/test_cmd.cmd"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Contents of "test_cmd.cmd": Contents of `test_cmd.cmd`:
echo %SHELLLOCALTEST% echo %SHELLLOCALTEST%
@ -414,6 +414,17 @@ Example of running an inline command on windows: Required customization:
tempfile_extension tempfile_extension
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
tempfile_extension = ".cmd",
inline = ["echo %SHELLLOCALTEST%"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -426,23 +437,24 @@ tempfile_extension
``` ```
</Tab> </Tab>
</Tabs>
Example of running a bash command on windows using WSL: Required
customizations: `use_linux_pathing` and `execute_command`:
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
post-processor "shell-local" { post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest2"], environment_vars = ["SHELLLOCALTEST=ShellTest3"],
tempfile_extension = ".cmd", execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
inline = [echo %SHELLLOCALTEST%"] use_linux_pathing = true
script = "./scripts/example_bash.sh"
} }
``` ```
</Tab> </Tab>
</Tabs>
Example of running a bash command on windows using WSL: Required
customizations: use_linux_pathing and execute_command
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -455,30 +467,30 @@ customizations: use_linux_pathing and execute_command
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest3"],
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "./scripts/example_bash.sh"
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Contents of "example_bash.sh": Contents of `example_bash.sh`:
#!/bin/bash #!/bin/bash
echo $SHELLLOCALTEST echo $SHELLLOCALTEST
Example of running a powershell script on windows: Required customizations: Example of running a PowerShell script on Windows:
env_var_format and execute_command Required customizations: `env_var_format` and `execute_command`.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest4"]
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
env_var_format = "$env:%s=\"%s\"; "
script = "./scripts/example_ps.ps1"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -492,24 +504,25 @@ env_var_format and execute_command
``` ```
</Tab> </Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
customizations: `env_var_format`, `tempfile_extension`, and `execute_command`
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
post-processor "shell-local" { post-processor "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest4"] tempfile_extension = ".ps1"
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"] environment_vars = ["SHELLLOCALTEST=ShellTest5"]
env_var_format = "$env:%s=\"%s\"; " execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
script = "./scripts/example_ps.ps1" env_var_format = "$env:%s=\"%s\"; "
inline = ["write-output $env:SHELLLOCALTEST"]
} }
``` ```
</Tab> </Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
customizations: env_var_format, tempfile_extension, and execute_command
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -523,27 +536,24 @@ customizations: env_var_format, tempfile_extension, and execute_command
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
tempfile_extension = ".ps1"
environment_vars = ["SHELLLOCALTEST=ShellTest5"]
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
env_var_format = "$env:%s=\"%s\"; "
inline = ["write-output $env:SHELLLOCALTEST"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
### Unix Host ### Unix Host
Example of running a bash script on unix: Example of running a Shell script on unix:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
scripts = ["./scripts/example_bash.sh"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -554,22 +564,23 @@ Example of running a bash script on unix:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
scripts = ["./scripts/example_bash.sh"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Example of running a bash "inline" on unix: Example of running a bash "inline" on unix:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
inline = ["echo hello", "echo $PROVISIONERTEST"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -580,23 +591,28 @@ Example of running a bash "inline" on unix:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
inline = ["echo hello", "echo $PROVISIONERTEST"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Example of running a python script on unix: Example of running a python script on unix:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
script = "hello.py"
environment_vars = ["HELLO_USER=packeruser"]
execute_command = [
"/bin/sh",
"-c",
"{{.Vars}} /usr/local/bin/python {{.Script}}"
]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -612,27 +628,13 @@ Example of running a python script on unix:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
post-processor "shell-local" {
script = "hello.py"
environment_vars = ["HELLO_USER=packeruser"]
execute_command = [
"/bin/sh",
"-c",
"{{.Vars}} /usr/local/bin/python {{.Script}}"
]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
```text
Where "hello.py" contains: Where "hello.py" contains:
import os import os
print('Hello, %s!' % os.getenv("HELLO_USER")) print('Hello, %s!' % os.getenv("HELLO_USER"))
```

10
website/content/docs/post-processors/vagrant-cloud.mdx
View File

@ -90,18 +90,18 @@ on Vagrant Cloud, as well as authentication and version information.
- `no_release` (string) - If set to true, does not release the version on - `no_release` (string) - If set to true, does not release the version on
Vagrant Cloud, making it active. You can manually release the version via Vagrant Cloud, making it active. You can manually release the version via
the API or Web UI. Defaults to false. the API or Web UI. Defaults to `false`.
- `insecure_skip_tls_verify` (boolean) - If set to true _and_ `vagrant_cloud_url` - `insecure_skip_tls_verify` (boolean) - If set to true _and_ `vagrant_cloud_url`
is set to something different than its default, it will set TLS InsecureSkipVerify is set to something different than its default, it will set TLS InsecureSkipVerify
to true. In other words, this will disable security checks of SSL. You may need to true. In other words, this will disable security checks of SSL. You may need
to set this option to true if your host at vagrant_cloud_url is using a to set this option to true if your host at `vagrant_cloud_url` is using a
self-signed certificate. self-signed certificate.
- `keep_input_artifact` (boolean) - When true, preserve the local box - `keep_input_artifact` (boolean) - When true, preserve the local box
after uploading to Vagrant cloud. Defaults to `true`. after uploading to Vagrant cloud. Defaults to `true`.
- `version_description` (string) - Optionally markdown text used as a - `version_description` (string) - Optional Markdown text used as a
full-length and in-depth description of the version, typically for denoting full-length and in-depth description of the version, typically for denoting
changes introduced changes introduced
@ -109,12 +109,12 @@ on Vagrant Cloud, as well as authentication and version information.
is set the box will not be uploaded to the Vagrant Cloud. is set the box will not be uploaded to the Vagrant Cloud.
This is a [template engine](/docs/templates/legacy_json_templates/engine). Therefore, you This is a [template engine](/docs/templates/legacy_json_templates/engine). Therefore, you
may use user variables and template functions in this field. may use user variables and template functions in this field.
The following extra variables are also avilable in this engine: The following extra variables are also available in this engine:
- `Provider`: The Vagrant provider the box is for - `Provider`: The Vagrant provider the box is for
- `ArtifactId`: The ID of the input artifact. - `ArtifactId`: The ID of the input artifact.
- `no_direct_upload` (boolean) - When true, upload the box artifact through - `no_direct_upload` (boolean) - When `true`, upload the box artifact through
Vagrant Cloud instead of directly to the backend storage. Vagrant Cloud instead of directly to the backend storage.
## Use with the Vagrant Post-Processor ## Use with the Vagrant Post-Processor

4
website/content/docs/post-processors/vagrant.mdx
View File

@ -49,7 +49,7 @@ post-processor doesn't support creating boxes for a provider you care about,
please help by contributing to Packer and adding support for it. please help by contributing to Packer and adding support for it.
Please note that if you are using the Vagrant builder, then the Vagrant Please note that if you are using the Vagrant builder, then the Vagrant
post-processor is unnecesary because the output of the Vagrant builder is post-processor is unnecessary because the output of the Vagrant builder is
already a Vagrant box; using this post-processor with the Vagrant builder will already a Vagrant box; using this post-processor with the Vagrant builder will
cause your build to fail. cause your build to fail.
@ -84,7 +84,7 @@ more details about certain options in following sections.
this post-processor. This is a this post-processor. This is a
[template engine](/docs/templates/legacy_json_templates/engine). Therefore, you may use user [template engine](/docs/templates/legacy_json_templates/engine). Therefore, you may use user
variables and template functions in this field. The following extra variables and template functions in this field. The following extra
variables are also avilable in this engine: variables are also available in this engine:
- `Provider`: The Vagrant provider the box is for - `Provider`: The Vagrant provider the box is for
- `ArtifactId`: The ID of the input artifact. - `ArtifactId`: The ID of the input artifact.

8
website/content/docs/post-processors/vsphere-template.mdx
View File

@ -78,8 +78,8 @@ Optional:
- `reregister_vm` (boolean) - Use the method of unregister VM and reregister - `reregister_vm` (boolean) - Use the method of unregister VM and reregister
as a template, rather than using the markAsTemplate method in vmWare. as a template, rather than using the markAsTemplate method in vmWare.
NOTE: If you are getting permission denied errors when trying to mark as a NOTE: If you are getting permission denied errors when trying to mark as a
template, but it works fine in the vSphere UI, try setting this to false. template, but it works fine in the vSphere UI, try setting this to `false`.
Default is true. Default is `true`.
## Using the vSphere Template with local builders ## Using the vSphere Template with local builders
@ -162,7 +162,7 @@ And this role must be authorized on the:
Some users have reported that vSphere templates created from local VMWare builds Some users have reported that vSphere templates created from local VMWare builds
get their boot order reset to cdrom only instead of the original boot order get their boot order reset to cdrom only instead of the original boot order
defined by the template. If this issue affects you, the solution is to set defined by the template. If this issue affects you, the solution is to set
`"bios.hddOrder": "scsi0:0"` in your builder's vmx_data. `"bios.hddOrder": "scsi0:0"` in your builder's `vmx_data`.
Packer doesn't automatically do this for you because it causes strange upload Packer doesn't automatically do this for you because it causes strange upload
behavior in certain versions of ovftool. behavior in certain versions of `ovftool`.

80
website/content/docs/post-processors/vsphere.mdx
View File

@ -47,13 +47,13 @@ Optional:
- `esxi_host` (string) - Target vSphere host. Used to assign specific esx - `esxi_host` (string) - Target vSphere host. Used to assign specific esx
host to upload the resulting VM to, when a vCenter Server is used as host to upload the resulting VM to, when a vCenter Server is used as
`host`. Can be either a hostname (e.g. "packer-esxi1", requires proper DNS `host`. Can be either a hostname (e.g. "packer-esxi1", requires proper DNS
setup and/or correct DNS search domain setting) or an ipv4 address. setup and/or correct DNS search domain setting) or an IPv4 address.
- `disk_mode` (string) - Target disk format. See `ovftool` manual for - `disk_mode` (string) - Target disk format. See `ovftool` manual for
available options. By default, "thick" will be used. available options. By default, `thick` will be used.
- `insecure` (boolean) - Whether or not the connection to vSphere can be done - `insecure` (boolean) - Whether or not the connection to vSphere can be done
over an insecure connection. By default this is false. over an insecure connection. By default this is `false`.
- `keep_input_artifact` (boolean) - When `true`, preserve the local VM files, - `keep_input_artifact` (boolean) - When `true`, preserve the local VM files,
even after importing them to vsphere. Defaults to `false`. even after importing them to vsphere. Defaults to `false`.
@ -66,9 +66,9 @@ Optional:
to. to.
- `overwrite` (boolean) - If it's true force the system to overwrite the - `overwrite` (boolean) - If it's true force the system to overwrite the
existing files instead create new ones. Default is false existing files instead create new ones. Default is `false`
- `options` (array of strings) - Custom options to add in ovftool. See - `options` (array of strings) - Custom options to add in `ovftool`. See
`ovftool --help` to list all the options `ovftool --help` to list all the options
# Example # Example
@ -80,6 +80,39 @@ to a vSphere cluster.
You can also use this post-processor with the vmx artifact from a vmware build. You can also use this post-processor with the vmx artifact from a vmware build.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
post-processors{
post-processor "artifice"{
files = ["output-vmware-iso/packer-vmware-iso.vmx"]
}
post-processor "vsphere"{
keep_input_artifact = true
vm_name = "packerparty"
vm_network = "VM Network"
cluster = "123.45.678.1"
datacenter = "PackerDatacenter"
datastore = "datastore1"
host = "123.45.678.9"
password = "SuperSecretPassword"
username = "Administrator@vsphere.local"
}
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -113,46 +146,13 @@ You can also use this post-processor with the vmx artifact from a vmware build.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
post-processors{
post-processor "artifice"{
files = ["output-vmware-iso/packer-vmware-iso.vmx"]
}
post-processor "vsphere"{
keep_input_artifact = true
vm_name = "packerparty"
vm_network = "VM Network"
cluster = "123.45.678.1"
datacenter = "PackerDatacenter"
datastore = "datastore1"
host = "123.45.678.9"
password = "SuperSecretPassword"
username = "Administrator@vsphere.local"
}
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
# Permissions # Permissions
The vsphere post processor uses ovftool and therefore needs the same privileges The vsphere post processor uses `ovftool` and therefore needs the same privileges
as ovftool. Rather than giving full administrator access, you can create a role as `ovftool`. Rather than giving full administrator access, you can create a role
to give the post-processor the permissions necessary to run. Below is an example to give the post-processor the permissions necessary to run. Below is an example
role. Please note that this is a user-supplied list so there may be a few role. Please note that this is a user-supplied list so there may be a few
extraneous permissions that are not strictly required. extraneous permissions that are not strictly required.

12
website/content/docs/provisioners/ansible-local.mdx
View File

@ -2,7 +2,7 @@
description: > description: >
The ansible-local Packer provisioner will run ansible in ansible's "local" The ansible-local Packer provisioner will run ansible in ansible's "local"
mode on the remote/guest VM using Playbook and Role files that exist on the mode on the remote/guest VM using Playbook and Role files that exist on the
guest VM. This means ansible must be installed on the remote/guest VM. guest VM. This means Ansible must be installed on the remote/guest VM.
Playbooks and Roles can be uploaded from your build machine (the one running Playbooks and Roles can be uploaded from your build machine (the one running
Packer) to the vm. Packer) to the vm.
page_title: Ansible Local - Provisioners page_title: Ansible Local - Provisioners
@ -12,9 +12,9 @@ page_title: Ansible Local - Provisioners
Type: `ansible-local` Type: `ansible-local`
The `ansible-local` Packer provisioner will run ansible in ansible's "local" The `ansible-local` Packer provisioner will execute `ansible` in Ansible's "local"
mode on the remote/guest VM using Playbook and Role files that exist on the mode on the remote/guest VM using Playbook and Role files that exist on the
guest VM. This means ansible must be installed on the remote/guest VM. guest VM. This means Ansible must be installed on the remote/guest VM.
Playbooks and Roles can be uploaded from your build machine (the one running Playbooks and Roles can be uploaded from your build machine (the one running
Packer) to the vm. Ansible is then run on the guest machine in [local Packer) to the vm. Ansible is then run on the guest machine in [local
mode](https://docs.ansible.com/ansible/latest/playbooks_delegation.html#local-playbooks) mode](https://docs.ansible.com/ansible/latest/playbooks_delegation.html#local-playbooks)
@ -128,9 +128,9 @@ commonly useful Ansible variables:
run only certain parts of the playbook on systems built with certain run only certain parts of the playbook on systems built with certain
builders. builders.
- `packer_http_addr` If using a builder that provides an http server for file - `packer_http_addr` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.

413
website/content/docs/provisioners/ansible.mdx
View File

@ -34,6 +34,27 @@ DigitalOcean. Replace the mock `api_token` value with your own.
Example Packer template: Example Packer template:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "digitalocean" "example"{
api_token = "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb"
image = "ubuntu-20-04-x64"
region = "sfo1"
}
build {
sources = [
"source.digitalocean.example"
]
provisioner "ansible" {
playbook_file = "./playbook.yml"
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -42,7 +63,7 @@ Example Packer template:
{ {
"type": "digitalocean", "type": "digitalocean",
"api_token": "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb", "api_token": "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb",
"image": "ubuntu-14-04-x64", "image": "ubuntu-20-04-x64",
"region": "sfo1" "region": "sfo1"
} }
], ],
@ -55,26 +76,6 @@ Example Packer template:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "digitalocean" "example"{
api_token = "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb"
image = "ubuntu-14-04-x64"
region = "sfo1"
}
build {
sources = [
"source.digitalocean.example"
]
provisioner "ansible" {
playbook_file = "./playbook.yml"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -121,10 +122,10 @@ commonly useful Ansible variables:
run only certain parts of the playbook on systems built with certain run only certain parts of the playbook on systems built with certain
builders. builders.
- `packer_http_addr` If using a builder that provides an http server for file - `packer_http_addr` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.
@ -134,19 +135,19 @@ To debug underlying issues with Ansible, add `"-vvvv"` to `"extra_arguments"`
to enable verbose logging. to enable verbose logging.
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"extra_arguments": [ "-vvvv" ]
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
extra_arguments = [ "-vvvv" ] extra_arguments = [ "-vvvv" ]
``` ```
</Tab>
<Tab heading="JSON">
```json
"extra_arguments": [ "-vvvv" ]
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -168,6 +169,32 @@ Building within a chroot (e.g. `amazon-chroot`) requires changing the Ansible
connection to chroot and running Ansible as root/sudo. connection to chroot and running Ansible as root/sudo.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "amazon-chroot" "example" {
mount_path = "/mnt/packer-amazon-chroot"
region = "us-east-1"
source_ami = "ami-123456"
}
build {
sources = [
"source.amazon-chroot.example"
]
provisioner "ansible" {
extra_arguments = [
"--connection=chroot",
"--inventory-file=/mnt/packer-amazon-chroot"
]
playbook_file = "main.yml"
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -193,36 +220,12 @@ connection to chroot and running Ansible as root/sudo.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "amazon-chroot" "example" {
mount_path = "/mnt/packer-amazon-chroot"
region = "us-east-1"
source_ami = "ami-123456"
}
build {
sources = [
"source.amazon-chroot.example"
]
provisioner "ansible" {
extra_arguments = [
"--connection=chroot",
"--inventory-file=/mnt/packer-amazon-chroot"
]
playbook_file = "main.yml"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
### WinRM Communicator ### WinRM Communicator
There are two possible methods for using ansible with the WinRM communicator. There are two possible methods for using Ansible with the WinRM communicator.
Please note that if you're having trouble getting Ansible to connect, you may Please note that if you're having trouble getting Ansible to connect, you may
want to take a look at the script that the Ansible project provides to help want to take a look at the script that the Ansible project provides to help
@ -240,6 +243,57 @@ extra_arguments.
Below is a fully functioning Ansible example using WinRM: Below is a fully functioning Ansible example using WinRM:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
data "amazon-ami" "ubuntu" {
access_key = var.aws_access_key
filters = {
name = "ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"
root-device-type = "ebs"
virtualization-type = "hvm"
}
most_recent = true
owners = ["099720109477"]
region = var.aws_region
secret_key = var.aws_secret_key
}
source "amazon-ebs" "example" {
region = "us-east-1"
instance_type = "t2.micro"
source_ami = data.amazon-ami.ubuntu.id
ami_name = "test-ansible-packer"
user_data_file = "windows_bootstrap.txt"
communicator = "winrm"
force_deregister = true
winrm_username = "Administrator"
winrm_insecure = true
winrm_use_ssl = true
}
build {
sources = [
"source.amazon-ebs.example",
]
provisioner "ansible" {
playbook_file = "./playbooks/playbook-windows.yml"
user = "Administrator"
use_proxy = false
extra_arguments = [
"-e",
"ansible_winrm_server_cert_validation=ignore"
]
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -279,53 +333,13 @@ Below is a fully functioning Ansible example using WinRM:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "amazon-ebs" "example" {
region = "us-east-1"
instance_type = "t2.micro"
source_ami_filter {
filters = {
"virtualization-type": "hvm",
"name": "*Windows_Server-2012*English-64Bit-Base*",
"root-device-type": "ebs"
}
most_recent = true
owners = ["amazon"]
}
ami_name = "test-ansible-packer"
user_data_file = "windows_bootstrap.txt"
communicator = "winrm"
force_deregister = true
winrm_username = "Administrator"
winrm_insecure = true
winrm_use_ssl = true
}
build {
sources = [
"source.amazon-ebs.example",
]
provisioner "ansible" {
playbook_file = "./playbooks/playbook-windows.yml"
user = "Administrator"
use_proxy = false
extra_arguments = [
"-e", "ansible_winrm_server_cert_validation=ignore"
]
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Note that you do have to set the "Administrator" user, because otherwise Ansible Note that you do have to set the "Administrator" user, because otherwise Ansible
will default to using the user that is calling Packer, rather than the user will default to using the user that is calling Packer, rather than the user
configured inside of the Packer communicator. For the contents of configured inside of the Packer communicator. For the contents of
windows_bootstrap.txt, see the winrm docs for the amazon-ebs communicator. windows_bootstrap.txt, see the WinRM docs for the amazon-ebs communicator.
When running from OSX, you may see an error like: When running from OSX, you may see an error like:
@ -339,19 +353,19 @@ If you see this, you may be able to work around the issue by telling Ansible to
explicitly not use any proxying; you can do this by setting the template option explicitly not use any proxying; you can do this by setting the template option
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"ansible_env_vars": ["no_proxy=\"*\""],
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
ansible_env_vars = ["no_proxy=\"*\""] ansible_env_vars = ["no_proxy=\"*\""]
``` ```
</Tab>
<Tab heading="JSON">
```json
"ansible_env_vars": ["no_proxy=\"*\""],
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -359,7 +373,7 @@ in the above Ansible template.
#### Method 2 (Not recommended) #### Method 2 (Not recommended)
If you want to use the Packer ssh proxy, then you need a custom Ansible If you want to use the Packer SSH proxy, then you need a custom Ansible
connection plugin and a particular configuration. You need a directory named connection plugin and a particular configuration. You need a directory named
`connection_plugins` next to the playbook which contains a file named `connection_plugins` next to the playbook which contains a file named
packer.py` which implements the connection plugin. On versions of Ansible packer.py` which implements the connection plugin. On versions of Ansible
@ -496,24 +510,34 @@ $ ssh-add -D
### Become: yes ### Become: yes
We recommend against running Packer as root; if you do then you won't be able We recommend against running Packer as root; if you do then you won't be able
to successfully run your ansible playbook as root; `become: yes` will fail. to successfully run your Ansible playbook as root; `become: yes` will fail.
### Using a wrapping script for your ansible call ### Using a wrapping script for your Ansible call
Sometimes, you may have extra setup that needs to be called as part of your Sometimes, you may have extra setup that needs to be called as part of your
ansible run. The easiest way to do this is by writing a small bash script and ansible run. The easiest way to do this is by writing a small bash script and
using that bash script in your "command" in place of the default using that bash script in your "command" in place of the default
"ansible-playbook". For example, you may need to launch a Python virtualenv "ansible-playbook". For example, you may need to launch a Python virtualenv
before calling ansible. To do this, you'd want to create a bash script like before calling Ansible. To do this, you'd want to create a bash script like
```shell ```shell
#!/bin/bash #!/bin/bash
source /tmp/venv/bin/activate && ANSIBLE_FORCE_COLOR=1 PYTHONUNBUFFERED=1 /tmp/venv/bin/ansible-playbook "$@" source /tmp/venv/bin/activate && ANSIBLE_FORCE_COLOR=1 PYTHONUNBUFFERED=1 /tmp/venv/bin/ansible-playbook "$@"
``` ```
The ansible provisioner template remains very simple. For example: The Ansible provisioner template remains very simple. For example:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "ansible" {
command = "/Path/To/call_ansible.sh"
playbook_file = "./playbook.yml"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -524,22 +548,12 @@ The ansible provisioner template remains very simple. For example:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "ansible" {
command = "/Path/To/call_ansible.sh"
playbook_file = "./playbook.yml"
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Note that we're calling ansible-playbook at the end of this command and passing Note that we're calling ansible-playbook at the end of this command and passing
all command line arguments through into this call; this is necessary for all command line arguments through into this call; this is necessary for
making sure that --extra-vars and other important ansible arguments get set. making sure that --extra-vars and other important Ansible arguments get set.
Note the quoting around the bash array, too; if you don't use quotes, any Note the quoting around the bash array, too; if you don't use quotes, any
arguments with spaces will not be read properly. arguments with spaces will not be read properly.
@ -556,6 +570,40 @@ On a CI server you probably want to overwrite ansible_host with a random name.
Example Packer template: Example Packer template:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
variable "ansible_host" {
default = "default"
}
variable "ansible_connection" {
default = "docker"
}
source "docker" "example" {
image = "centos:7"
commit = true
run_command = [ "-d", "-i", "-t", "--name", var.ansible_host, "{{.Image}}", "/bin/bash" ]
}
build {
sources = [
"source.docker.example"
]
provisioner "ansible" {
groups = [ "webserver" ]
playbook_file = "./webserver.yml"
extra_arguments = [
"--extra-vars",
"ansible_host=${var.ansible_host} ansible_connection=${var.ansible_connection}"
]
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -594,40 +642,6 @@ Example Packer template:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
variable "ansible_host" {
default = "default"
}
variable "ansible_connection" {
default = "docker"
}
source "docker" "example" {
image = "centos:7"
commit = true
run_command = [ "-d", "-i", "-t", "--name", var.ansible_host, "{{.Image}}", "/bin/bash" ]
}
build {
sources = [
"source.docker.example"
]
provisioner "ansible" {
groups = [ "webserver" ]
playbook_file = "./webserver.yml"
extra_arguments = [
"--extra-vars",
"ansible_host=${var.ansible_host} ansible_connection=${var.ansible_connection}"
]
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -665,6 +679,18 @@ provisioned otherwise you may run into a TargetNotConnected error. Users can use
their configured region. their configured region.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "ansible" {
use_proxy = false
playbook_file = "./playbooks/playbook_remote.yml"
ansible_env_vars = ["PACKER_BUILD_NAME={{ build_name }}"]
inventory_file_template = "{{ .HostAlias }} ansible_host={{ .ID }} ansible_user={{ .User }} ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyCommand=\"sh -c \\\"aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p\\\"\"'\n"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -680,23 +706,52 @@ their configured region.
``` ```
</Tab> </Tab>
</Tabs>
Full Packer template example:
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
variables {
instance_role = "SSMInstanceProfile"
}
source "amazon-ebs" "ansible-example" {
region = "us-east-1"
ami_name = "packer-ami-ansible"
instance_type = "t2.micro"
source_ami_filter {
filters = {
name = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
virtualization-type = "hvm"
root-device-type = "ebs"
}
owners = [ "099720109477" ]
most_recent = true
}
communicator = "ssh"
ssh_username = "ubuntu"
ssh_interface = "session_manager"
iam_instance_profile = var.instance_role
}
build {
sources = ["source.amazon-ebs.ansible-example"]
provisioner "ansible" { provisioner "ansible" {
use_proxy = false use_proxy = false
playbook_file = "./playbooks/playbook_remote.yml" playbook_file = "./playbooks/playbook_remote.yml"
ansible_env_vars = ["PACKER_BUILD_NAME={{ build_name }}"] ansible_env_vars = ["PACKER_BUILD_NAME={{ build_name }}"]
inventory_file_template = "{{ .HostAlias }} ansible_host={{ .ID }} ansible_user={{ .User }} ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyCommand=\"sh -c \\\"aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p\\\"\"'\n" inventory_file_template = "{{ .HostAlias }} ansible_host={{ .ID }} ansible_user={{ .User }} ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyCommand=\"sh -c \\\"aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p\\\"\"'\n"
} }
}
``` ```
</Tab> </Tab>
</Tabs>
Full Packer template example:
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -738,46 +793,6 @@ Full Packer template example:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
variables {
instance_role = "SSMInstanceProfile"
}
source "amazon-ebs" "ansible-example" {
region = "us-east-1"
ami_name = "packer-ami-ansible"
instance_type = "t2.micro"
source_ami_filter {
filters = {
name = "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*"
virtualization-type = "hvm"
root-device-type = "ebs"
}
owners = [ "099720109477" ]
most_recent = true
}
communicator = "ssh"
ssh_username = "ubuntu"
ssh_interface = "session_manager"
iam_instance_profile = var.instance_role
}
build {
sources = ["source.amazon-ebs.ansible-example"]
provisioner "ansible" {
use_proxy = false
playbook_file = "./playbooks/playbook_remote.yml"
ansible_env_vars = ["PACKER_BUILD_NAME={{ build_name }}"]
inventory_file_template = "{{ .HostAlias }} ansible_host={{ .ID }} ansible_user={{ .User }} ansible_ssh_common_args='-o StrictHostKeyChecking=no -o ProxyCommand=\"sh -c \\\"aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters portNumber=%p\\\"\"'\n"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>

104
website/content/docs/provisioners/inspec.mdx
View File

@ -24,6 +24,26 @@ This is a fully functional template that will test an image on DigitalOcean.
Replace the mock `api_token` value with your own. Replace the mock `api_token` value with your own.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "digitalocean" "example"{
api_token = "<digital ocean api token>"
image = "ubuntu-14-04-x64"
region = "sfo1"
}
build {
sources = [
"source.digitalocean.example"
]
provisioner "inspec" {
profile = "https://github.com/dev-sec/linux-baseline"
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -46,26 +66,6 @@ Replace the mock `api_token` value with your own.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "digitalocean" "example"{
api_token = "<digital ocean api token>"
image = "ubuntu-14-04-x64"
region = "sfo1"
}
build {
sources = [
"source.digitalocean.example"
]
provisioner "inspec" {
profile = "https://github.com/dev-sec/linux-baseline"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -81,19 +81,19 @@ Optional Parameters:
running InSpec. Usage example: running InSpec. Usage example:
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"inspec_env_vars": [ "FOO=bar" ]
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
inspec_env_vars = [ "FOO=bar" ] inspec_env_vars = [ "FOO=bar" ]
``` ```
</Tab>
<Tab heading="JSON">
```json
"inspec_env_vars": [ "FOO=bar" ]
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -104,26 +104,26 @@ Optional Parameters:
not be quoted. Usage example: not be quoted. Usage example:
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"extra_arguments": [ "--sudo", "--reporter", "json" ]
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
extra_arguments = [ "--sudo", "--reporter", "json" ] extra_arguments = [ "--sudo", "--reporter", "json" ]
``` ```
</Tab>
<Tab heading="JSON">
```json
"extra_arguments": [ "--sudo", "--reporter", "json" ]
```
</Tab> </Tab>
</Tabs> </Tabs>
- `attributes` (array of strings) - Attribute Files used by InSpec which will - `attributes` (array of strings) - Attribute Files used by InSpec which will
be passed to the `--input-file` argument of the `inspec` command when this be passed to the `--input-file` argument of the `inspec` command when this
provisioner runs InSpec. Specify this if you want a different location. provisioner runs InSpec. Specify this if you want a different location.
Note using also `"--input-file"` in `extra_arguments` will override this Note that also using `"--input-file"` in `extra_arguments` will override this
setting. setting.
- `attributes_directory` (string) - The directory in which to place the - `attributes_directory` (string) - The directory in which to place the
@ -171,6 +171,16 @@ Chef InSpec requires accepting the license before starting to use the tool.
This can be done via `inspec_env_vars` in the template: This can be done via `inspec_env_vars` in the template:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "inspec" {
inspec_env_vars = [ "CHEF_LICENSE=accept"]
profile = "https://github.com/dev-sec/linux-baseline"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -183,16 +193,6 @@ This can be done via `inspec_env_vars` in the template:
] ]
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "inspec" {
inspec_env_vars = [ "CHEF_LICENSE=accept"]
profile = "https://github.com/dev-sec/linux-baseline"
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -219,18 +219,18 @@ To debug underlying issues with InSpec, add `"-l"` to `"extra_arguments"` to
enable verbose logging. enable verbose logging.
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"extra_arguments": ["-l", "debug"]
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
extra_arguments = ["-l", "debug"] extra_arguments = ["-l", "debug"]
``` ```
</Tab>
<Tab heading="JSON">
```json
"extra_arguments": ["-l", "debug"]
```
</Tab> </Tab>
</Tabs> </Tabs>

214
website/content/docs/provisioners/powershell.mdx
View File

@ -21,6 +21,15 @@ for details.
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
inline = ["dir c:\\"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -30,15 +39,6 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
inline = ["dir c:\\"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -82,6 +82,16 @@ provisioner "powershell" {
accessing the `build` variables For example: accessing the `build` variables For example:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
environment_vars = ["WINRMPASS=${build.Password}"]
inline = ["Write-Host \"Automatically generated aws password is: $Env:WINRMPASS\""]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -92,16 +102,6 @@ provisioner "powershell" {
}, },
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
environment_vars = ["WINRMPASS=${build.Password}"]
inline = ["Write-Host \"Automatically generated aws password is: $Env:WINRMPASS\""]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -140,6 +140,16 @@ provisioner "powershell" {
accessing the `build` variables For example: accessing the `build` variables For example:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
elevated_user = "Administrator"
elevated_password = build.Password
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -151,16 +161,6 @@ provisioner "powershell" {
}, },
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
elevated_user = "Administrator"
elevated_password = build.Password
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -168,6 +168,16 @@ If you specify an empty `elevated_password` value then the PowerShell
script is run as a service account. For example: script is run as a service account. For example:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
elevated_user = "SYSTEM"
elevated_password = ""
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -179,24 +189,14 @@ script is run as a service account. For example:
}, },
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
elevated_user = "SYSTEM"
elevated_password = ""
}
```
</Tab> </Tab>
</Tabs> </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 "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", are `bypass`, `allsigned`, `default`, `remotesigned`, `restricted`,
"undefined", "unrestricted", "none". `undefined`, `unrestricted`, and `none`.
- `remote_path` (string) - The path where the PowerShell script will be - `remote_path` (string) - The path where the PowerShell script will be
uploaded to within the target build machine. This defaults to uploaded to within the target build machine. This defaults to
@ -227,7 +227,7 @@ provisioner "powershell" {
value set for `skip_clean`. value set for `skip_clean`.
- `start_retry_timeout` (string) - The amount of time to attempt to _start_ - `start_retry_timeout` (string) - The amount of time to attempt to _start_
the remote process. By default this is "5m" or 5 minutes. This setting the remote process. By default this is `5m` or 5 minutes. This setting
exists in order to deal with times when SSH may restart, such as a system 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. reboot. Set this to a higher value if reboots take a longer amount of time.
@ -249,10 +249,10 @@ commonly useful environmental variables:
run only certain parts of the script on systems built with certain run only certain parts of the script on systems built with certain
builders. builders.
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file - `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.
@ -276,6 +276,16 @@ dollar sign backslash escaped so that it is not interpreted by the remote Bash
shell - Bash being the default shell for Cygwin environments. shell - Bash being the default shell for Cygwin environments.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
execute_command = "powershell -executionpolicy bypass \"& { if (Test-Path variable:global:ProgressPreference){\\$ProgressPreference='SilentlyContinue'};. {{.Vars}}; &'{{.Path}}'; exit \\$LastExitCode }\""
inline = [ "Write-Host \"Hello from PowerShell\""]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -288,16 +298,6 @@ shell - Bash being the default shell for Cygwin environments.
] ]
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
execute_command = "powershell -executionpolicy bypass \"& { if (Test-Path variable:global:ProgressPreference){\\$ProgressPreference='SilentlyContinue'};. {{.Vars}}; &'{{.Path}}'; exit \\$LastExitCode }\""
inline = [ "Write-Host \"Hello from PowerShell\""]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -316,6 +316,21 @@ quotes appear within double quotes, the addition of a backslash escape is
required for the JSON template to be parsed correctly. required for the JSON template to be parsed correctly.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
inline = [
"Write-Host \"A literal dollar `$ must be escaped\"",
"Write-Host \"A literal backtick `` must be escaped\"",
"Write-Host \"Here `\"double quotes`\" must be escaped\"",
"Write-Host \"Here `'single quotes`' don`'t really need to be\"",
"Write-Host \"escaped... but it doesn`'t hurt to do so.\"",
]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -333,21 +348,6 @@ required for the JSON template to be parsed correctly.
] ]
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "powershell" {
inline = [
"Write-Host \"A literal dollar `$ must be escaped\"",
"Write-Host \"A literal backtick `` must be escaped\"",
"Write-Host \"Here `\"double quotes`\" must be escaped\"",
"Write-Host \"Here `'single quotes`' don`'t really need to be\"",
"Write-Host \"escaped... but it doesn`'t hurt to do so.\"",
]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -370,6 +370,43 @@ Special characters appearing in user environment variable values and in the
for the user. There is no need to use escapes in these instances. for the user. There is no need to use escapes in these instances.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
variable "psvar" {
type = string
default = "My$tring"
}
build {
sources = ["source.amazon-ebs.example"]
provisioner "powershell" {
elevated_user = "Administrator"
elevated_password = "Super$3cr3t!"
inline = ["Write-Output \"The dollar in the elevated_password is interpreted correctly\""]
}
provisioner "powershell" {
environment_vars = [
"VAR1=A$Dollar",
"VAR2=A`Backtick",
"VAR3=A'SingleQuote",
"VAR4=A\"DoubleQuote",
"VAR5=${var.psvar}",
]
inline = [
"Write-Output \"In the following examples the special character is interpreted correctly:\"",
"Write-Output \"The dollar in VAR1: $Env:VAR1\"",
"Write-Output \"The backtick in VAR2: $Env:VAR2\"",
"Write-Output \"The single quote in VAR3: $Env:VAR3\"",
"Write-Output \"The double quote in VAR4: $Env:VAR4\"",
"Write-Output \"The dollar in VAR5 (expanded from a user var): $Env:VAR5\"",
]
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -408,43 +445,6 @@ for the user. There is no need to use escapes in these instances.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
variable "psvar" {
type = string
default = "My$tring"
}
build {
sources = ["source.amazon-ebs.example"]
provisioner "powershell" {
elevated_user = "Administrator"
elevated_password = "Super$3cr3t!"
inline = ["Write-Output \"The dollar in the elevated_password is interpreted correctly\""]
}
provisioner "powershell" {
environment_vars = [
"VAR1=A$Dollar",
"VAR2=A`Backtick",
"VAR3=A'SingleQuote",
"VAR4=A\"DoubleQuote",
"VAR5=${var.psvar}",
]
inline = [
"Write-Output \"In the following examples the special character is interpreted correctly:\"",
"Write-Output \"The dollar in VAR1: $Env:VAR1\"",
"Write-Output \"The backtick in VAR2: $Env:VAR2\"",
"Write-Output \"The single quote in VAR3: $Env:VAR3\"",
"Write-Output \"The double quote in VAR4: $Env:VAR4\"",
"Write-Output \"The dollar in VAR5 (expanded from a user var): $Env:VAR5\"",
]
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>

18
website/content/docs/provisioners/salt-masterless.mdx
View File

@ -20,6 +20,15 @@ master.
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "salt-masterless" {
local_state_tree = "/Users/me/salt"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -29,15 +38,6 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "salt-masterless" {
local_state_tree = "/Users/me/salt"
}
```
</Tab> </Tab>
</Tabs> </Tabs>

288
website/content/docs/provisioners/shell-local.mdx
View File

@ -24,6 +24,25 @@ scripts on a remote machine.
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "file" "example" {
content = "example content"
}
build {
source "source.file.example" {
target = "./test_artifact.txt"
}
provisioner "shell-local" {
inline = ["echo foo"]
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -45,32 +64,13 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "file" "example" {
content = "example content"
}
build {
source "source.file.example" {
target = "./test_artifact.txt"
}
provisioner "shell-local" {
inline = ["echo foo"]
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
## Configuration Reference ## Configuration Reference
The reference of available configuration options is listed below. The only The reference of available configuration options is listed below. The only
required element is "command". required element is `command`.
Exactly _one_ of the following is required: Exactly _one_ of the following is required:
@ -86,7 +86,7 @@ Exactly _one_ of the following is required:
they are all executed within the same context. This allows you to change they are all executed within the same context. This allows you to change
directories in one command and use something in the directory in the next directories in one command and use something in the directory in the next
and so on. Inline scripts are the easiest way to pull off simple tasks and so on. Inline scripts are the easiest way to pull off simple tasks
within the machine in which packer is running. within the machine in which Packer is running.
- `script` (string) - The path to a script to execute. This path can be - `script` (string) - The path to a script to execute. This path can be
absolute or relative. If it is relative, it is relative to the working absolute or relative. If it is relative, it is relative to the working
@ -169,7 +169,7 @@ Optional parameters:
ignore this option. ignore this option.
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By - `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
default this is just 0. default this is `0`.
@include 'provisioners/common-config.mdx' @include 'provisioners/common-config.mdx'
@ -200,6 +200,34 @@ Please note that the WSL is a beta feature, and this tool is not guaranteed to
work as you expect it to. work as you expect it to.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
provisioner "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
scripts = ["C:/Users/me/scripts/example_bash.sh"]
}
provisioner "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "C:/Users/me/scripts/example_bash.sh"
}
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -229,34 +257,6 @@ work as you expect it to.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
source "null" "example" {
communicator = "none"
}
build {
sources = [
"source.null.example"
]
provisioner "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
scripts = ["C:/Users/me/scripts/example_bash.sh"]
}
provisioner "shell-local"{
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "C:/Users/me/scripts/example_bash.sh"
}
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -275,17 +275,17 @@ commonly useful environmental variables:
run only certain parts of the script on systems built with certain run only certain parts of the script on systems built with certain
builders. builders.
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file - `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.
## Safely Writing A Script ## Safely Writing A Script
Whether you use the `inline` option, or pass it a direct `script` or `scripts`, Whether you use the `inline` option, or pass it a direct `script` or `scripts`,
it is important to understand a few things about how the shell-local it is important to understand a few things about how the `shell-local`
provisioner works to run it safely and easily. This understanding will save you provisioner works to run it safely and easily. This understanding will save you
much time in the process. much time in the process.
@ -310,6 +310,16 @@ _must_ be extra careful to `exit 0` when necessary.
Example of running a .cmd file on windows: Example of running a .cmd file on windows:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
scripts = ["./scripts/test_cmd.cmd"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -320,16 +330,6 @@ Example of running a .cmd file on windows:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
scripts = ["./scripts/test_cmd.cmd"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -341,6 +341,17 @@ Example of running an inline command on windows: Required customization:
tempfile_extension tempfile_extension
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
tempfile_extension = ".cmd",
inline = [echo "%SHELLLOCALTEST%"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -352,17 +363,6 @@ tempfile_extension
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
tempfile_extension = ".cmd",
inline = [echo %SHELLLOCALTEST%"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -370,6 +370,18 @@ Example of running a bash command on windows using WSL: Required
customizations: use_linux_pathing and execute_command customizations: use_linux_pathing and execute_command
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest3"],
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "./scripts/example_bash.sh"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -382,30 +394,30 @@ customizations: use_linux_pathing and execute_command
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest3"],
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
use_linux_pathing = true
script = "./scripts/example_bash.sh"
}
```
</Tab> </Tab>
</Tabs> </Tabs>
Contents of "example_bash.sh": Contents of `example_bash.sh`:
#!/bin/bash #!/bin/bash
echo $SHELLLOCALTEST 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 `env_var_format` and `execute_command`
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest4"]
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
env_var_format = "$env:%s=\"%s\"; "
script = "./scripts/example_ps.ps1"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -419,24 +431,25 @@ env_var_format and execute_command
``` ```
</Tab> </Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
customizations: `env_var_format`, `tempfile_extension`, and `execute_command`
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
provisioner "shell-local" { provisioner "shell-local" {
environment_vars = ["SHELLLOCALTEST=ShellTest4"] tempfile_extension = ".ps1"
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"] environment_vars = ["SHELLLOCALTEST=ShellTest5"]
env_var_format = "$env:%s=\"%s\"; " execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
script = "./scripts/example_ps.ps1" env_var_format = "$env:%s=\"%s\"; "
inline = ["write-output $env:SHELLLOCALTEST"]
} }
``` ```
</Tab> </Tab>
</Tabs>
Example of running a powershell script on windows as "inline": Required
customizations: env_var_format, tempfile_extension, and execute_command
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -450,27 +463,24 @@ customizations: env_var_format, tempfile_extension, and execute_command
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
tempfile_extension = ".ps1"
environment_vars = ["SHELLLOCALTEST=ShellTest5"]
execute_command = ["powershell.exe", "{{.Vars}} {{.Script}}"]
env_var_format = "$env:%s=\"%s\"; "
inline = ["write-output $env:SHELLLOCALTEST"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
### Unix Host ### Unix Host
Example of running a bash script on unix: Example of running a Shell script on unix:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
scripts = ["./scripts/example_bash.sh"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -482,21 +492,22 @@ Example of running a bash script on unix:
``` ```
</Tab> </Tab>
</Tabs>
Example of running a Shell script "inline" on unix:
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
provisioner "shell-local" { provisioner "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"] environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
scripts = ["./scripts/example_bash.sh"] inline = ["echo hello", "echo $PROVISIONERTEST"]
} }
``` ```
</Tab> </Tab>
</Tabs>
Example of running a bash "inline" on unix:
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -508,22 +519,27 @@ Example of running a bash "inline" on unix:
``` ```
</Tab> </Tab>
</Tabs>
Example of running a Python script on unix:
<Tabs>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
provisioner "shell-local" { provisioner "shell-local" {
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"] script = "hello.py"
inline = ["echo hello", "echo $PROVISIONERTEST"] environment_vars = ["HELLO_USER=packeruser"]
execute_command = [
"/bin/sh",
"-c",
"{{.Vars}} /usr/local/bin/python {{.Script}}"
]
} }
``` ```
</Tab> </Tab>
</Tabs>
Example of running a python script on unix:
<Tabs>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -539,27 +555,13 @@ Example of running a python script on unix:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell-local" {
script = "hello.py"
environment_vars = ["HELLO_USER=packeruser"]
execute_command = [
"/bin/sh",
"-c",
"{{.Vars}} /usr/local/bin/python {{.Script}}"
]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
```text
Where "hello.py" contains: Where "hello.py" contains:
import os import os
print('Hello, %s!' % os.getenv("HELLO_USER")) print('Hello, %s!' % os.getenv("HELLO_USER"))
```

156
website/content/docs/provisioners/shell.mdx
View File

@ -23,6 +23,15 @@ Shell](/docs/provisioners/windows-shell) provisioners.
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
inline = ["echo foo"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -32,15 +41,6 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
inline = ["echo foo"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -65,7 +65,7 @@ provisioner "shell" {
`chmod +x {{.Path}}; . {{.EnvVarFile}} && {{.Path}}`. This option is `chmod +x {{.Path}}; . {{.EnvVarFile}} && {{.Path}}`. This option is
unnecessary for most cases, but if you have extra quoting in your custom unnecessary for most cases, but if you have extra quoting in your custom
`execute_command`, then this may be required for proper script `execute_command`, then this may be required for proper script
execution. Default: false. execution. Default: `false`.
- `execute_command` (string) - The command to use to execute the script. By - `execute_command` (string) - The command to use to execute the script. By
default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`, unless the default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`, unless the
@ -82,7 +82,7 @@ provisioner "shell" {
- `expect_disconnect` (boolean) - Defaults to `false`. When `true`, allow the - `expect_disconnect` (boolean) - Defaults to `false`. When `true`, allow the
server to disconnect from Packer without throwing an error. A disconnect server to disconnect from Packer without throwing an error. A disconnect
might happen if you restart the ssh server or reboot the host. might happen if you restart the SSH server or reboot the host.
- `inline_shebang` (string) - The - `inline_shebang` (string) - The
[shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use [shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use
@ -93,18 +93,18 @@ provisioner "shell" {
provisioner. provisioner.
- `remote_folder` (string) - The folder where the uploaded script will reside - `remote_folder` (string) - The folder where the uploaded script will reside
on the machine. This defaults to '/tmp'. on the machine. This defaults to `/tmp`.
- `remote_file` (string) - The filename the uploaded script will have on the - `remote_file` (string) - The filename the uploaded script will have on the
machine. This defaults to 'script_nnn.sh'. machine. This defaults to `script_nnn.sh`.
- `remote_path` (string) - The full path to the uploaded script will have on - `remote_path` (string) - The full path to the uploaded script will have on
the machine. By default this is remote_folder/remote_file, if set this the machine. By default this is `remote_folder/remote_file`, if set this
option will override both remote_folder and remote_file. option will override both `remote_folder` and `remote_file`.
- `skip_clean` (boolean) - If true, specifies that the helper scripts - `skip_clean` (boolean) - If true, specifies that the helper scripts
uploaded to the system will not be removed by Packer. This defaults to uploaded to the system will not be removed by Packer. This defaults to
false (clean scripts from the system). `false` (clean scripts from the system).
- `start_retry_timeout` (string) - The amount of time to attempt to _start_ - `start_retry_timeout` (string) - The amount of time to attempt to _start_
the remote process. By default this is `5m` or 5 minutes. This setting the remote process. By default this is `5m` or 5 minutes. This setting
@ -175,10 +175,10 @@ commonly useful environmental variables:
run only certain parts of the script on systems built with certain run only certain parts of the script on systems built with certain
builders. builders.
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file - `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.
@ -194,10 +194,21 @@ scripts. The amount of time the provisioner will wait is configured using
Sometimes, when executing a command like `reboot`, the shell script will return Sometimes, when executing a command like `reboot`, the shell script will return
and Packer will start executing the next one before SSH actually quits and the and Packer will start executing the next one before SSH actually quits and the
machine restarts. For this, put use "pause_before" to make Packer wait before machine restarts. For this, use `pause_before` to make Packer wait before
executing the next script: executing the next script:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
script = "script.sh"
pause_before = "10s"
timeout = "10s"
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -209,17 +220,6 @@ executing the next script:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
script = "script.sh"
pause_before = "10s"
timeout = "10s"
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -237,8 +237,8 @@ For example, on Gentoo:
Some provisioning requires connecting to remote SSH servers from within the Some provisioning requires connecting to remote SSH servers from within the
packer instance. The below example is for pulling code from a private git packer instance. The below example is for pulling code from a private git
repository utilizing openssh on the client. Make sure you are running repository utilizing openssh on the client. Make sure you are running
`ssh-agent` and add your git repo ssh keys into it using `ssh-agent` and add your git repo SSH keys into it using
`ssh-add /path/to/key`. When the packer instance needs access to the ssh keys `ssh-add /path/to/key`. When the Packer instance needs access to the SSH keys
the agent will forward the request back to your `ssh-agent`. the agent will forward the request back to your `ssh-agent`.
Note: when provisioning via git you should add the git server keys into the Note: when provisioning via git you should add the git server keys into the
@ -249,12 +249,11 @@ to populate the file (less secure). An example of the latter accessing github
would be: would be:
<Tabs> <Tabs>
<Tab heading="JSON"> <Tab heading="HCL2">
```json ```hcl
{ provisioner "shell" {
"type": "shell", inline = [
"inline": [
"sudo apt-get install -y git", "sudo apt-get install -y git",
"ssh-keyscan github.com >> ~/.ssh/known_hosts", "ssh-keyscan github.com >> ~/.ssh/known_hosts",
"git clone git@github.com:exampleorg/myprivaterepo.git" "git clone git@github.com:exampleorg/myprivaterepo.git"
@ -263,11 +262,12 @@ would be:
``` ```
</Tab> </Tab>
<Tab heading="HCL2"> <Tab heading="JSON">
```hcl ```json
provisioner "shell" { {
inline = [ "type": "shell",
"inline": [
"sudo apt-get install -y git", "sudo apt-get install -y git",
"ssh-keyscan github.com >> ~/.ssh/known_hosts", "ssh-keyscan github.com >> ~/.ssh/known_hosts",
"git clone git@github.com:exampleorg/myprivaterepo.git" "git clone git@github.com:exampleorg/myprivaterepo.git"
@ -311,6 +311,15 @@ _My builds don't always work the same_
wait until it completely boots. wait until it completely boots.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
inline = ["sleep 10"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -320,49 +329,15 @@ _My builds don't always work the same_
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "shell" {
inline = ["sleep 10"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
## Quoting Environment Variables ## Quoting Environment Variables
Packer manages quoting for you, so you should't have to worry about it. Below Packer manages quoting for you, so you shouldn't have to worry about it. Below
is an example of packer template inputs and what you should expect to get out: is an example of Packer template inputs and what you should expect to get out:
<Tabs> <Tabs>
<Tab heading="JSON">
```json
"provisioners": [
{
"type": "shell",
"environment_vars": ["FOO=foo",
"BAR=bar's",
"BAZ=baz=baz",
"QUX==qux",
"FOOBAR=foo bar",
"FOOBARBAZ='foo bar baz'",
"QUX2=\"qux\""],
"inline": ["echo \"FOO is $FOO\"",
"echo \"BAR is $BAR\"",
"echo \"BAZ is $BAZ\"",
"echo \"QUX is $QUX\"",
"echo \"FOOBAR is $FOOBAR\"",
"echo \"FOOBARBAZ is $FOOBARBAZ\"",
"echo \"QUX2 is $QUX2\""]
}
]
```
</Tab>
<Tab heading="HCL2"> <Tab heading="HCL2">
```hcl ```hcl
@ -388,6 +363,31 @@ provisioner "shell" {
} }
``` ```
</Tab>
<Tab heading="JSON">
```json
"provisioners": [
{
"type": "shell",
"environment_vars": ["FOO=foo",
"BAR=bar's",
"BAZ=baz=baz",
"QUX==qux",
"FOOBAR=foo bar",
"FOOBARBAZ='foo bar baz'",
"QUX2=\"qux\""],
"inline": ["echo \"FOO is $FOO\"",
"echo \"BAR is $BAR\"",
"echo \"BAZ is $BAZ\"",
"echo \"QUX is $QUX\"",
"echo \"FOOBAR is $FOOBAR\"",
"echo \"FOOBARBAZ is $FOOBARBAZ\"",
"echo \"QUX2 is $QUX2\""]
}
]
```
</Tab> </Tab>
</Tabs> </Tabs>

40
website/content/docs/provisioners/windows-restart.mdx
View File

@ -25,6 +25,13 @@ so Windows must be completely booted in order to continue.
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "windows-restart" {}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -33,13 +40,6 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "windows-restart" {}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -54,13 +54,14 @@ Optional parameters:
installation kicks off a reboot and you want the provisioner to wait for installation kicks off a reboot and you want the provisioner to wait for
that reboot to complete before reconnecting. Please note that this option that reboot to complete before reconnecting. Please note that this option
is a beta feature, and we generally recommend that you finish installs that is a beta feature, and we generally recommend that you finish installs that
auto-reboot (like windows updates) during your autounattend phase before auto-reboot (like Windows Updates) during your _autounattend_ phase before
our winrm provisioner connects. the `winrm` provisioner connects.
- `registry_keys` (array of strings) - if `check-registry` is `true`, - `registry_keys` (array of strings) - if `check-registry` is `true`,
windows-restart will not reconnect until after all of the listed keys are `windows-restart` will not reconnect until after all of the listed keys are
no longer present in the registry. no longer present in the registry.
```
default: default:
var DefaultRegistryKeys = []string{ var DefaultRegistryKeys = []string{
@ -68,6 +69,7 @@ Optional parameters:
"HKLM:SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Component Based Servicing\\PackagesPending", "HKLM:SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Component Based Servicing\\PackagesPending",
"HKLM:Software\\Microsoft\\Windows\\CurrentVersion\\Component Based Servicing\\RebootInProgress", "HKLM:Software\\Microsoft\\Windows\\CurrentVersion\\Component Based Servicing\\RebootInProgress",
} }
```
- `restart_command` (string) - The command to execute to initiate the - `restart_command` (string) - The command to execute to initiate the
restart. By default this is `shutdown /r /f /t 0 /c "packer restart"`. restart. By default this is `shutdown /r /f /t 0 /c "packer restart"`.
@ -76,6 +78,15 @@ Optional parameters:
restart succeeded. This will be done in a loop. Example usage: restart succeeded. This will be done in a loop. Example usage:
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "windows-restart" {
restart_check_command = "powershell -command \"& {Write-Output 'restarted.'}\""
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -85,15 +96,6 @@ Optional parameters:
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "windows-restart" {
restart_check_command = "powershell -command \"& {Write-Output 'restarted.'}\""
}
```
</Tab> </Tab>
</Tabs> </Tabs>

24
website/content/docs/provisioners/windows-shell.mdx
View File

@ -17,6 +17,15 @@ The windows-shell Packer provisioner runs commands on a Windows machine using
The example below is fully functional. The example below is fully functional.
<Tabs> <Tabs>
<Tab heading="HCL2">
```hcl
provisioner "windows-shell" {
inline = ["dir c:\\"]
}
```
</Tab>
<Tab heading="JSON"> <Tab heading="JSON">
```json ```json
@ -26,15 +35,6 @@ The example below is fully functional.
} }
``` ```
</Tab>
<Tab heading="HCL2">
```hcl
provisioner "windows-shell" {
inline = ["dir c:\\"]
}
```
</Tab> </Tab>
</Tabs> </Tabs>
@ -84,9 +84,9 @@ commonly useful environmental variables:
run only certain parts of the script on systems built with certain run only certain parts of the script on systems built with certain
builders. builders.
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file - `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this transfer (such as `hyperv`, `parallels`, `qemu`, `virtualbox`, and `vmware`), this
will be set to the address. You can use this address in your provisioner to will be set to the address. You can use this address in your provisioner to
download large files over http. This may be useful if you're experiencing download large files over HTTP. This may be useful if you're experiencing
slower speeds using the default file provisioner. A file provisioner using slower speeds using the default file provisioner. A file provisioner using
the `winrm` communicator may experience these types of difficulties. the `winrm` communicator may experience these types of difficulties.

2
website/content/guides/automatic-operating-system-installs/autounattend_windows.mdx
View File

@ -66,7 +66,7 @@ disconnections can fail a build.
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 sets up openssh as part of the unattended installation so that Packer can
connect using the ssh communicator. They functioning answer files for every connect using the SSH communicator. They functioning answer files for every
modern Windows version can be found [here](https://github.com/chef/bento/tree/master/packer_templates/windows/answer_files). 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) Stefan Scherer's [packer-windows repo](https://github.com/StefanScherer/packer-windows)

8
website/content/guides/hcl/from-json-v1.mdx
View File

@ -18,8 +18,8 @@ for example,
packer hcl2_upgrade mytemplate.json packer hcl2_upgrade mytemplate.json
``` ```
will convert your packer template to a new HCL2 file in your current working will convert your Packer template to a new HCL2 file in your current working
directory named mytemplate.json.pkr.hcl. It is not a perfect converter yet; directory named `mytemplate.json.pkr.hcl`. It is not a perfect converter yet;
please open an issue if you find a problem with the conversion. Packer will not please open an issue if you find a problem with the conversion. Packer will not
destroy your legacy json template, so this is not a risky command to call. destroy your legacy json template, so this is not a risky command to call.
@ -63,7 +63,7 @@ Becomes:
```hcl ```hcl
# The data block defines a data source that is used to fetch data from outside Packer. # The data block defines a data source that is used to fetch data from outside Packer.
# The amazon-ami data source was generated from the source_ami_filter present in # The amazon-ami data source was generated from the `source_ami_filter` present in
# the amazon builder from the JSON template. # the amazon builder from the JSON template.
data "amazon-ami" "autogenerated_1" { data "amazon-ami" "autogenerated_1" {
filters = { filters = {
@ -110,7 +110,7 @@ build {
### 1:1 correspondence of components ... except : ### 1:1 correspondence of components ... except :
All fields of builders, provisioners and post-processors have a 1:1 All fields of builders, provisioners and post-processors have a 1:1
correspondance except for the following: mapping, except for the following:
- builders: - builders:

8
website/content/guides/hcl/variables.mdx
View File

@ -16,15 +16,15 @@ Local variables can be a compound of input variables and local variables.
## Defining Variables and locals ## Defining Variables and locals
In the legacy JSON packer templates, any variables we hadn't already defined in In the legacy JSON Packer templates, any variables we hadn't already defined in
the "variables" stanza of our json template could simply be passed in via the the "variables" stanza of our json template could simply be passed in via the
command line or a var-file; if a variable was never defined it would generally command line or a `var-file`; if a variable was never defined it would generally
be interpolated to an empty string. be interpolated to an empty string.
_In the HCL2 packer templates, we must always pre-define our variables in the _In the HCL2 Packer templates, we must always pre-define our variables in the
HCL equivalent of the "variables" stanza._ HCL equivalent of the "variables" stanza._
Another difference between JSON and HCL packer templates is that in JSON packer Another difference between JSON and HCL Packer templates is that in JSON packer
templates, the "variables" stanza, if used, was always in the same .json file templates, the "variables" stanza, if used, was always in the same .json file
as the builds and builders. In HCL, it can exist in its own file if you want it as the builds and builders. In HCL, it can exist in its own file if you want it
to. to.

2
website/content/partials/packer-plugin-sdk/communicator/SSHTemporaryKeyPair.mdx
View File

@ -1,5 +1,5 @@
<!-- Code generated from the comments of the SSHTemporaryKeyPair struct in communicator/config.go; DO NOT EDIT MANUALLY --> <!-- Code generated from the comments of the SSHTemporaryKeyPair struct in communicator/config.go; DO NOT EDIT MANUALLY -->
When no ssh credentials are specified, Packer will generate a temporary SSH When no SSH credentials are specified, Packer will generate a temporary SSH
keypair for the instance. You can change the algorithm type and bits keypair for the instance. You can change the algorithm type and bits
settings. settings.