Fix broken links
This commit is contained in:
parent
f5a10460dd
commit
38e0ba8bd3
|
@ -62,8 +62,8 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
- `ami_name` (string) - The name of the resulting AMI that will appear when
|
||||
managing AMIs in the AWS console or via APIs. This must be unique. To help
|
||||
make this unique, use a function like `timestamp` (see [configuration
|
||||
templates](/docs/templates/configuration-templates.html) for more info)
|
||||
make this unique, use a function like `timestamp` (see [template
|
||||
engine](/docs/templates/engine.html) for more info)
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with AWS. [Learn
|
||||
how to set this.](/docs/builders/amazon.html#specifying-amazon-credentials)
|
||||
|
@ -77,7 +77,7 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
- `ami_description` (string) - The description to set for the
|
||||
resulting AMI(s). By default this description is empty. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with name of the region where this
|
||||
is built.
|
||||
|
@ -226,7 +226,7 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override AMI tags if already applied to snapshot. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with name of the region where this
|
||||
is built.
|
||||
|
@ -270,7 +270,7 @@ each category, the available configuration keys are alphabetized.
|
|||
This is most useful for selecting a daily distro build.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the AMI. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with name of the region where this
|
||||
is built.
|
||||
|
|
|
@ -50,8 +50,8 @@ builder.
|
|||
|
||||
- `ami_name` (string) - The name of the resulting AMI that will appear when
|
||||
managing AMIs in the AWS console or via APIs. This must be unique. To help
|
||||
make this unique, use a function like `timestamp` (see [configuration
|
||||
templates](/docs/templates/configuration-templates.html) for more info)
|
||||
make this unique, use a function like `timestamp` (see [template
|
||||
engine](/docs/templates/engine.html) for more info)
|
||||
|
||||
- `instance_type` (string) - The EC2 instance type to use while building the
|
||||
AMI, such as `m1.small`.
|
||||
|
@ -111,7 +111,7 @@ builder.
|
|||
|
||||
- `ami_description` (string) - The description to set for the
|
||||
resulting AMI(s). By default this description is empty. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -191,14 +191,14 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the instance
|
||||
that is *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
- `run_volume_tags` (object of key/value strings) - Tags to apply to the volumes
|
||||
that are *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -229,7 +229,7 @@ builder.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override AMI tags if already applied to snapshot. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -303,7 +303,7 @@ builder.
|
|||
|
||||
- `tags` (object of key/value strings) - Tags applied to the AMI and
|
||||
relevant snapshots. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
|
|
@ -104,7 +104,7 @@ builder.
|
|||
|
||||
- `ami_description` (string) - The description to set for the
|
||||
resulting AMI(s). By default this description is empty. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -184,14 +184,14 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the instance
|
||||
that is *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
- `run_volume_tags` (object of key/value strings) - Tags to apply to the volumes
|
||||
that are *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -222,7 +222,7 @@ builder.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override AMI tags if already applied to snapshot. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -296,7 +296,7 @@ builder.
|
|||
|
||||
- `tags` (object of key/value strings) - Tags applied to the AMI and
|
||||
relevant snapshots. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
|
|
@ -84,8 +84,8 @@ builder.
|
|||
volumes, `io1` for Provisioned IOPS (SSD) volumes, and `standard` for Magnetic
|
||||
volumes
|
||||
- `tags` (map) - Tags to apply to the volume. These are retained after the
|
||||
builder completes. This is a [configuration template]
|
||||
(/docs/templates/configuration-templates.html) where the `SourceAMI`
|
||||
builder completes. This is a [template engine]
|
||||
(/docs/templates/engine.html) where the `SourceAMI`
|
||||
variable is replaced with the source AMI ID and `BuildRegion` variable
|
||||
is replaced with the value of `region`.
|
||||
|
||||
|
@ -111,7 +111,7 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the instance
|
||||
that is *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
|
|
@ -62,7 +62,7 @@ builder.
|
|||
- `ami_name` (string) - The name of the resulting AMI that will appear when
|
||||
managing AMIs in the AWS console or via APIs. This must be unique. To help
|
||||
make this unique, use a function like `timestamp` (see [configuration
|
||||
templates](/docs/templates/configuration-templates.html) for more info)
|
||||
templates](/docs/templates/engine.html) for more info)
|
||||
|
||||
- `instance_type` (string) - The EC2 instance type to use while building the
|
||||
AMI, such as `m1.small`.
|
||||
|
@ -133,7 +133,7 @@ builder.
|
|||
|
||||
- `ami_description` (string) - The description to set for the
|
||||
resulting AMI(s). By default this description is empty. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -207,7 +207,7 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the instance
|
||||
that is *launched* to create the AMI. These tags are *not* applied to the
|
||||
resulting AMI unless they're duplicated in `tags`. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -304,7 +304,7 @@ builder.
|
|||
required if you are using an non-default VPC.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the AMI. This is a
|
||||
[configuration template](/docs/templates/configuration-templates.html)
|
||||
[template engine](/docs/templates/engine.html)
|
||||
where the `SourceAMI` variable is replaced with the source AMI ID and
|
||||
`BuildRegion` variable is replaced with the value of `region`.
|
||||
|
||||
|
@ -380,7 +380,7 @@ AMI.
|
|||
|
||||
These are configured with `bundle_vol_command` and `bundle_upload_command`. Both
|
||||
of these configurations are [configuration
|
||||
templates](/docs/templates/configuration-templates.html) and have support for
|
||||
templates](/docs/templates/engine.html) and have support for
|
||||
their own set of template variables.
|
||||
|
||||
### Bundle Volume Command
|
||||
|
|
|
@ -70,7 +70,7 @@ builder.
|
|||
- `snapshot_name` (string) - The name of the resulting snapshot that will
|
||||
appear in your account. This must be unique. To help make this unique, use a
|
||||
function like `timestamp` (see [configuration
|
||||
templates](/docs/templates/configuration-templates.html) for more info)
|
||||
templates](/docs/templates/engine.html) for more info)
|
||||
|
||||
- `state_timeout` (string) - The time to wait, as a duration string, for a
|
||||
droplet to enter a desired state (such as "active") before timing out. The
|
||||
|
|
|
@ -260,7 +260,7 @@ will be replaced by the proper key:
|
|||
When using modifier keys `ctrl`, `alt`, `shift` ensure that you release them, otherwise they will be held down until the machine reboots. Use lowercase characters as well inside modifiers. For example: to simulate ctrl+c use `<leftCtrlOn>c<leftCtrlOff>`.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html).
|
||||
[template engine](/docs/templates/engine.html).
|
||||
The available variables are:
|
||||
|
||||
* `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
|
|
@ -185,7 +185,7 @@ builder.
|
|||
- `parallels_tools_guest_path` (string) - The path in the virtual machine to
|
||||
upload Parallels Tools. This only takes effect if `parallels_tools_mode`
|
||||
is "upload". This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) that has a single
|
||||
template](/docs/templates/engine.html) that has a single
|
||||
valid variable: `Flavor`, which will be the value of
|
||||
`parallels_tools_flavor`. By default this is "prl-tools-{{.Flavor}}.iso"
|
||||
which should upload into the login directory of the user.
|
||||
|
@ -204,7 +204,7 @@ builder.
|
|||
itself as an array of strings, where each string represents a single
|
||||
argument on the command-line to `prlctl` (but excluding `prlctl` itself).
|
||||
Each arg is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html), where the `Name`
|
||||
template](/docs/templates/engine.html), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use `prlctl`
|
||||
are below.
|
||||
|
||||
|
@ -305,7 +305,7 @@ characters as well inside modifiers.
|
|||
For example: to simulate ctrl+c use `<leftCtrlOn>c<leftCtrlOff>`.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
@ -356,7 +356,6 @@ executed in the order defined. So in the above example, the memory will be set
|
|||
followed by the CPUs.
|
||||
|
||||
Each command itself is an array of strings, where each string is an argument to
|
||||
`prlctl`. Each argument is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html). The only available
|
||||
`prlctl`. Each argument is treated as a [template engine](/docs/templates/engine.html). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many `prlctl` calls.
|
||||
|
|
|
@ -106,7 +106,7 @@ builder.
|
|||
- `parallels_tools_guest_path` (string) - The path in the VM to upload
|
||||
Parallels Tools. This only takes effect if `parallels_tools_mode`
|
||||
is "upload". This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) that has a single
|
||||
template](/docs/templates/engine.html) that has a single
|
||||
valid variable: `Flavor`, which will be the value of
|
||||
`parallels_tools_flavor`. By default this is "prl-tools-{{.Flavor}}.iso"
|
||||
which should upload into the login directory of the user.
|
||||
|
@ -125,7 +125,7 @@ builder.
|
|||
itself as an array of strings, where each string represents a single
|
||||
argument on the command-line to `prlctl` (but excluding `prlctl` itself).
|
||||
Each arg is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html), where the `Name`
|
||||
template](/docs/templates/engine.html), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use `prlctl`
|
||||
are below.
|
||||
|
||||
|
@ -231,7 +231,7 @@ proper key:
|
|||
for the UI to update before typing more.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
## prlctl Commands
|
||||
|
@ -261,6 +261,6 @@ followed by the CPUs.
|
|||
|
||||
Each command itself is an array of strings, where each string is an argument to
|
||||
`prlctl`. Each argument is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html). The only available
|
||||
template](/docs/templates/engine.html). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many `prlctl` calls.
|
||||
|
|
|
@ -427,7 +427,7 @@ characters as well inside modifiers. For example: to simulate ctrl+c use
|
|||
`<leftCtrlOn>c<leftCtrlOff>`.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
|
|
@ -174,7 +174,7 @@ builder.
|
|||
where the VirtualBox guest additions ISO will be uploaded. By default this
|
||||
is "VBoxGuestAdditions.iso" which should upload into the login directory of
|
||||
the user. This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) where the `Version`
|
||||
template](/docs/templates/engine.html) where the `Version`
|
||||
variable is replaced with the VirtualBox version.
|
||||
|
||||
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest
|
||||
|
@ -293,7 +293,7 @@ builder.
|
|||
defined itself as an array of strings, where each string represents a single
|
||||
argument on the command-line to `VBoxManage` (but excluding
|
||||
`VBoxManage` itself). Each arg is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html), where the `Name`
|
||||
template](/docs/templates/engine.html), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use
|
||||
`VBoxManage` are below.
|
||||
|
||||
|
@ -390,7 +390,7 @@ characters as well inside modifiers.
|
|||
For example: to simulate ctrl+c use `<leftCtrlOn>c<leftCtrlOff>`.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
@ -457,6 +457,6 @@ followed by the CPUs.
|
|||
|
||||
Each command itself is an array of strings, where each string is an argument to
|
||||
`VBoxManage`. Each argument is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html). The only available
|
||||
template](/docs/templates/engine.html). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many VBoxManage calls.
|
||||
|
|
|
@ -167,7 +167,7 @@ builder.
|
|||
where the VirtualBox guest additions ISO will be uploaded. By default this
|
||||
is "VBoxGuestAdditions.iso" which should upload into the login directory of
|
||||
the user. This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) where the `Version`
|
||||
template](/docs/templates/engine.html) where the `Version`
|
||||
variable is replaced with the VirtualBox version.
|
||||
|
||||
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest
|
||||
|
@ -257,7 +257,7 @@ builder.
|
|||
defined itself as an array of strings, where each string represents a single
|
||||
argument on the command-line to `VBoxManage` (but excluding
|
||||
`VBoxManage` itself). Each arg is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html), where the `Name`
|
||||
template](/docs/templates/engine.html), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use
|
||||
`VBoxManage` are below.
|
||||
|
||||
|
@ -347,7 +347,7 @@ by the proper key:
|
|||
for the UI to update before typing more.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
@ -414,6 +414,6 @@ followed by the CPUs.
|
|||
|
||||
Each command itself is an array of strings, where each string is an argument to
|
||||
`VBoxManage`. Each argument is treated as a [configuration
|
||||
template](/docs/templates/configuration-templates.html). The only available
|
||||
template](/docs/templates/engine.html). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many VBoxManage calls.
|
||||
|
|
|
@ -253,7 +253,7 @@ builder.
|
|||
- `tools_upload_path` (string) - The path in the VM to upload the
|
||||
VMware tools. This only takes effect if `tools_upload_flavor` is non-empty.
|
||||
This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) that has a single
|
||||
template](/docs/templates/engine.html) that has a single
|
||||
valid variable: `Flavor`, which will be the value of `tools_upload_flavor`.
|
||||
By default the upload path is set to `{{.Flavor}}.iso`. This setting is not
|
||||
used when `remote_type` is "esx5".
|
||||
|
@ -279,7 +279,7 @@ builder.
|
|||
virtual machine is exported.
|
||||
|
||||
- `vmx_template_path` (string) - Path to a [configuration
|
||||
template](/docs/templates/configuration-templates.html) that defines the
|
||||
template](/docs/templates/engine.html) that defines the
|
||||
contents of the virtual machine VMX file for VMware. This is for **advanced
|
||||
users only** as this can render the virtual machine non-functional. See
|
||||
below for more information. For basic VMX modifications, try
|
||||
|
@ -371,7 +371,7 @@ characters as well inside modifiers.
|
|||
For example: to simulate ctrl+c use `<leftCtrlOn>c<leftCtrlOff>`.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
|
|
@ -147,7 +147,7 @@ builder.
|
|||
- `tools_upload_path` (string) - The path in the VM to upload the
|
||||
VMware tools. This only takes effect if `tools_upload_flavor` is non-empty.
|
||||
This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) that has a single
|
||||
template](/docs/templates/engine.html) that has a single
|
||||
valid variable: `Flavor`, which will be the value of `tools_upload_flavor`.
|
||||
By default the upload path is set to `{{.Flavor}}.iso`.
|
||||
|
||||
|
@ -243,7 +243,7 @@ command, they will be replaced by the proper key:
|
|||
for the UI to update before typing more.
|
||||
|
||||
In addition to the special keys, each command to type is treated as a
|
||||
[configuration template](/docs/templates/configuration-templates.html). The
|
||||
[template engine](/docs/templates/engine.html). The
|
||||
available variables are:
|
||||
|
||||
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
|
||||
|
|
|
@ -101,7 +101,7 @@ become a literal `\r`.
|
|||
### Machine-Readable Message Types
|
||||
|
||||
The set of machine-readable message types can be found in the
|
||||
[machine-readable format](/docs/machine-readable/index.html) complete
|
||||
[machine-readable format](/docs/commands/index.html) complete
|
||||
documentation section. This section contains documentation on all the message
|
||||
types exposed by Packer core as well as all the components that ship with
|
||||
Packer by default.
|
||||
|
|
|
@ -12,7 +12,7 @@ description: |-
|
|||
# `validate` Command
|
||||
|
||||
The `packer validate` Packer command is used to validate the syntax and
|
||||
configuration of a [template](/docs/templates/introduction.html). The command
|
||||
configuration of a [template](/docs/templates/index.html). The command
|
||||
will return a zero exit status on success, and a non-zero exit status on
|
||||
failure. Additionally, if a template doesn't validate, any error messages will
|
||||
be outputted.
|
||||
|
|
|
@ -17,7 +17,7 @@ builder, etc. However, it is possible to write custom builders using the Packer
|
|||
plugin interface, and this page documents how to do that.
|
||||
|
||||
Prior to reading this page, it is assumed you have read the page on [plugin
|
||||
development basics](/docs/extending/developing-plugins.html).
|
||||
development basics](/docs/extending/plugins.html).
|
||||
|
||||
~> **Warning!** This is an advanced topic. If you're new to Packer, we
|
||||
recommend getting a bit more comfortable before you dive into writing plugins.
|
||||
|
|
|
@ -19,7 +19,7 @@ transformation would be taking an artifact with some set of files, uploading
|
|||
those files, and returning an artifact with a single ID: the URL of the upload.
|
||||
|
||||
Prior to reading this page, it is assumed you have read the page on [plugin
|
||||
development basics](/docs/extending/developing-plugins.html).
|
||||
development basics](/docs/extending/plugins.html).
|
||||
|
||||
Post-processor plugins implement the `packer.PostProcessor` interface and are
|
||||
served using the `plugin.ServePostProcessor` function.
|
||||
|
|
|
@ -18,7 +18,7 @@ provisioner](/docs/provisioners/shell.html), which runs shell scripts within the
|
|||
machines.
|
||||
|
||||
Prior to reading this page, it is assumed you have read the page on [plugin
|
||||
development basics](/docs/extending/developing-plugins.html).
|
||||
development basics](/docs/extending/plugins.html).
|
||||
|
||||
Provisioner plugins implement the `packer.Provisioner` interface and are served
|
||||
using the `plugin.ServeProvisioner` function.
|
||||
|
|
|
@ -19,7 +19,7 @@ as Plugins that are simply hardcoded to load with Packer.
|
|||
|
||||
This page will cover how to install and use plugins. If you're interested in
|
||||
developing plugins, the documentation for that is available the [developing
|
||||
plugins](/docs/extending/developing-plugins.html) page.
|
||||
plugins](/docs/extending/plugins.html) page.
|
||||
|
||||
Because Packer is so young, there is no official listing of available Packer
|
||||
plugins. Plugins are best found via Google. Typically, searching "packer plugin
|
||||
|
|
|
@ -57,7 +57,7 @@ Optional parameters:
|
|||
|
||||
- `execute_command` (string) - The command to use to execute the script. By
|
||||
default this is `chmod +x "{{.Script}}"; {{.Vars}} "{{.Script}}"`.
|
||||
The value of this is treated as [configuration template](/docs/templates/configuration-templates.html).
|
||||
The value of this is treated as [template engine](/docs/templates/engine.html).
|
||||
There are two available variables: `Script`, which is the path to the script
|
||||
to run, `Vars`, which is the list of `environment_vars`, if configured.
|
||||
|
||||
|
|
|
@ -66,7 +66,7 @@ more details about certain options in following sections.
|
|||
|
||||
- `output` (string) - The full path to the box file that will be created by
|
||||
this post-processor. This is a [configuration
|
||||
template](/docs/templates/configuration-templates.html). The variable
|
||||
template](/docs/templates/engine.html). The variable
|
||||
`Provider` is replaced by the Vagrant provider the box is for. The variable
|
||||
`ArtifactId` is replaced by the ID of the input artifact. The variable
|
||||
`BuildName` is replaced with the name of the build. By default, the value of
|
||||
|
|
|
@ -57,7 +57,7 @@ configuration is actually required.
|
|||
|
||||
- `execute_command` (string) - The command used to execute Chef. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `guest_os_type` (string) - The target guest OS type, either "unix" or
|
||||
|
@ -66,7 +66,7 @@ configuration is actually required.
|
|||
|
||||
- `install_command` (string) - The command used to install Chef. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `json` (object) - An arbitrary mapping of JSON that will be available as
|
||||
|
@ -74,7 +74,7 @@ configuration is actually required.
|
|||
|
||||
- `knife_command` (string) - The command used to run Knife during node clean-up. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `node_name` (string) - The name of the node to register with the
|
||||
|
@ -161,7 +161,7 @@ ssl_verify_mode :{{.SslVerifyMode}}
|
|||
```
|
||||
|
||||
This template is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) and has a set of
|
||||
template](/docs/templates/engine.html) and has a set of
|
||||
variables available to use:
|
||||
|
||||
- `ChefEnvironment` - The Chef environment name.
|
||||
|
|
|
@ -66,7 +66,7 @@ configuration is actually required, but at least `run_list` is recommended.
|
|||
|
||||
- `execute_command` (string) - The command used to execute Chef. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `guest_os_type` (string) - The target guest OS type, either "unix" or
|
||||
|
@ -75,7 +75,7 @@ configuration is actually required, but at least `run_list` is recommended.
|
|||
|
||||
- `install_command` (string) - The command used to install Chef. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `json` (object) - An arbitrary mapping of JSON that will be available as
|
||||
|
@ -125,7 +125,7 @@ cookbook_path [{{.CookbookPaths}}]
|
|||
```
|
||||
|
||||
This template is a [configuration
|
||||
template](/docs/templates/configuration-templates.html) and has a set of
|
||||
template](/docs/templates/engine.html) and has a set of
|
||||
variables available to use:
|
||||
|
||||
- `ChefEnvironment` - The current enabled environment. Only non-empty if the
|
||||
|
|
|
@ -57,14 +57,14 @@ Optional parameters:
|
|||
|
||||
- `execute_command` (string) - the command used to execute Converge. This has
|
||||
various
|
||||
[configuration template variables](/docs/templates/configuration-templates.html) available.
|
||||
[configuration template variables](/docs/templates/engine.html) available.
|
||||
|
||||
- `prevent_sudo` (bool) - stop Converge from running with adminstrator
|
||||
privileges via sudo
|
||||
|
||||
- `bootstrap_command` (string) - the command used to bootstrap Converge. This
|
||||
has various
|
||||
[configuration template variables](/docs/templates/configuration-templates.html) available.
|
||||
[configuration template variables](/docs/templates/engine.html) available.
|
||||
|
||||
- `prevent_bootstrap_sudo` (bool) - stop Converge from bootstrapping with
|
||||
administrator privileges via sudo
|
||||
|
|
|
@ -63,7 +63,7 @@ Optional parameters:
|
|||
- `execute_command` (string) - The command to use to execute the script. By
|
||||
default this is `powershell "& { {{.Vars}}{{.Path}}; exit $LastExitCode}"`.
|
||||
The value of this is treated as [configuration
|
||||
template](/docs/templates/configuration-templates.html). There are two
|
||||
template](/docs/templates/engine.html). There are two
|
||||
available variables: `Path`, which is the path to the script to run, and
|
||||
`Vars`, which is the list of `environment_vars`, if configured.
|
||||
|
||||
|
|
|
@ -56,7 +56,7 @@ Optional parameters:
|
|||
|
||||
- `execute_command` (string) - The command used to execute Puppet. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information.
|
||||
|
||||
- `extra_arguments` (array of strings) - This is an array of additional options to
|
||||
|
|
|
@ -83,7 +83,7 @@ listed below:
|
|||
|
||||
- `execute_command` (string) - This is optional. The command used to execute Puppet. This has
|
||||
various [configuration template
|
||||
variables](/docs/templates/configuration-templates.html) available. See
|
||||
variables](/docs/templates/engine.html) available. See
|
||||
below for more information. By default, Packer uses the following command:
|
||||
|
||||
```liquid
|
||||
|
|
|
@ -43,5 +43,5 @@ Optional parameters:
|
|||
the script. By default this is `["/bin/sh", "-c", "{{.Command}}"]`. The value
|
||||
is an array of arguments executed directly by the OS. The value of this is
|
||||
treated as [configuration
|
||||
template](/docs/templates/configuration-templates.html). The only available
|
||||
template](/docs/templates/engine.html). The only available
|
||||
variable is `Command` which is the command to execute.
|
||||
|
|
|
@ -68,7 +68,7 @@ Optional parameters:
|
|||
- `execute_command` (string) - The command to use to execute the script. By
|
||||
default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`. The value
|
||||
of this is treated as [configuration
|
||||
template](/docs/templates/configuration-templates.html). There are two
|
||||
template](/docs/templates/engine.html). There are two
|
||||
available variables: `Path`, which is the path to the script to run, and
|
||||
`Vars`, which is the list of `environment_vars`, if configured.
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ Optional parameters:
|
|||
|
||||
- `execute_command` (string) - The command to use to execute the script. By
|
||||
default this is `{{ .Vars }}"{{ .Path }}"`. The value of this is treated as
|
||||
[configuration template](/docs/templates/configuration-templates.html).
|
||||
[template engine](/docs/templates/engine.html).
|
||||
There are two available variables: `Path`, which is the path to the script
|
||||
to run, and `Vars`, which is the list of `environment_vars`, if configured.
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ and other types of information out of your templates. This maximizes the
|
|||
portability and shareability of the template.
|
||||
|
||||
Using user variables expects you know how [configuration
|
||||
templates](/docs/templates/configuration-templates.html) work. If you don't know
|
||||
templates](/docs/templates/engine.html) work. If you don't know
|
||||
how configuration templates work yet, please read that page first.
|
||||
|
||||
## Usage
|
||||
|
|
|
@ -14,7 +14,7 @@ description: |-
|
|||
With Packer installed, let's just dive right into it and build our first image.
|
||||
Our first image will be an [Amazon EC2 AMI](https://aws.amazon.com/ec2/) with
|
||||
Redis pre-installed. This is just an example. Packer can create images for [many
|
||||
platforms](/intro/platforms.html) with anything pre-installed.
|
||||
platforms][platforms] with anything pre-installed.
|
||||
|
||||
If you don't have an AWS account, [create one now](https://aws.amazon.com/free/).
|
||||
For the example, we'll use a "t2.micro" instance to build our image, which
|
||||
|
@ -26,7 +26,7 @@ of money, but it shouldn't be more than a few cents.
|
|||
free-tier, you may be charged to run these examples. The charge should only be a
|
||||
few cents, but we're not responsible if it ends up being more.
|
||||
|
||||
Packer can build images for [many platforms](/intro/platforms.html) other than
|
||||
Packer can build images for [many platforms][platforms] other than
|
||||
AWS, but AWS requires no additional software installed on your computer and
|
||||
their [free-tier](https://aws.amazon.com/free/) makes it free to use for most
|
||||
people. This is why we chose to use AWS for the example. If you're uncomfortable
|
||||
|
@ -84,7 +84,7 @@ re-packaging it into a new AMI.
|
|||
The additional keys within the object are configuration for this builder,
|
||||
specifying things such as access keys, the source AMI to build from and more.
|
||||
The exact set of configuration variables available for a builder are specific to
|
||||
each builder and can be found within the [documentation](/docs).
|
||||
each builder and can be found within the [documentation](/docs/index.html).
|
||||
|
||||
Before we take this template and build an image from it, let's validate the
|
||||
template by running `packer validate example.json`. This command checks the
|
||||
|
@ -191,3 +191,5 @@ Congratulations! You've just built your first image with Packer. Although the
|
|||
image was pretty useless in this case (nothing was changed about it), this page
|
||||
should've given you a general idea of how Packer works, what templates are and
|
||||
how to validate and build templates into machine images.
|
||||
|
||||
[platforms]: /docs/builders/index.html
|
||||
|
|
|
@ -17,7 +17,7 @@ builds, provisioners, etc. At this point you're ready to begin playing with and
|
|||
using Packer in real scenarios.
|
||||
|
||||
From this point forward, the most important reference for you will be the
|
||||
[documentation](/docs). The documentation is less of a guide and more of a
|
||||
[documentation](/docs/index.html). The documentation is less of a guide and more of a
|
||||
reference of all the overall features and options of Packer.
|
||||
|
||||
If you're interested in learning more about how Packer fits into the HashiCorp
|
||||
|
|
|
@ -73,7 +73,7 @@ builders defined in our template, such as both Amazon and DigitalOcean, then the
|
|||
shell script would run as part of both builds. There are ways to restrict
|
||||
provisioners to certain builds, but it is outside the scope of this getting
|
||||
started guide. It is covered in more detail in the complete
|
||||
[documentation](/docs).
|
||||
[documentation](/docs/index.html).
|
||||
|
||||
The one provisioner we defined has a type of `shell`. This provisioner ships
|
||||
with Packer and runs shell scripts on the running machine. In our case, we
|
||||
|
|
|
@ -13,7 +13,8 @@ description: |-
|
|||
Welcome to the world of Packer! This introduction guide will show you what
|
||||
Packer is, explain why it exists, the benefits it has to offer, and how you can
|
||||
get started with it. If you're already familiar with Packer, the
|
||||
[documentation](/docs) provides more of a reference for all available features.
|
||||
[documentation](/docs/index.html) provides more of a reference for all available
|
||||
features.
|
||||
|
||||
## What is Packer?
|
||||
|
||||
|
|
Loading…
Reference in New Issue