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
GitHub
parent
15a2e59bba
commit
cf94fd1778
|
|
@ -47,7 +47,7 @@ contribution here!
|
|||
Packer 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) -
|
||||
Ubuntu LTS Virtual Machines for Vagrant
|
||||
|
|
|
|||
|
|
@ -139,4 +139,4 @@ for details.
|
|||
|
||||
See the
|
||||
[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.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ options. In addition to the options listed here, a [communicator](/docs/template
|
|||
|
||||
#### 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
|
||||
|
||||
|
|
@ -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
|
||||
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.
|
||||
|
||||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
|
|
@ -493,4 +493,4 @@ minimal, so overall impact is small.
|
|||
|
||||
See the
|
||||
[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.
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ following methods are available and are explained below:
|
|||
- Azure CLI
|
||||
|
||||
-> **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.
|
||||
|
||||
No matter which method you choose, the identity you use will need the
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ straightforwarded, it is documented here.
|
|||
Packer looks for credentials in the following places, preferring the first
|
||||
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
|
||||
`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).
|
||||
|
||||
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`:
|
||||
|
||||
<Tabs>
|
||||
|
|
@ -402,8 +402,8 @@ The GCS location must be writeable by the service account of the instance that P
|
|||
|
||||
### Gotchas
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
The machine type must have a scratch disk, which means you can't use an
|
||||
`f1-micro` or `g1-small` to build images.
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ builder.
|
|||
for more info.
|
||||
|
||||
- `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.
|
||||
|
||||
|
|
|
|||
|
|
@ -842,7 +842,7 @@ d-i pkgsel/update-policy select none
|
|||
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.
|
||||
On RHEL based machines this may require installing the package `hyperv-daemons`
|
||||
and ensuring the `hypervkvpd` service is started at boot. On Debian based
|
||||
|
|
|
|||
|
|
@ -88,7 +88,7 @@ Below is a fully functioning example.
|
|||
`packer-<BuildName>`.
|
||||
|
||||
- `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.
|
||||
|
||||
- `init_timeout` (string) - The timeout in seconds to wait for the the
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ Here is a basic example for linux server.
|
|||
|
||||
## 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.
|
||||
|
||||
"builders": [
|
||||
|
|
@ -148,7 +148,7 @@ provision when creating a Windows server.
|
|||
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
|
||||
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
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -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 <UUID> 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -338,7 +338,7 @@ services:
|
|||
|
||||
### 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.
|
||||
|
||||
## Building From Scratch
|
||||
|
|
|
|||
|
|
@ -79,9 +79,9 @@ Usage:
|
|||
### x509 Certificate Authentication
|
||||
|
||||
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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ this build to run. We recommend you check out the
|
|||
for a practical usage example.
|
||||
|
||||
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`).
|
||||
|
||||
## 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
|
||||
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
|
||||
file/directory or run in another directory.
|
||||
|
||||
|
|
|
|||
|
|
@ -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_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.
|
||||
|
||||
- `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_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.
|
||||
|
||||
- `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
|
||||
[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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
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
|
||||
than is produced when you call `vagrant ssh-config`, then you must provide the
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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
|
||||
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
|
||||
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
|
||||
advanced configuration option. Please make sure your firewall settings are
|
||||
correct before adjusting.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
- `-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.
|
||||
|
||||
- `-var-file` - Set template variables from a file.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ help output, which can be seen via `packer console -h`.
|
|||
|
||||
## 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.
|
||||
example: `-var "myvar=asdf"`
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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
|
||||
per hour one IP can
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Errors validating build 'vmware'. 1 error(s) occurred:
|
|||
- `-machine-readable` Sets all output to become machine-readable on stdout.
|
||||
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.
|
||||
|
||||
- `-var-file` - Set template variables from a file.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ core configuration for now.
|
|||
## Packer's home directory
|
||||
|
||||
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 :
|
||||
|
||||
| unix | windows |
|
||||
|
|
@ -32,7 +32,7 @@ to be set :
|
|||
## Packer's config file
|
||||
|
||||
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 |
|
||||
| ------------------------------- | -------------------------------- |
|
||||
|
|
@ -43,8 +43,8 @@ It is not an error if no config file was found.
|
|||
|
||||
## Packer's config directory
|
||||
|
||||
Packer's configuration directory can potentialy contain plugins and internal
|
||||
Packer files. The config dir of packer will be looked up on the following paths:
|
||||
Packer's configuration directory can potentially contain plugins and internal
|
||||
Packer files. The config dir of Packer will be looked up on the following paths:
|
||||
|
||||
| unix | windows |
|
||||
| --------------------------- | --------------------------- |
|
||||
|
|
@ -69,9 +69,9 @@ The format of the configuration file is basic JSON.
|
|||
## Packer's cache directory
|
||||
|
||||
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`
|
||||
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
|
||||
same ISO twice for example.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
Check the specfics on your builder to confirm their behavior.
|
||||
Check the specifics on your builder to confirm their behavior.
|
||||
|
||||
### 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
|
||||
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
|
||||
AMI.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ Type: `manifest`
|
|||
Artifact BuilderId: `packer.post-processor.manifest`
|
||||
|
||||
The manifest post-processor writes a JSON file with a list of all of the
|
||||
artifacts packer produces during a run. If your packer template includes
|
||||
artifacts packer produces during a run. If your Packer template includes
|
||||
multiple builds, this helps you keep track of which output artifacts (files,
|
||||
AMI IDs, docker containers, etc.) correspond to each build.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,25 @@ some task with packer outputs and variables.
|
|||
The example below is a fully functional self-contained build.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ Optional parameters:
|
|||
a beta feature.
|
||||
|
||||
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
|
||||
default this is just 0.
|
||||
default this is `0`.
|
||||
|
||||
## 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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -294,7 +294,7 @@ you much time in the process.
|
|||
|
||||
### 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
|
||||
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
|
||||
source "file" "example" {
|
||||
content = "Lorem ipsum dolor sit amet"
|
||||
target = "dummy_artifact.txt"
|
||||
target = "dummy_artifact.txt"
|
||||
}
|
||||
build {
|
||||
sources = [
|
||||
"source.file.example"
|
||||
]
|
||||
post-processor "manifest" {
|
||||
output = "manifest.json"
|
||||
output = "manifest.json"
|
||||
strip_path = true
|
||||
}
|
||||
|
||||
post-processor "shell-local" {
|
||||
inline = [
|
||||
"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:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
post-processor "shell-local" {
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
|
||||
scripts = ["./scripts/test_cmd.cmd"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
Contents of "test_cmd.cmd":
|
||||
Contents of `test_cmd.cmd`:
|
||||
|
||||
echo %SHELLLOCALTEST%
|
||||
|
||||
|
|
@ -414,6 +414,17 @@ Example of running an inline command on windows: Required customization:
|
|||
tempfile_extension
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
post-processor "shell-local" {
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
|
||||
tempfile_extension = ".cmd",
|
||||
inline = ["echo %SHELLLOCALTEST%"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -426,23 +437,24 @@ tempfile_extension
|
|||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a bash command on windows using WSL: Required
|
||||
customizations: `use_linux_pathing` and `execute_command`:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
post-processor "shell-local" {
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
|
||||
tempfile_extension = ".cmd",
|
||||
inline = [echo %SHELLLOCALTEST%"]
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest3"],
|
||||
execute_command = ["bash", "-c", "{{.Vars}} {{.Script}}"]
|
||||
use_linux_pathing = true
|
||||
script = "./scripts/example_bash.sh"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a bash command on windows using WSL: Required
|
||||
customizations: use_linux_pathing and execute_command
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
Contents of "example_bash.sh":
|
||||
Contents of `example_bash.sh`:
|
||||
|
||||
#!/bin/bash
|
||||
echo $SHELLLOCALTEST
|
||||
|
||||
Example of running a powershell script on windows: Required customizations:
|
||||
env_var_format and execute_command
|
||||
Example of running a PowerShell script on Windows:
|
||||
Required customizations: `env_var_format` and `execute_command`.
|
||||
|
||||
<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">
|
||||
|
||||
```json
|
||||
|
|
@ -492,24 +504,25 @@ env_var_format and execute_command
|
|||
```
|
||||
|
||||
</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">
|
||||
|
||||
```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"
|
||||
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>
|
||||
</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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
### Unix Host
|
||||
|
||||
Example of running a bash script on unix:
|
||||
Example of running a Shell script on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
post-processor "shell-local" {
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
|
||||
scripts = ["./scripts/example_bash.sh"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
Example of running a bash "inline" on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
post-processor "shell-local" {
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
|
||||
inline = ["echo hello", "echo $PROVISIONERTEST"]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
Example of running a python script on unix:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
```text
|
||||
Where "hello.py" contains:
|
||||
|
||||
import os
|
||||
|
||||
print('Hello, %s!' % os.getenv("HELLO_USER"))
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
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`
|
||||
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 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.
|
||||
|
||||
- `keep_input_artifact` (boolean) - When true, preserve the local box
|
||||
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
|
||||
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.
|
||||
This is a [template engine](/docs/templates/legacy_json_templates/engine). Therefore, you
|
||||
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
|
||||
- `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.
|
||||
|
||||
## Use with the Vagrant Post-Processor
|
||||
|
|
|
|||
|
|
@ -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 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
|
||||
cause your build to fail.
|
||||
|
||||
|
|
@ -84,7 +84,7 @@ more details about certain options in following sections.
|
|||
this post-processor. This is a
|
||||
[template engine](/docs/templates/legacy_json_templates/engine). Therefore, you may use user
|
||||
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
|
||||
- `ArtifactId`: The ID of the input artifact.
|
||||
|
|
|
|||
|
|
@ -78,8 +78,8 @@ Optional:
|
|||
- `reregister_vm` (boolean) - Use the method of unregister VM and reregister
|
||||
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
|
||||
template, but it works fine in the vSphere UI, try setting this to false.
|
||||
Default is true.
|
||||
template, but it works fine in the vSphere UI, try setting this to `false`.
|
||||
Default is `true`.
|
||||
|
||||
## 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
|
||||
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
|
||||
`"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
|
||||
behavior in certain versions of ovftool.
|
||||
behavior in certain versions of `ovftool`.
|
||||
|
|
|
|||
|
|
@ -47,13 +47,13 @@ Optional:
|
|||
- `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`. 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
|
||||
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
|
||||
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,
|
||||
even after importing them to vsphere. Defaults to `false`.
|
||||
|
|
@ -66,9 +66,9 @@ Optional:
|
|||
to.
|
||||
|
||||
- `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
|
||||
|
||||
# Example
|
||||
|
|
@ -80,6 +80,39 @@ to a vSphere cluster.
|
|||
You can also use this post-processor with the vmx artifact from a vmware build.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
# Permissions
|
||||
|
||||
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
|
||||
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
|
||||
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
|
||||
extraneous permissions that are not strictly required.
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
description: >
|
||||
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
|
||||
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
|
||||
Packer) to the vm.
|
||||
page_title: Ansible Local - Provisioners
|
||||
|
|
@ -12,9 +12,9 @@ page_title: Ansible Local - Provisioners
|
|||
|
||||
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
|
||||
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
|
||||
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)
|
||||
|
|
@ -128,9 +128,9 @@ commonly useful Ansible variables:
|
|||
run only certain parts of the playbook on systems built with certain
|
||||
builders.
|
||||
|
||||
- `packer_http_addr` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `packer_http_addr` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
the `winrm` communicator may experience these types of difficulties.
|
||||
|
|
|
|||
|
|
@ -34,6 +34,27 @@ DigitalOcean. Replace the mock `api_token` value with your own.
|
|||
Example Packer template:
|
||||
|
||||
<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">
|
||||
|
||||
```json
|
||||
|
|
@ -42,7 +63,7 @@ Example Packer template:
|
|||
{
|
||||
"type": "digitalocean",
|
||||
"api_token": "6a561151587389c7cf8faa2d83e94150a4202da0e2bad34dd2bf236018ffaeeb",
|
||||
"image": "ubuntu-14-04-x64",
|
||||
"image": "ubuntu-20-04-x64",
|
||||
"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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -121,10 +122,10 @@ commonly useful Ansible variables:
|
|||
run only certain parts of the playbook on systems built with certain
|
||||
builders.
|
||||
|
||||
- `packer_http_addr` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `packer_http_addr` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": [ "-vvvv" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
extra_arguments = [ "-vvvv" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": [ "-vvvv" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
### 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
|
||||
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:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
|
|
@ -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
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"ansible_env_vars": ["no_proxy=\"*\""],
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
ansible_env_vars = ["no_proxy=\"*\""]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"ansible_env_vars": ["no_proxy=\"*\""],
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -359,7 +373,7 @@ in the above Ansible template.
|
|||
|
||||
#### 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_plugins` next to the playbook which contains a file named
|
||||
packer.py` which implements the connection plugin. On versions of Ansible
|
||||
|
|
@ -496,24 +510,34 @@ $ ssh-add -D
|
|||
### Become: yes
|
||||
|
||||
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
|
||||
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
|
||||
"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
|
||||
#!/bin/bash
|
||||
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>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "ansible" {
|
||||
command = "/Path/To/call_ansible.sh"
|
||||
playbook_file = "./playbook.yml"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
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
|
||||
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
|
||||
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:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -665,6 +679,18 @@ provisioned otherwise you may run into a TargetNotConnected error. Users can use
|
|||
their configured region.
|
||||
|
||||
<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">
|
||||
|
||||
```json
|
||||
|
|
@ -680,23 +706,52 @@ their configured region.
|
|||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Full Packer template example:
|
||||
|
||||
<Tabs>
|
||||
<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>
|
||||
</Tabs>
|
||||
|
||||
Full Packer template example:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -81,19 +81,19 @@ Optional Parameters:
|
|||
running InSpec. Usage example:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"inspec_env_vars": [ "FOO=bar" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
inspec_env_vars = [ "FOO=bar" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"inspec_env_vars": [ "FOO=bar" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -104,26 +104,26 @@ Optional Parameters:
|
|||
not be quoted. Usage example:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": [ "--sudo", "--reporter", "json" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
extra_arguments = [ "--sudo", "--reporter", "json" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": [ "--sudo", "--reporter", "json" ]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
- `attributes` (array of strings) - Attribute Files used by InSpec which will
|
||||
be passed to the `--input-file` argument of the `inspec` command when this
|
||||
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.
|
||||
|
||||
- `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:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -219,18 +219,18 @@ To debug underlying issues with InSpec, add `"-l"` to `"extra_arguments"` to
|
|||
enable verbose logging.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": ["-l", "debug"]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
extra_arguments = ["-l", "debug"]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
"extra_arguments": ["-l", "debug"]
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -21,6 +21,15 @@ for details.
|
|||
The example below is fully functional.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "powershell" {
|
||||
inline = ["dir c:\\"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -30,15 +39,6 @@ The example below is fully functional.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "powershell" {
|
||||
inline = ["dir c:\\"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -82,6 +82,16 @@ provisioner "powershell" {
|
|||
accessing the `build` variables For example:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -140,6 +140,16 @@ provisioner "powershell" {
|
|||
accessing the `build` variables For example:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "powershell" {
|
||||
elevated_user = "Administrator"
|
||||
elevated_password = build.Password
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -151,16 +161,6 @@ provisioner "powershell" {
|
|||
},
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "powershell" {
|
||||
elevated_user = "Administrator"
|
||||
elevated_password = build.Password
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</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:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "powershell" {
|
||||
elevated_user = "SYSTEM"
|
||||
elevated_password = ""
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
- `execution_policy` - To run ps scripts on windows packer defaults this to
|
||||
"bypass" and wraps the command to run. Setting this to "none" will prevent
|
||||
wrapping, allowing to see exit codes on docker for windows. Possible values
|
||||
are "bypass", "allsigned", "default", "remotesigned", "restricted",
|
||||
"undefined", "unrestricted", "none".
|
||||
are `bypass`, `allsigned`, `default`, `remotesigned`, `restricted`,
|
||||
`undefined`, `unrestricted`, and `none`.
|
||||
|
||||
- `remote_path` (string) - The path where the PowerShell script will be
|
||||
uploaded to within the target build machine. This defaults to
|
||||
|
|
@ -227,7 +227,7 @@ provisioner "powershell" {
|
|||
value set for `skip_clean`.
|
||||
|
||||
- `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
|
||||
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
|
||||
builders.
|
||||
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,15 @@ master.
|
|||
The example below is fully functional.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "salt-masterless" {
|
||||
local_state_tree = "/Users/me/salt"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -24,6 +24,25 @@ scripts on a remote machine.
|
|||
The example below is fully functional.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
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:
|
||||
|
||||
|
|
@ -86,7 +86,7 @@ Exactly _one_ of the following is required:
|
|||
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
|
||||
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
|
||||
absolute or relative. If it is relative, it is relative to the working
|
||||
|
|
@ -169,7 +169,7 @@ Optional parameters:
|
|||
ignore this option.
|
||||
|
||||
- `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'
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -275,17 +275,17 @@ commonly useful environmental variables:
|
|||
run only certain parts of the script on systems built with certain
|
||||
builders.
|
||||
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
the `winrm` communicator may experience these types of difficulties.
|
||||
|
||||
## Safely Writing A Script
|
||||
|
||||
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
|
||||
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:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell-local" {
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest1"]
|
||||
scripts = ["./scripts/test_cmd.cmd"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -341,6 +341,17 @@ Example of running an inline command on windows: Required customization:
|
|||
tempfile_extension
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell-local" {
|
||||
environment_vars = ["SHELLLOCALTEST=ShellTest2"],
|
||||
tempfile_extension = ".cmd",
|
||||
inline = [echo "%SHELLLOCALTEST%"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -370,6 +370,18 @@ Example of running a bash command on windows using WSL: Required
|
|||
customizations: use_linux_pathing and execute_command
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
Contents of "example_bash.sh":
|
||||
Contents of `example_bash.sh`:
|
||||
|
||||
#!/bin/bash
|
||||
echo $SHELLLOCALTEST
|
||||
|
||||
Example of running a powershell script on windows: Required customizations:
|
||||
env_var_format and execute_command
|
||||
`env_var_format` and `execute_command`
|
||||
|
||||
<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">
|
||||
|
||||
```json
|
||||
|
|
@ -419,24 +431,25 @@ env_var_format and execute_command
|
|||
```
|
||||
|
||||
</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">
|
||||
|
||||
```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"
|
||||
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>
|
||||
</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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
### Unix Host
|
||||
|
||||
Example of running a bash script on unix:
|
||||
Example of running a Shell script on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell-local" {
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
|
||||
scripts = ["./scripts/example_bash.sh"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -482,21 +492,22 @@ Example of running a bash script on unix:
|
|||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a Shell script "inline" on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell-local" {
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest1"]
|
||||
scripts = ["./scripts/example_bash.sh"]
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
|
||||
inline = ["echo hello", "echo $PROVISIONERTEST"]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a bash "inline" on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -508,22 +519,27 @@ Example of running a bash "inline" on unix:
|
|||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a Python script on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell-local" {
|
||||
environment_vars = ["PROVISIONERTEST=ProvisionerTest2"]
|
||||
inline = ["echo hello", "echo $PROVISIONERTEST"]
|
||||
script = "hello.py"
|
||||
environment_vars = ["HELLO_USER=packeruser"]
|
||||
execute_command = [
|
||||
"/bin/sh",
|
||||
"-c",
|
||||
"{{.Vars}} /usr/local/bin/python {{.Script}}"
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
Example of running a python script on unix:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
```text
|
||||
Where "hello.py" contains:
|
||||
|
||||
import os
|
||||
|
||||
print('Hello, %s!' % os.getenv("HELLO_USER"))
|
||||
```
|
||||
|
|
|
|||
|
|
@ -23,6 +23,15 @@ Shell](/docs/provisioners/windows-shell) provisioners.
|
|||
The example below is fully functional.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
inline = ["echo foo"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -32,15 +41,6 @@ The example below is fully functional.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
inline = ["echo foo"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ provisioner "shell" {
|
|||
`chmod +x {{.Path}}; . {{.EnvVarFile}} && {{.Path}}`. This option is
|
||||
unnecessary for most cases, but if you have extra quoting in your custom
|
||||
`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
|
||||
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
|
||||
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
|
||||
[shebang](https://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use
|
||||
|
|
@ -93,18 +93,18 @@ provisioner "shell" {
|
|||
provisioner.
|
||||
|
||||
- `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
|
||||
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
|
||||
the machine. By default this is remote_folder/remote_file, if set this
|
||||
option will override both remote_folder and remote_file.
|
||||
the machine. By default this is `remote_folder/remote_file`, if set this
|
||||
option will override both `remote_folder` and `remote_file`.
|
||||
|
||||
- `skip_clean` (boolean) - If true, specifies that the helper scripts
|
||||
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_
|
||||
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
|
||||
builders.
|
||||
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
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
|
||||
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:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
script = "script.sh"
|
||||
pause_before = "10s"
|
||||
timeout = "10s"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -237,8 +237,8 @@ For example, on Gentoo:
|
|||
Some provisioning requires connecting to remote SSH servers from within the
|
||||
packer instance. The below example is for pulling code from a private git
|
||||
repository utilizing openssh on the client. Make sure you are running
|
||||
`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-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
|
||||
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
|
||||
|
|
@ -249,12 +249,11 @@ to populate the file (less secure). An example of the latter accessing github
|
|||
would be:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="JSON">
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```json
|
||||
{
|
||||
"type": "shell",
|
||||
"inline": [
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
inline = [
|
||||
"sudo apt-get install -y git",
|
||||
"ssh-keyscan github.com >> ~/.ssh/known_hosts",
|
||||
"git clone git@github.com:exampleorg/myprivaterepo.git"
|
||||
|
|
@ -263,11 +262,12 @@ would be:
|
|||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
<Tab heading="JSON">
|
||||
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
inline = [
|
||||
```json
|
||||
{
|
||||
"type": "shell",
|
||||
"inline": [
|
||||
"sudo apt-get install -y git",
|
||||
"ssh-keyscan github.com >> ~/.ssh/known_hosts",
|
||||
"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.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "shell" {
|
||||
inline = ["sleep 10"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
## Quoting Environment Variables
|
||||
|
||||
Packer manages quoting for you, so you should't have to worry about it. Below
|
||||
is an example of packer template inputs and what you should expect to get out:
|
||||
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:
|
||||
|
||||
<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">
|
||||
|
||||
```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>
|
||||
</Tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -25,6 +25,13 @@ so Windows must be completely booted in order to continue.
|
|||
The example below is fully functional.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "windows-restart" {}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -33,13 +40,6 @@ The example below is fully functional.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "windows-restart" {}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -54,13 +54,14 @@ Optional parameters:
|
|||
installation kicks off a reboot and you want the provisioner to wait for
|
||||
that reboot to complete before reconnecting. Please note that this option
|
||||
is a beta feature, and we generally recommend that you finish installs that
|
||||
auto-reboot (like windows updates) during your autounattend phase before
|
||||
our winrm provisioner connects.
|
||||
auto-reboot (like Windows Updates) during your _autounattend_ phase before
|
||||
the `winrm` provisioner connects.
|
||||
|
||||
- `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.
|
||||
|
||||
```
|
||||
default:
|
||||
|
||||
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\\RebootInProgress",
|
||||
}
|
||||
```
|
||||
|
||||
- `restart_command` (string) - The command to execute to initiate the
|
||||
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:
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "windows-restart" {
|
||||
restart_check_command = "powershell -command \"& {Write-Output 'restarted.'}\""
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="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>
|
||||
</Tabs>
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,15 @@ The windows-shell Packer provisioner runs commands on a Windows machine using
|
|||
The example below is fully functional.
|
||||
|
||||
<Tabs>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "windows-shell" {
|
||||
inline = ["dir c:\\"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
|
|
@ -26,15 +35,6 @@ The example below is fully functional.
|
|||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
<Tab heading="HCL2">
|
||||
|
||||
```hcl
|
||||
provisioner "windows-shell" {
|
||||
inline = ["dir c:\\"]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -84,9 +84,9 @@ commonly useful environmental variables:
|
|||
run only certain parts of the script on systems built with certain
|
||||
builders.
|
||||
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an http server for file
|
||||
transfer (such as hyperv, parallels, qemu, virtualbox, and vmware), this
|
||||
- `PACKER_HTTP_ADDR` If using a builder that provides an HTTP server for file
|
||||
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
|
||||
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
|
||||
the `winrm` communicator may experience these types of difficulties.
|
||||
|
|
|
|||
|
|
@ -66,7 +66,7 @@ disconnections can fail a build.
|
|||
|
||||
The chef-maintained bento boxes are a great example of a windows build that
|
||||
sets up openssh as part of the unattended installation so that Packer can
|
||||
connect using the ssh communicator. 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).
|
||||
|
||||
Stefan Scherer's [packer-windows repo](https://github.com/StefanScherer/packer-windows)
|
||||
|
|
|
|||
|
|
@ -18,8 +18,8 @@ for example,
|
|||
packer hcl2_upgrade mytemplate.json
|
||||
```
|
||||
|
||||
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;
|
||||
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;
|
||||
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.
|
||||
|
||||
|
|
@ -63,7 +63,7 @@ Becomes:
|
|||
|
||||
```hcl
|
||||
# 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.
|
||||
data "amazon-ami" "autogenerated_1" {
|
||||
filters = {
|
||||
|
|
@ -110,7 +110,7 @@ build {
|
|||
### 1:1 correspondence of components ... except :
|
||||
|
||||
All fields of builders, provisioners and post-processors have a 1:1
|
||||
correspondance except for the following:
|
||||
mapping, except for the following:
|
||||
|
||||
- builders:
|
||||
|
||||
|
|
|
|||
|
|
@ -16,15 +16,15 @@ Local variables can be a compound of input variables and local variables.
|
|||
|
||||
## 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
|
||||
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.
|
||||
|
||||
_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._
|
||||
|
||||
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
|
||||
as the builds and builders. In HCL, it can exist in its own file if you want it
|
||||
to.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
<!-- 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
|
||||
settings.
|
||||
|
|
|
|||
Loading…
Reference in New Issue