remove unnecessary .html extensions
This commit is contained in:
parent
86b6a4562b
commit
d626cedd45
|
@ -19,7 +19,7 @@ vendors. These plugins are not officially tested nor officially maintained by
|
|||
HashiCorp, and are listed here in order to help users find them easily.
|
||||
|
||||
To learn more about how to use community plugins, or how to build your own,
|
||||
check out the docs on [extending Packer](/docs/extending/plugins.html)
|
||||
check out the docs on [extending Packer](/docs/extending/plugins)
|
||||
|
||||
If you have built a plugin and would like to add it to this community list,
|
||||
please make a pull request to the website so that we can document your
|
||||
|
|
|
@ -19,7 +19,7 @@ customized images based on an existing base images.
|
|||
|
||||
The following configuration options are available for building Alicloud images.
|
||||
In addition to the options listed here, a
|
||||
[communicator](../templates/communicator.html) can be configured for this
|
||||
[communicator](../templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -31,7 +31,7 @@ the extra fast build.
|
|||
|
||||
~> **This is an advanced builder** If you're just getting started with
|
||||
Packer, we recommend starting with the [amazon-ebs
|
||||
builder](/docs/builders/amazon-ebs.html), which is much easier to use.
|
||||
builder](/docs/builders/amazon-ebs), which is much easier to use.
|
||||
|
||||
The builder does _not_ manage AMIs. Once it creates an AMI and stores it in
|
||||
your account, it is up to you to use, delete, etc., the AMI.
|
||||
|
@ -299,7 +299,7 @@ variables are available:
|
|||
|
||||
## Build function template engine variables
|
||||
|
||||
For the build function of [template engine](/docs/templates/engine.html), the following
|
||||
For the build function of [template engine](/docs/templates/engine), the following
|
||||
variables are available:
|
||||
|
||||
- `SourceAMIName` - The source AMI Name (for example
|
||||
|
|
|
@ -201,7 +201,7 @@ variables are available:
|
|||
|
||||
## Build function template engine variables
|
||||
|
||||
For the build function of [template engine](/docs/templates/engine.html), the following
|
||||
For the build function of [template engine](/docs/templates/engine), the following
|
||||
variables are available:
|
||||
|
||||
- `SourceAMIName` - The source AMI Name (for example
|
||||
|
|
|
@ -163,7 +163,7 @@ variables are available:
|
|||
|
||||
## Build function template engine variables
|
||||
|
||||
For the build function of [template engine](/docs/templates/engine.html), the following
|
||||
For the build function of [template engine](/docs/templates/engine), the following
|
||||
variables are available:
|
||||
|
||||
- `SourceAMIName` - The source AMI Name (for example
|
||||
|
|
|
@ -190,7 +190,7 @@ marked for deletion on termination will remain in your account.
|
|||
|
||||
## Build function template engine variables
|
||||
|
||||
For the build function of [template engine](/docs/templates/engine.html), the following
|
||||
For the build function of [template engine](/docs/templates/engine), the following
|
||||
variables are available:
|
||||
|
||||
- `SourceAMIName` - The source AMI Name (for example
|
||||
|
|
|
@ -14,29 +14,29 @@ Packer is able to create Amazon AMIs. To achieve this, Packer comes with
|
|||
multiple builders depending on the strategy you want to use to build the AMI.
|
||||
Packer supports the following builders at the moment:
|
||||
|
||||
- [amazon-ebs](/docs/builders/amazon-ebs.html) - Create EBS-backed AMIs by
|
||||
- [amazon-ebs](/docs/builders/amazon-ebs) - Create EBS-backed AMIs by
|
||||
launching a source AMI and re-packaging it into a new AMI after
|
||||
provisioning. If in doubt, use this builder, which is the easiest to get
|
||||
started with.
|
||||
|
||||
- [amazon-instance](/docs/builders/amazon-instance.html) - Create
|
||||
- [amazon-instance](/docs/builders/amazon-instance) - Create
|
||||
instance-store AMIs by launching and provisioning a source instance, then
|
||||
rebundling it and uploading it to S3.
|
||||
|
||||
- [amazon-chroot](/docs/builders/amazon-chroot.html) - Create EBS-backed AMIs
|
||||
- [amazon-chroot](/docs/builders/amazon-chroot) - Create EBS-backed AMIs
|
||||
from an existing EC2 instance by mounting the root device and using a
|
||||
[Chroot](https://en.wikipedia.org/wiki/Chroot) environment to provision
|
||||
that device. This is an **advanced builder and should not be used by
|
||||
newcomers**. However, it is also the fastest way to build an EBS-backed AMI
|
||||
since no new EC2 instance needs to be launched.
|
||||
|
||||
- [amazon-ebssurrogate](/docs/builders/amazon-ebssurrogate.html) - Create EBS
|
||||
- [amazon-ebssurrogate](/docs/builders/amazon-ebssurrogate) - Create EBS
|
||||
-backed AMIs from scratch. Works similarly to the `chroot` builder but does
|
||||
not require running in AWS. This is an **advanced builder and should not be
|
||||
used by newcomers**.
|
||||
|
||||
-> **Don't know which builder to use?** If in doubt, use the [amazon-ebs
|
||||
builder](/docs/builders/amazon-ebs.html). It is much easier to use and Amazon
|
||||
builder](/docs/builders/amazon-ebs). It is much easier to use and Amazon
|
||||
generally recommends EBS-backed images nowadays.
|
||||
|
||||
# Amazon EBS Volume Builder
|
||||
|
@ -44,7 +44,7 @@ generally recommends EBS-backed images nowadays.
|
|||
Packer is able to create Amazon EBS Volumes which are preinitialized with a
|
||||
filesystem and data.
|
||||
|
||||
- [amazon-ebsvolume](/docs/builders/amazon-ebsvolume.html) - Create EBS
|
||||
- [amazon-ebsvolume](/docs/builders/amazon-ebsvolume) - Create EBS
|
||||
volumes by launching a source AMI with block devices mapped. Provision the
|
||||
instance, then destroy it, retaining the EBS volumes.
|
||||
|
||||
|
|
|
@ -44,7 +44,7 @@ machine. This can be done within a provisioner, but must be done before the
|
|||
builder finishes running.
|
||||
|
||||
~> Instance builds are not supported for Windows. Use
|
||||
[`amazon-ebs`](amazon-ebs.html) instead.
|
||||
[`amazon-ebs`](amazon-ebs) instead.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
|
@ -169,7 +169,7 @@ variables are available:
|
|||
|
||||
## Build function template engine variables
|
||||
|
||||
For the build function of [template engine](/docs/templates/engine.html), the following
|
||||
For the build function of [template engine](/docs/templates/engine), the following
|
||||
variables are available:
|
||||
|
||||
- `SourceAMIName` - The source AMI Name (for example
|
||||
|
@ -190,7 +190,7 @@ upload the AMI.
|
|||
|
||||
These are configured with `bundle_vol_command` and `bundle_upload_command`.
|
||||
Both of these configurations are [configuration
|
||||
templates](/docs/templates/engine.html) and have support for their own set of
|
||||
templates](/docs/templates/engine) and have support for their own set of
|
||||
template variables.
|
||||
|
||||
### Bundle Volume Command
|
||||
|
|
|
@ -18,7 +18,7 @@ costs for VMs built and stored using Packer.
|
|||
|
||||
Azure uses a combination of OAuth and Active Directory to authorize requests to
|
||||
the ARM API. Learn how to [authorize access to
|
||||
ARM](/docs/builders/azure.html#authentication-for-azure).
|
||||
ARM](/docs/builders/azure#authentication-for-azure).
|
||||
|
||||
The documentation below references command output from the [Azure
|
||||
CLI](https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/).
|
||||
|
@ -27,7 +27,7 @@ CLI](https://azure.microsoft.com/en-us/documentation/articles/xplat-cli-install/
|
|||
|
||||
There are many configuration options available for the builder. We'll start
|
||||
with authentication parameters, then go over the Azure ARM builder specific
|
||||
options. In addition to the options listed here, a [communicator](/docs/templates/communicator.html) can be configured for this builder.
|
||||
options. In addition to the options listed here, a [communicator](/docs/templates/communicator) can be configured for this builder.
|
||||
|
||||
### Authentication options
|
||||
|
||||
|
@ -35,7 +35,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.html#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
|
||||
|
||||
|
@ -44,7 +44,7 @@ Packer will use cached credentials or redirect you to a website to log in.
|
|||
|
||||
#### Service Principal
|
||||
|
||||
To use a [service principal](/docs/builders/azure.html#azure-active-directory-service-principal)
|
||||
To use a [service principal](/docs/builders/azure#azure-active-directory-service-principal)
|
||||
you should specify `subscription_id`, `client_id` and one of `client_secret`,
|
||||
`client_cert_path` or `client_jwt`.
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ content and enables some capabilities that are not possible with the
|
|||
`azure-arm` builder.
|
||||
|
||||
> **This is an advanced builder** If you're just getting started with Packer,
|
||||
> it is recommend to start with the [azure-arm builder](/docs/builders/azure-arm.html),
|
||||
> it is recommend to start with the [azure-arm builder](/docs/builders/azure-arm),
|
||||
> which is much easier to use.
|
||||
|
||||
## How Does it Work?
|
||||
|
@ -58,7 +58,7 @@ options.
|
|||
|
||||
None of the authentication options are required, but depending on which
|
||||
ones are specified a different authentication method may be used. See the
|
||||
[shared Azure builders documentation](/docs/builders/azure.html) for more
|
||||
[shared Azure builders documentation](/docs/builders/azure) for more
|
||||
information.
|
||||
|
||||
@include 'builder/azure/common/client/Config-not-required.mdx'
|
||||
|
|
|
@ -16,12 +16,12 @@ Packer can create Azure virtual machine images through variety of ways
|
|||
depending on the strategy that you want to use for building the images.
|
||||
Packer supports the following builders for Azure images at the moment:
|
||||
|
||||
- [azure-arm](/docs/builders/azure-arm.html) - Uses Azure Resource
|
||||
- [azure-arm](/docs/builders/azure-arm) - Uses Azure Resource
|
||||
Manager (ARM) to launch a virtual machine (VM) from which a new image is
|
||||
captured after provisioning. If in doubt, use this builder; it is the
|
||||
easiest builder to get started with.
|
||||
|
||||
- [azure-chroot](/docs/builders/azure-chroot.html) - Uses ARM to create
|
||||
- [azure-chroot](/docs/builders/azure-chroot) - Uses ARM to create
|
||||
a managed disk that is attached to an existing Azure VM that Packer is
|
||||
running on. Provisioning leverages [Chroot](https://en.wikipedia.org/wiki/Chroot)
|
||||
environment. After provisioning, the disk is detached an image is created
|
||||
|
@ -30,7 +30,7 @@ Packer supports the following builders for Azure images at the moment:
|
|||
Azure.
|
||||
|
||||
-> **Don't know which builder to use?** If in doubt, use the [azure-arm
|
||||
builder](/docs/builders/azure-arm.html). It is much easier to use.
|
||||
builder](/docs/builders/azure-arm). It is much easier to use.
|
||||
|
||||
# Authentication for Azure
|
||||
|
||||
|
|
|
@ -29,7 +29,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -184,14 +184,14 @@ builder.
|
|||
`packer_<UUID>`, where <UUID> is a 36 character unique identifier.
|
||||
|
||||
- `user_data` (string) - User data to launch with the instance. This is a
|
||||
[template engine](/docs/templates/engine.html) see _User Data_ bellow for
|
||||
[template engine](/docs/templates/engine) see _User Data_ bellow for
|
||||
more details. Packer will not automatically wait for a user script to
|
||||
finish before shutting down the instance this must be handled in a
|
||||
provisioner.
|
||||
|
||||
- `user_data_file` (string) - Path to a file that will be used for the user
|
||||
data when launching the instance. This file will be parsed as a [template
|
||||
engine](/docs/templates/engine.html) see _User Data_ bellow for more
|
||||
engine](/docs/templates/engine) see _User Data_ bellow for more
|
||||
details.
|
||||
|
||||
- `use_local_ip_address` (boolean) - Set to `true` to indicate that the
|
||||
|
|
|
@ -14,5 +14,5 @@ sidebar_current: docs-builders-custom
|
|||
Packer is extensible, allowing you to write new builders without having to
|
||||
modify the core source code of Packer itself. Documentation for creating new
|
||||
builders is covered in the [custom
|
||||
builders](/docs/extending/custom-builders.html) page of the Packer plugin
|
||||
builders](/docs/extending/custom-builders) page of the Packer plugin
|
||||
section.
|
||||
|
|
|
@ -36,7 +36,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -79,7 +79,7 @@ builder.
|
|||
|
||||
- `snapshot_name` (string) - The name of the resulting snapshot that will
|
||||
appear in your account. Defaults to `packer-{{timestamp}}` (see
|
||||
[configuration templates](/docs/templates/engine.html) for more info).
|
||||
[configuration templates](/docs/templates/engine) for more info).
|
||||
|
||||
- `snapshot_regions` (array of strings) - The regions of the resulting
|
||||
snapshot that will appear in your account.
|
||||
|
|
|
@ -137,7 +137,7 @@ optional. Within each category, the available options are alphabetized and
|
|||
described.
|
||||
|
||||
The Docker builder uses a special Docker communicator _and will not use_ the
|
||||
standard [communicators](/docs/templates/communicator.html).
|
||||
standard [communicators](/docs/templates/communicator).
|
||||
|
||||
### Required:
|
||||
|
||||
|
@ -155,8 +155,8 @@ You must specify (only) one of `commit`, `discard`, or `export_path`.
|
|||
|
||||
Once the tar artifact has been generated, you will likely want to import, tag,
|
||||
and push it to a container repository. Packer can do this for you automatically
|
||||
with the [docker-import](/docs/post-processors/docker-import.html) and
|
||||
[docker-push](/docs/post-processors/docker-push.html) post-processors.
|
||||
with the [docker-import](/docs/post-processors/docker-import) and
|
||||
[docker-push](/docs/post-processors/docker-push) post-processors.
|
||||
|
||||
**Note:** This section is covering how to use an artifact that has been
|
||||
_exported_. More specifically, if you set `export_path` in your configuration.
|
||||
|
@ -165,7 +165,7 @@ If you set `commit`, see the next section.
|
|||
The example below shows a full configuration that would import and push the
|
||||
created image. This is accomplished using a sequence definition (a collection
|
||||
of post-processors that are treated as as single pipeline, see
|
||||
[Post-Processors](/docs/templates/post-processors.html) for more information):
|
||||
[Post-Processors](/docs/templates/post-processors) for more information):
|
||||
|
||||
```json
|
||||
{
|
||||
|
@ -204,7 +204,7 @@ If you committed your container to an image, you probably want to tag, save,
|
|||
push, etc. Packer can do this automatically for you. An example is shown below
|
||||
which tags and pushes an image. This is accomplished using a sequence
|
||||
definition (a collection of post-processors that are treated as as single
|
||||
pipeline, see [Post-Processors](/docs/templates/post-processors.html) for more
|
||||
pipeline, see [Post-Processors](/docs/templates/post-processors) for more
|
||||
information):
|
||||
|
||||
```json
|
||||
|
@ -313,7 +313,7 @@ above and example configuration properties are shown below:
|
|||
```
|
||||
|
||||
[Learn how to set Amazon AWS
|
||||
credentials.](/docs/builders/amazon.html#specifying-amazon-credentials)
|
||||
credentials.](/docs/builders/amazon#specifying-amazon-credentials)
|
||||
|
||||
## Dockerfiles
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ Configuration options are organized below into two categories: required and
|
|||
optional. Within each category, the available options are alphabetized and
|
||||
described.
|
||||
|
||||
Any [communicator](/docs/templates/communicator.html) defined is ignored.
|
||||
Any [communicator](/docs/templates/communicator) defined is ignored.
|
||||
|
||||
### Required:
|
||||
|
||||
|
|
|
@ -21,7 +21,7 @@ It is possible to build images from scratch, but not with the `googlecompute`
|
|||
Packer builder. The process is recommended only for advanced users, please see
|
||||
[Building GCE Images from Scratch](https://cloud.google.com/compute/docs/tutorials/building-images)
|
||||
and the [Google Compute Import
|
||||
Post-Processor](/docs/post-processors/googlecompute-import.html) for more
|
||||
Post-Processor](/docs/post-processors/googlecompute-import) for more
|
||||
information.
|
||||
|
||||
## Authentication
|
||||
|
@ -207,7 +207,7 @@ optional. Within each category, the available options are alphabetized and
|
|||
described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -31,7 +31,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -86,7 +86,7 @@ builder.
|
|||
|
||||
- `snapshot_name` (string) - The name of the resulting snapshot that will
|
||||
appear in your account. Defaults to `packer-{{timestamp}}` (see
|
||||
[configuration templates](/docs/templates/engine.html) for more info).
|
||||
[configuration templates](/docs/templates/engine) for more info).
|
||||
|
||||
- `snapshot_labels` (map of key/value strings) - Key/value pair labels to
|
||||
apply to the created image.
|
||||
|
|
|
@ -88,7 +88,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -124,7 +124,7 @@ builder.
|
|||
|
||||
- `image_name` (string) - The name of the resulting image. Defaults to
|
||||
`packer-{{timestamp}}`
|
||||
(see [configuration templates](/docs/templates/engine.html) for more info).
|
||||
(see [configuration templates](/docs/templates/engine) for more info).
|
||||
|
||||
- `image_service` (string) - The service of the resulting image.
|
||||
|
||||
|
|
|
@ -14,12 +14,12 @@ The HyperV Packer builder is able to create
|
|||
[Hyper-V](https://www.microsoft.com/en-us/server-cloud/solutions/virtualization.aspx)
|
||||
virtual machines and export them.
|
||||
|
||||
- [hyperv-iso](/docs/builders/hyperv-iso.html) - Starts from an ISO file,
|
||||
- [hyperv-iso](/docs/builders/hyperv-iso) - Starts from an ISO file,
|
||||
creates a brand new Hyper-V VM, installs an OS, provisions software within
|
||||
the OS, then exports that machine to create an image. This is best for
|
||||
people who want to start from scratch.
|
||||
|
||||
- [hyperv-vmcx](/docs/builders/hyperv-vmcx.html) - Clones an an existing
|
||||
- [hyperv-vmcx](/docs/builders/hyperv-vmcx) - Clones an an existing
|
||||
virtual machine, provisions software within the OS, then exports that
|
||||
machine to create an image. This is best for people who have existing base
|
||||
images and want to customize them.
|
||||
|
|
|
@ -68,7 +68,7 @@ are organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Optional:
|
||||
|
|
|
@ -68,7 +68,7 @@ are organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
## ISO Configuration Reference
|
||||
|
@ -138,7 +138,7 @@ The example shown below is a working boot command used to start an Ubuntu
|
|||
```
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## Integration Services
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required
|
||||
|
@ -70,7 +70,7 @@ builder.
|
|||
|
||||
- `image_label` (string) - The name of the resulting image that will appear
|
||||
in your account. Defaults to `packer-{{timestamp}}` (see [configuration
|
||||
templates](/docs/templates/engine.html) for more info).
|
||||
templates](/docs/templates/engine) for more info).
|
||||
|
||||
- `image_description` (string) - The description of the resulting image that
|
||||
will appear in your account. Defaults to "".
|
||||
|
|
|
@ -36,4 +36,4 @@ provisioners are defined, but it will connect to the specified host via ssh.
|
|||
## Configuration Reference
|
||||
|
||||
The null builder has no configuration parameters other than the
|
||||
[communicator](/docs/templates/communicator.html) settings.
|
||||
[communicator](/docs/templates/communicator) settings.
|
||||
|
|
|
@ -20,7 +20,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required
|
||||
|
|
|
@ -37,8 +37,8 @@ or earlier, we recommend you use Packer v1.1.2 or earlier version.
|
|||
~> **OpenStack Liberty or later requires OpenSSL!** To use the OpenStack
|
||||
builder with OpenStack Liberty (Oct 2015) or later you need to have OpenSSL
|
||||
installed _if you are using temporary key pairs_, i.e. don't use
|
||||
[`ssh_keypair_name`](openstack.html#ssh_keypair_name) nor
|
||||
[`ssh_password`](/docs/templates/communicator.html#ssh_password). All major
|
||||
[`ssh_keypair_name`](openstack#ssh_keypair_name) nor
|
||||
[`ssh_password`](/docs/templates/communicator#ssh_password). All major
|
||||
OS'es have OpenSSL installed by default except Windows. This have been resolved
|
||||
in OpenStack Ocata(Feb 2017).
|
||||
|
||||
|
@ -53,7 +53,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -142,7 +142,7 @@ which discusses the strategy used here.
|
|||
If this is set, a few more options become available.
|
||||
|
||||
- `builder_communicator` (communicator) - This represents an
|
||||
[`ssh communicator`](/docs/templates/communicator.html#ssh-communicator),
|
||||
[`ssh communicator`](/docs/templates/communicator#ssh-communicator),
|
||||
and can be configured as such. If you use a different builder image, you
|
||||
may need to change the `ssh_username`, for example. That might look like
|
||||
this:
|
||||
|
|
|
@ -12,11 +12,11 @@ Packer is able to create custom images on both Oracle Cloud Infrastructure and
|
|||
Oracle Cloud Infrastructure Classic Compute. Packer comes with builders
|
||||
designed to support both platforms. Please choose the one that's right for you:
|
||||
|
||||
- [oracle-classic](/docs/builders/oracle-classic.html) - Create custom images
|
||||
- [oracle-classic](/docs/builders/oracle-classic) - Create custom images
|
||||
in Oracle Cloud Infrastructure Classic Compute by launching a source
|
||||
instance and creating an image list from a snapshot of it after
|
||||
provisioning.
|
||||
|
||||
- [oracle-oci](/docs/builders/oracle-oci.html) - Create custom images in
|
||||
- [oracle-oci](/docs/builders/oracle-oci) - Create custom images in
|
||||
Oracle Cloud Infrastructure (OCI) by launching a base instance and creating
|
||||
an image from it after provisioning.
|
||||
|
|
|
@ -42,7 +42,7 @@ in which case you don't need the above user authorization.
|
|||
|
||||
There are many configuration options available for the `oracle-oci` builder. In
|
||||
addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required
|
||||
|
@ -84,8 +84,8 @@ builder.
|
|||
operation available in the Core Services API.
|
||||
|
||||
Note: the subnet must be configured to allow access via your chosen
|
||||
[communicator](/docs/templates/communicator.html) (communicator defaults to
|
||||
[SSH tcp/22](/docs/templates/communicator.html#ssh_port)).
|
||||
[communicator](/docs/templates/communicator) (communicator defaults to
|
||||
[SSH tcp/22](/docs/templates/communicator#ssh_port)).
|
||||
|
||||
### Optional
|
||||
|
||||
|
|
|
@ -43,20 +43,20 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](../templates/communicator.html) can be configured for this
|
||||
[communicator](../templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale.html#authentication)
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine.html) for more info).
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine) for more info).
|
||||
|
||||
- `vm_type` (string) - The Outscale VM type to use while building the OMI, such as `t2.small`.
|
||||
|
||||
- `region` (string) - The name of the region, such as `us-east-1`, in which to launch the Outscale VM to create the OMI.
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale.html#authentication)
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `source_omi` (string) - The initial OMI used as a base for the newly created machine. `source_omi_filter` may be used instead to populate this automatically.
|
||||
|
||||
|
@ -83,7 +83,7 @@ builder.
|
|||
|
||||
- `volume_type` (string) - The volume type. `gp2` for General Purpose (SSD) volumes, `io1` for Provisioned IOPS (SSD) volumes, and `standard` for Magnetic volumes
|
||||
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s). By default this description is empty. This is a [template engine](../templates/engine.html), see [Build template
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s). By default this description is empty. This is a [template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `omi_account_ids` (array of strings) - A list of account IDs that have access to launch the resulting OMI(s). By default no additional users other than the user creating the OMIS has permissions to launch it.
|
||||
|
@ -103,7 +103,7 @@ builder.
|
|||
sometimes desirable to [run Sysprep](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc721940(v=ws.10)>) which will stop the VM for you. If this is set to `true`, Packer
|
||||
_will not_ stop the VM but will assume that you will send the stop
|
||||
signal yourself through your final provisioner. You can do this with a
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell).
|
||||
|
||||
Note that Packer will still wait for the VM to be stopped, and
|
||||
failing to send the stop signal yourself, when you have set this flag to
|
||||
|
@ -133,13 +133,13 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the VM
|
||||
that is _launched_ to create the OMI. These tags are _not_ applied to the
|
||||
resulting OMIS unless they're duplicated in `tags`. This is a [template
|
||||
engine](../templates/engine.html), see [Build template
|
||||
engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `run_volume_tags` (object of key/value strings) - Tags to apply to the
|
||||
volumes that are _launched_ to create the OMI. These tags are _not_ applied
|
||||
to the resulting OMIS unless they're duplicated in `tags`. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
[template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `security_group_id` (string) - The ID (_not_ the name) of the security
|
||||
|
@ -171,7 +171,7 @@ builder.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override OMIS tags if already applied to snapshot. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
[template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `source_omi_filter` (object) - Filters used to populate the `source_omi` field.
|
||||
|
@ -198,7 +198,7 @@ builder.
|
|||
This will fail unless _exactly_ one OMIS is returned. In the above example,
|
||||
`most_recent` will cause this to succeed by selecting the newest image.
|
||||
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator.html#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator.html#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
|
||||
- `ssh_agent_auth` (boolean) - If true, the local SSH agent will be used to authenticate connections to the source VM. No temporary keypair will be created, and the values of `ssh_password` and `ssh_private_key_file` will be ignored. To use this option with a key pair already configured in the source OMI, leave the `ssh_keypair_name` blank. To associate an existing key pair in Outscale with the source VM, set the `ssh_keypair_name` field to the name of the key pair.
|
||||
|
||||
|
@ -208,7 +208,7 @@ builder.
|
|||
|
||||
- `subnet_id` (string) - If using Net, the ID of the subnet, such as `subnet-12345def`, where Packer will launch the VM. This field is required if you are using an non-default Net.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMIS and relevant snapshots. This is a [template engine](../templates/engine.html), see [Build template data](#build-template-data) for more information.
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMIS and relevant snapshots. This is a [template engine](../templates/engine), see [Build template data](#build-template-data) for more information.
|
||||
|
||||
- `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.
|
||||
|
||||
|
|
|
@ -31,20 +31,20 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale.html#authentication)
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine.html) for more info).
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine) for more info).
|
||||
|
||||
- `vm_type` (string) - The Outscale VM type to use while building the OMI, such as `t2.small`.
|
||||
|
||||
- `region` (string) - The name of the region, such as `us-east-1`, in which to launch the Outscale VM to create the OMI.
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale.html#authentication)
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `source_omi` (string) - The initial OMI used as a base for the newly created machine. `source_omi_filter` may be used instead to populate this automatically.
|
||||
|
||||
|
@ -79,7 +79,7 @@ builder.
|
|||
|
||||
- `volume_type` (string) - The volume type. `gp2` for General Purpose (SSD) volumes, `io1` for Provisioned IOPS (SSD) volumes, and `standard` for Magnetic volumes
|
||||
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s). By default this description is empty. This is a [template engine](../templates/engine.html), see [Build template
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s). By default this description is empty. This is a [template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `omi_account_ids` (array of strings) - A list of account IDs that have access to launch the resulting OMI(s). By default no additional users other than the user creating the OMIS has permissions to launch it.
|
||||
|
@ -99,7 +99,7 @@ builder.
|
|||
sometimes desirable to [run Sysprep](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc721940(v=ws.10)>) which will stop the VM for you. If this is set to `true`, Packer
|
||||
_will not_ stop the VM but will assume that you will send the stop
|
||||
signal yourself through your final provisioner. You can do this with a
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell).
|
||||
|
||||
Note that Packer will still wait for the VM to be stopped, and
|
||||
failing to send the stop signal yourself, when you have set this flag to
|
||||
|
@ -141,13 +141,13 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the VM
|
||||
that is _launched_ to create the OMI. These tags are _not_ applied to the
|
||||
resulting OMIS unless they're duplicated in `tags`. This is a [template
|
||||
engine](../templates/engine.html), see [Build template
|
||||
engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `run_volume_tags` (object of key/value strings) - Tags to apply to the
|
||||
volumes that are _launched_ to create the OMI. These tags are _not_ applied
|
||||
to the resulting OMIS unless they're duplicated in `tags`. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
[template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `security_group_id` (string) - The ID (_not_ the name) of the security
|
||||
|
@ -179,7 +179,7 @@ builder.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override OMIS tags if already applied to snapshot. This is a
|
||||
[template engine](../templates/engine.html), see [Build template
|
||||
[template engine](../templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `source_omi_filter` (object) - Filters used to populate the `source_omi` field.
|
||||
|
@ -206,7 +206,7 @@ builder.
|
|||
This will fail unless _exactly_ one OMIS is returned. In the above example,
|
||||
`most_recent` will cause this to succeed by selecting the newest image.
|
||||
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator.html#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator.html#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
|
||||
- `ssh_agent_auth` (boolean) - If true, the local SSH agent will be used to authenticate connections to the source VM. No temporary keypair will be created, and the values of `ssh_password` and `ssh_private_key_file` will be ignored. To use this option with a key pair already configured in the source OMI, leave the `ssh_keypair_name` blank. To associate an existing key pair in Outscale with the source VM, set the `ssh_keypair_name` field to the name of the key pair.
|
||||
|
||||
|
@ -216,7 +216,7 @@ builder.
|
|||
|
||||
- `subnet_id` (string) - If using Net, the ID of the subnet, such as `subnet-12345def`, where Packer will launch the VM. This field is required if you are using an non-default Net.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMIS and relevant snapshots. This is a [template engine](../templates/engine.html), see [Build template data](#build-template-data) for more information.
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMIS and relevant snapshots. This is a [template engine](../templates/engine), see [Build template data](#build-template-data) for more information.
|
||||
|
||||
- `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.
|
||||
|
||||
|
|
|
@ -37,18 +37,18 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale.html#authentication)
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `vm_type` (string) - The Outscale VM type to use while building the OMI, such as `t2.small`.
|
||||
|
||||
- `region` (string) - The name of the region, such as `us-east-1`, in which to launch the Outscale VM to create the OMI.
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale.html#authentication)
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `source_omi` (string) - The initial OMI used as a base for the newly created machine. `source_omi_filter` may be used instead to populate this automatically.
|
||||
|
||||
|
@ -76,7 +76,7 @@ builder.
|
|||
|
||||
- `tags` (map) - Tags to apply to the volume. These are retained after
|
||||
the builder completes. This is a [template
|
||||
engine](/docs/templates/engine.html), see [Build template
|
||||
engine](/docs/templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `associate_public_ip_address` (boolean) - If using a non-default Net, public IP addresses are not provided by default. If this is toggled, your new VM will get a Public IP.
|
||||
|
@ -92,7 +92,7 @@ builder.
|
|||
sometimes desirable to [run Sysprep](<https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-vista/cc721940(v=ws.10)>) which will stop the VM for you. If this is set to `true`, Packer
|
||||
_will not_ stop the VM but will assume that you will send the stop
|
||||
signal yourself through your final provisioner. You can do this with a
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell.html).
|
||||
[windows-shell provisioner](https://www.packer.io/docs/provisioners/windows-shell).
|
||||
|
||||
Note that Packer will still wait for the VM to be stopped, and
|
||||
failing to send the stop signal yourself, when you have set this flag to
|
||||
|
@ -106,7 +106,7 @@ builder.
|
|||
- `run_tags` (object of key/value strings) - Tags to apply to the instance
|
||||
that is _launched_ to create the OMI. These tags are _not_ applied to the
|
||||
resulting OMI unless they're duplicated in `tags`. This is a [template
|
||||
engine](/docs/templates/engine.html), see [Build template
|
||||
engine](/docs/templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `security_group_id` (string) - The ID (_not_ the name) of the security
|
||||
|
@ -161,7 +161,7 @@ builder.
|
|||
This will fail unless _exactly_ one OMIS is returned. In the above example,
|
||||
`most_recent` will cause this to succeed by selecting the newest image.
|
||||
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator.html#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator.html#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
- `ssh_keypair_name` (string) - If specified, this is the key that will be used for SSH with the machine. The key must match a key pair name loaded up into Outscale. By default, this is blank, and Packer will generate a temporary keypair unless [`ssh_password`](../templates/communicator#ssh_password) is used. [`ssh_private_key_file`](../templates/communicator#ssh_private_key_file) or `ssh_agent_auth` must be specified when `ssh_keypair_name` is utilized.
|
||||
|
||||
- `ssh_interface` (string) - One of `public_ip`, `private_ip`, `public_dns`, or `private_dns`. If set, either the public IP address, private IP address, public DNS name or private DNS name will used as the host for SSH. The default behaviour if inside a Net is to use the public IP address if available, otherwise the private IP address will be used. If not in a Net the public DNS name will be used. Also works for WinRM.
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ the extra fast build.
|
|||
|
||||
~> **This is an advanced builder** If you're just getting started with
|
||||
Packer, we recommend starting with the [osc-bsu
|
||||
builder](/docs/builders/osc-bsu.html), which is much easier to use.
|
||||
builder](/docs/builders/osc-bsu), which is much easier to use.
|
||||
|
||||
The builder does _not_ manage OMIs. Once it creates an OMI and stores it in
|
||||
your account, it is up to you to use, delete, etc., the OMI.
|
||||
|
@ -62,18 +62,18 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
### Required:
|
||||
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale.html#authentication)
|
||||
- `access_key` (string) - The access key used to communicate with OUTSCALE. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine.html) for more info).
|
||||
- `omi_name` (string) - The name of the resulting OMIS that will appear when managing OMIs in the Outscale console or via APIs. This must be unique. To help make this unique, use a function like `timestamp` (see [template engine](../templates/engine) for more info).
|
||||
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale.html#authentication)
|
||||
- `secret_key` (string) - The secret key used to communicate with Outscale. [Learn how to set this](outscale#authentication)
|
||||
|
||||
- `source_omi` (string) - The initial OMI used as a base for the newly created machine. `source_omi_filter` may be used instead to populate this automatically.
|
||||
|
||||
### Optional:
|
||||
|
||||
- `omi_description` (string) - The description to set for the resulting OMI(s).
|
||||
By default this description is empty. This is a [template engine](../templates/engine.html),
|
||||
By default this description is empty. This is a [template engine](../templates/engine),
|
||||
see [Build template data](#build-template-data) for more information.
|
||||
|
||||
- `omi_account_ids` (array of strings) - A list of account IDs that have access to launch the resulting OMI(s). By default no additional users other than the user creating the OMIS has permissions to launch it.
|
||||
|
@ -195,7 +195,7 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
- `root_volume_tags` (object of key/value strings) - Tags to apply to the
|
||||
volumes that are _launched_. This is a [template
|
||||
engine](/docs/templates/engine.html), see [Build template
|
||||
engine](/docs/templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `skip_region_validation` (boolean) - Set to true if you want to skip
|
||||
|
@ -203,7 +203,7 @@ each category, the available configuration keys are alphabetized.
|
|||
|
||||
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
|
||||
They will override OMI tags if already applied to snapshot. This is a
|
||||
[template engine](/docs/templates/engine.html), see [Build template
|
||||
[template engine](/docs/templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
- `snapshot_groups` (array of strings) - A list of groups that have access to
|
||||
|
@ -247,7 +247,7 @@ each category, the available configuration keys are alphabetized.
|
|||
filter, but will cause Packer to fail if the `source_omi` does not exist.
|
||||
|
||||
- `tags` (object of key/value strings) - Tags applied to the OMI. This is a
|
||||
[template engine](/docs/templates/engine.html), see [Build template
|
||||
[template engine](/docs/templates/engine), see [Build template
|
||||
data](#build-template-data) for more information.
|
||||
|
||||
## Basic Example
|
||||
|
|
|
@ -16,30 +16,30 @@ Packer is able to create Outscale OMIs. To achieve this, Packer comes with
|
|||
multiple builders depending on the strategy you want to use to build the OMI.
|
||||
Packer supports the following builders at the moment:
|
||||
|
||||
- [osc-bsu](/docs/builders/osc-bsu.html) - Create BSU-backed OMIs by
|
||||
- [osc-bsu](/docs/builders/osc-bsu) - Create BSU-backed OMIs by
|
||||
launching a source OMI and re-packaging it into a new OMI after
|
||||
provisioning. If in doubt, use this builder, which is the easiest to get
|
||||
started with.
|
||||
|
||||
- [osc-chroot](/docs/builders/osc-chroot.html) - Create EBS-backed OMIs
|
||||
- [osc-chroot](/docs/builders/osc-chroot) - Create EBS-backed OMIs
|
||||
from an existing OUTSCALE VM by mounting the root device and using a
|
||||
[Chroot](https://en.wikipedia.org/wiki/Chroot) environment to provision
|
||||
that device. This is an **advanced builder and should not be used by
|
||||
newcomers**. However, it is also the fastest way to build an EBS-backed OMI
|
||||
since no new OUTSCALE VM needs to be launched.
|
||||
|
||||
- [osc-bsusurrogate](/docs/builders/osc-bsusurrogate.html) - Create BSU-backed OMIs from scratch. Works similarly to the `chroot` builder but does
|
||||
- [osc-bsusurrogate](/docs/builders/osc-bsusurrogate) - Create BSU-backed OMIs from scratch. Works similarly to the `chroot` builder but does
|
||||
not require running in Outscale VM. This is an **advanced builder and should not be
|
||||
used by newcomers**.
|
||||
|
||||
-> **Don't know which builder to use?** If in doubt, use the [osc-bsu
|
||||
builder](/docs/builders/osc-bsu.html). It is much easier to use and Outscale generally recommends BSU-backed images nowadays.
|
||||
builder](/docs/builders/osc-bsu). It is much easier to use and Outscale generally recommends BSU-backed images nowadays.
|
||||
|
||||
# Outscale BSU Volume Builder
|
||||
|
||||
Packer is able to create Outscale BSU Volumes which are preinitialized with a filesystem and data.
|
||||
|
||||
- [osc-bsuvolume](/docs/builders/osc-bsuvolume.html) - Create EBS volumes by launching a source OMI with block devices mapped. Provision the VM, then destroy it, retaining the EBS volumes.
|
||||
- [osc-bsuvolume](/docs/builders/osc-bsuvolume) - Create EBS volumes by launching a source OMI with block devices mapped. Provision the VM, then destroy it, retaining the EBS volumes.
|
||||
|
||||
## Authentication
|
||||
|
||||
|
|
|
@ -18,12 +18,12 @@ Packer actually comes with multiple builders able to create Parallels machines,
|
|||
depending on the strategy you want to use to build the image. Packer supports
|
||||
the following Parallels builders:
|
||||
|
||||
- [parallels-iso](/docs/builders/parallels-iso.html) - Starts from an ISO
|
||||
- [parallels-iso](/docs/builders/parallels-iso) - Starts from an ISO
|
||||
file, creates a brand new Parallels VM, installs an OS, provisions software
|
||||
within the OS, then exports that machine to create an image. This is best
|
||||
for people who want to start from scratch.
|
||||
|
||||
- [parallels-pvm](/docs/builders/parallels-pvm.html) - This builder imports
|
||||
- [parallels-pvm](/docs/builders/parallels-pvm) - This builder imports
|
||||
an existing PVM file, runs provisioners on top of that VM, and exports that
|
||||
machine to create an image. This is best if you have an existing Parallels
|
||||
VM export you want to use as the source. As an additional benefit, you can
|
||||
|
|
|
@ -55,7 +55,7 @@ are organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
## ISO Configuration Reference
|
||||
|
@ -171,7 +171,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/engine.html) that has a single
|
||||
template](/docs/templates/engine) 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.
|
||||
|
@ -190,7 +190,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/engine.html), where the `Name`
|
||||
template](/docs/templates/engine), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use `prlctl`
|
||||
are below.
|
||||
|
||||
|
@ -241,7 +241,7 @@ all typed in sequence. It is an array only to improve readability within the
|
|||
template.
|
||||
|
||||
The boot command is "typed" character for character (using the Parallels
|
||||
Virtualization SDK, see [Parallels Builder](/docs/builders/parallels.html))
|
||||
Virtualization SDK, see [Parallels Builder](/docs/builders/parallels))
|
||||
simulating a human actually typing the keyboard.
|
||||
|
||||
@include 'builders/boot-command.mdx'
|
||||
|
@ -264,7 +264,7 @@ Ubuntu 12.04 installer:
|
|||
```
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## prlctl Commands
|
||||
|
||||
|
@ -292,6 +292,6 @@ executed in the order defined. So in the above example, 3d acceleration will be
|
|||
first, followed by the command which enables the adaptive hypervisor.
|
||||
|
||||
Each command itself is an array of strings, where each string is an argument to
|
||||
`prlctl`. Each argument is treated as a [template engine](/docs/templates/engine.html). The only available
|
||||
`prlctl`. Each argument is treated as a [template engine](/docs/templates/engine). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many `prlctl` calls.
|
||||
|
|
|
@ -52,7 +52,7 @@ are organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -111,7 +111,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/engine.html) that has a single
|
||||
template](/docs/templates/engine) 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.
|
||||
|
@ -130,7 +130,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/engine.html), where the `Name`
|
||||
template](/docs/templates/engine), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use `prlctl`
|
||||
are below.
|
||||
|
||||
|
@ -186,7 +186,7 @@ all typed in sequence. It is an array only to improve readability within the
|
|||
template.
|
||||
|
||||
The boot command is "typed" character for character (using the Parallels
|
||||
Virtualization SDK, see [Parallels Builder](/docs/builders/parallels.html))
|
||||
Virtualization SDK, see [Parallels Builder](/docs/builders/parallels))
|
||||
simulating a human actually typing the keyboard.
|
||||
|
||||
@include 'builders/boot-command.mdx'
|
||||
|
@ -218,6 +218,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/engine.html). The only available
|
||||
template](/docs/templates/engine). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many `prlctl` calls.
|
||||
|
|
|
@ -20,7 +20,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required
|
||||
|
|
|
@ -30,7 +30,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -60,7 +60,7 @@ This is an example only, and will time out waiting for SSH because we have not
|
|||
provided a kickstart file. You must add a valid kickstart file to the
|
||||
"http_directory" and then provide the file in the "boot_command" in order for
|
||||
this build to run. We recommend you check out the
|
||||
[Community Templates](https://www.packer.io/community-tools.html#templates)
|
||||
[Community Templates](/community-tools#templates)
|
||||
for a practical usage example.
|
||||
|
||||
Note that you will need to set `"headless": true` if you are running Packer
|
||||
|
|
|
@ -36,7 +36,7 @@ segmented below into two categories: required and optional parameters. Within
|
|||
each category, the available configuration keys are alphabetized.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -19,7 +19,7 @@ customized images based on an existing base images.
|
|||
|
||||
The following configuration options are available for building Tencentcloud images.
|
||||
In addition to the options listed here,
|
||||
a [communicator](/docs/templates/communicator.html) can be configured for this builder.
|
||||
a [communicator](/docs/templates/communicator) can be configured for this builder.
|
||||
|
||||
### Required:
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ There are many configuration options available for the builder. They are
|
|||
segmented below into two categories: required and optional parameters.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -24,7 +24,7 @@ The following configuration options are available for building UCloud images. Th
|
|||
segmented below into two categories: required and optional parameters.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](../templates/communicator.html) can be configured for this
|
||||
[communicator](../templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
~> **Note:** The builder doesn't support Windows images for now and only supports CentOS and Ubuntu images via SSH authentication with `ssh_username` (Required) and `ssh_password` (Optional). The `ssh_username` must be `root` for CentOS images and `ubuntu` for Ubuntu images. The `ssh_password` may contain 8-30 characters, and must consist of at least 2 items out of the capital letters, lower case letters, numbers and special characters. The special characters include `()~!@#\$%^&\*-+=\_|{}\[]:;'<>,.?/`.
|
||||
|
@ -61,7 +61,7 @@ builder.
|
|||
|
||||
- `security_group_id` - (string) The ID of the fire wall associated to UHost instance. If `security_group_id` is not defined,
|
||||
the instance will use the non-recommended web fire wall, and open port include 22, 3389 by default. It is supported by ICMP fire wall protocols.
|
||||
You may refer to [security group_id](https://docs.ucloud.cn/network/firewall/firewall.html).
|
||||
You may refer to [security group_id](https://docs.ucloud.cn/network/firewall/firewall).
|
||||
|
||||
- `image_description` (string) - The description of the image.
|
||||
|
||||
|
|
|
@ -69,7 +69,7 @@ the Compress post-processor will not work with this builder.
|
|||
to Vagrant, this is the name to give it. If left blank, will default to
|
||||
"packer\_" plus your buildname.
|
||||
|
||||
- `provider` (string) - The vagrant [provider](docs/post-processors/vagrant.html).
|
||||
- `provider` (string) - The vagrant [provider](docs/post-processors/vagrant).
|
||||
This parameter is required when `source_path` have more than one provider,
|
||||
or when using `vagrant-cloud` post-processor. Defaults to unset.
|
||||
|
||||
|
|
|
@ -20,19 +20,19 @@ Packer actually comes with multiple builders able to create VirtualBox
|
|||
machines, depending on the strategy you want to use to build the image. Packer
|
||||
supports the following VirtualBox builders:
|
||||
|
||||
- [virtualbox-iso](/docs/builders/virtualbox-iso.html) - Starts from an ISO
|
||||
- [virtualbox-iso](/docs/builders/virtualbox-iso) - Starts from an ISO
|
||||
file, creates a brand new VirtualBox VM, installs an OS, provisions
|
||||
software within the OS, then exports that machine to create an image. This
|
||||
is best for people who want to start from scratch.
|
||||
|
||||
- [virtualbox-ovf](/docs/builders/virtualbox-ovf.html) - This builder imports
|
||||
- [virtualbox-ovf](/docs/builders/virtualbox-ovf) - This builder imports
|
||||
an existing OVF/OVA file, runs provisioners on top of that VM, and exports
|
||||
that machine to create an image. This is best if you have an existing
|
||||
VirtualBox VM export you want to use as the source. As an additional
|
||||
benefit, you can feed the artifact of this builder back into itself to
|
||||
iterate on a machine.
|
||||
|
||||
- [virtualbox-vm](/docs/builders/virtualbox-vm.html) - This builder uses an
|
||||
- [virtualbox-vm](/docs/builders/virtualbox-vm) - This builder uses an
|
||||
existing VM to run defined provisioners on top of that VM, and optionally
|
||||
creates a snapshot to save the changes applied from the provisioners. In
|
||||
addition the builder is able to export that machine to create an image. The
|
||||
|
|
|
@ -204,7 +204,7 @@ above (`{{ .HTTPIP }}`) is hardcoded to 10.0.2.2. If you change the network
|
|||
of your VM you must guarantee that you can still access this HTTP server.
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## Guest Additions
|
||||
|
||||
|
@ -244,7 +244,7 @@ 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/engine.html). The only available
|
||||
template](/docs/templates/engine). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many VBoxManage calls.
|
||||
|
||||
|
|
|
@ -190,7 +190,7 @@ Ubuntu 12.04 installer:
|
|||
```
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## Guest Additions
|
||||
|
||||
|
@ -234,6 +234,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/engine.html). The only available
|
||||
template](/docs/templates/engine). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many VBoxManage calls.
|
||||
|
|
|
@ -61,7 +61,7 @@ are organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
### Required:
|
||||
|
@ -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/engine.html) where the `Version`
|
||||
template](/docs/templates/engine) where the `Version`
|
||||
variable is replaced with the VirtualBox version.
|
||||
|
||||
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest
|
||||
|
@ -247,7 +247,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/engine.html), where the `Name`
|
||||
template](/docs/templates/engine), where the `Name`
|
||||
variable is replaced with the VM name. More details on how to use
|
||||
`VBoxManage` are below.
|
||||
|
||||
|
@ -333,7 +333,7 @@ above (`{{ .HTTPIP }}`) is hardcoded to 10.0.2.2. If you change the network
|
|||
of your VM you must guarantee that you can still access this HTTP server.
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## Guest Additions
|
||||
|
||||
|
@ -373,6 +373,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/engine.html). The only available
|
||||
template](/docs/templates/engine). The only available
|
||||
variable is `Name` which is replaced with the unique name of the VM, which is
|
||||
required for many VBoxManage calls.
|
||||
|
|
|
@ -17,24 +17,24 @@ Packer actually comes with multiple builders able to create VMware machines,
|
|||
depending on the strategy you want to use to build the image. Packer supports
|
||||
the following VMware builders:
|
||||
|
||||
- [vmware-iso](/docs/builders/vmware-iso.html) - Starts from an ISO file,
|
||||
- [vmware-iso](/docs/builders/vmware-iso) - Starts from an ISO file,
|
||||
creates a brand new VMware VM, installs an OS, provisions software within
|
||||
the OS, then exports that machine to create an image. This is best for
|
||||
people who want to start from scratch.
|
||||
|
||||
- [vmware-vmx](/docs/builders/vmware-vmx.html) - This builder imports an
|
||||
- [vmware-vmx](/docs/builders/vmware-vmx) - This builder imports an
|
||||
existing VMware machine (from a VMX file), runs provisioners on top of that
|
||||
VM, and exports that machine to create an image. This is best if you have
|
||||
an existing VMware VM you want to use as the source. As an additional
|
||||
benefit, you can feed the artifact of this builder back into Packer to
|
||||
iterate on a machine.
|
||||
|
||||
- [vsphere-iso](/docs/builders/vsphere-iso.html) - This builder starts from an
|
||||
- [vsphere-iso](/docs/builders/vsphere-iso) - This builder starts from an
|
||||
ISO file, but utilizes the vSphere API rather than the esxcli to build on a
|
||||
remote esx instance. This allows you to build vms even if you do not have
|
||||
SSH access to your vSphere cluster.
|
||||
|
||||
- [vsphere-clone](/docs/builders/vsphere-clone.html) - This builder clones a
|
||||
- [vsphere-clone](/docs/builders/vsphere-clone) - This builder clones a
|
||||
vm from an existing template, then modifies it and saves it as a new
|
||||
template. It uses the vSphere API rather than the esxcli to build on a
|
||||
remote esx instance. This allows you to build vms even if you do not have
|
||||
|
|
|
@ -183,7 +183,7 @@ to modify the network configuration after the VM is done building.
|
|||
@include 'common/bootcommand/BootConfig-not-required.mdx'
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
## VMX Template
|
||||
|
||||
|
|
|
@ -52,7 +52,7 @@ organized below into two categories: required and optional. Within each
|
|||
category, the available options are alphabetized and described.
|
||||
|
||||
In addition to the options listed here, a
|
||||
[communicator](/docs/templates/communicator.html) can be configured for this
|
||||
[communicator](/docs/templates/communicator) can be configured for this
|
||||
builder.
|
||||
|
||||
## Configuration Reference
|
||||
|
@ -170,7 +170,7 @@ to modify the network configuration after the VM is done building.
|
|||
@include 'common/bootcommand/BootConfig-not-required.mdx'
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
```
|
||||
{
|
||||
|
@ -202,6 +202,6 @@ Ubuntu 12.04 installer:
|
|||
```
|
||||
|
||||
For more examples of various boot commands, see the sample projects from our
|
||||
[community templates page](/community-tools.html#templates).
|
||||
[community templates page](/community-tools#templates).
|
||||
|
||||
@include 'builders/building_on_remote_vsphere_hypervisor.mdx'
|
||||
|
|
|
@ -16,7 +16,7 @@ Type: `vsphere-clone`
|
|||
This builder clones VMs from existing templates.
|
||||
|
||||
- VMware Player is not required.
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](https://www.packer.io/docs/builders/vmware-iso.html#building-on-a-remote-vsphere-hypervisor)
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](/docs/builders/vmware-iso#building-on-a-remote-vsphere-hypervisor)
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -18,7 +18,7 @@ This builder uses the vSphere API, and creates virtual machines remotely. It
|
|||
starts from an ISO file and creates new VMs from scratch.
|
||||
|
||||
- VMware Player is not required.
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](https://www.packer.io/docs/builders/vmware-iso.html#building-on-a-remote-vsphere-hypervisor)
|
||||
- It uses the official vCenter API, and does not require ESXi host [modification](/docs/builders/vmware-iso#building-on-a-remote-vsphere-hypervisor)
|
||||
|
||||
## Examples
|
||||
|
||||
|
|
|
@ -53,7 +53,7 @@ Configuration options are organized below into two categories: required and
|
|||
optional. Within each category, the available options are alphabetized and
|
||||
described.
|
||||
|
||||
In addition to the options listed here, a [communicator](/docs/templates/communicator.html)
|
||||
In addition to the options listed here, a [communicator](/docs/templates/communicator)
|
||||
can be configured for this builder.
|
||||
|
||||
### Required:
|
||||
|
|
|
@ -14,16 +14,16 @@ Communicators are the mechanism Packer uses to upload files, execute scripts,
|
|||
etc. with the machine being created.
|
||||
|
||||
Communicators are configured within the
|
||||
[builder](/docs/templates/builders.html) section. Packer currently supports
|
||||
[builder](/docs/templates/builders) section. Packer currently supports
|
||||
three kinds of communicators:
|
||||
|
||||
- `none` - No communicator will be used. If this is set, most provisioners
|
||||
also can't be used.
|
||||
|
||||
- [ssh](/docs/communicators/ssh.html) - An SSH connection will be established to the machine. This is
|
||||
- [ssh](/docs/communicators/ssh) - An SSH connection will be established to the machine. This is
|
||||
usually the default.
|
||||
|
||||
- [winrm](/docs/communicators/winrm.html) - A WinRM connection will be established.
|
||||
- [winrm](/docs/communicators/winrm) - A WinRM connection will be established.
|
||||
|
||||
In addition to the above, some builders have custom communicators they can use.
|
||||
For example, the Docker builder has a "docker" communicator that uses
|
||||
|
|
|
@ -12,7 +12,7 @@ sidebar_current: 'docs-communicators-ssh'
|
|||
|
||||
Communicators are the mechanism Packer uses to upload files, execute scripts,
|
||||
etc. on the machine being created, and ar configured within the
|
||||
[builder](/docs/templates/builders.html) section.
|
||||
[builder](/docs/templates/builders) section.
|
||||
|
||||
The SSH communicator does this by using the SSH protocol. It is the default
|
||||
communicator for a majority of builders.
|
||||
|
@ -34,7 +34,7 @@ the Packer template.
|
|||
However, if you are building from a brand-new and unconfigured operating system
|
||||
image, you will almost always have to perform some extra work to configure SSH
|
||||
on the guest machine. For most operating system distributions, this work will
|
||||
be performed by a [boot command](/docs/builders/vmware-iso.html#boot-configuration)
|
||||
be performed by a [boot command](/docs/builders/vmware-iso#boot-configuration)
|
||||
that references a file which provides answers to the normally-interactive
|
||||
questions you get asked when installing an operating system. The name of this
|
||||
file varies by operating system; some common examples are the "preseed" file
|
||||
|
|
|
@ -185,10 +185,10 @@ provisioning step to make sure your image is secure.
|
|||
|
||||
Most clouds allow you to provide a configuration script that runs when the
|
||||
instance is launched. In AWS, this is the
|
||||
[user_data_file](/docs/builders/amazon-ebs.html#user_data_file). In Google
|
||||
[user_data_file](/docs/builders/amazon-ebs#user_data_file). In Google
|
||||
Cloud, this is provided using the `windows-startup-script-cmd`
|
||||
[metadata](/docs/builders/googlecompute.html#metadata) tag.
|
||||
[Example](/docs/builders/googlecompute.html#windows-example)
|
||||
[metadata](/docs/builders/googlecompute#metadata) tag.
|
||||
[Example](/docs/builders/googlecompute#windows-example)
|
||||
|
||||
Essentially, these files are powershell or cmd scripts that configure winrm,
|
||||
without having to be wrapped in an Autounattend. Provide the script in the
|
||||
|
|
|
@ -46,4 +46,4 @@ configuration file. None of these are required, since all have sane defaults.
|
|||
- `builders`, `commands`, `post-processors`, and `provisioners` are objects
|
||||
that are used to install plugins. The details of how exactly these are set
|
||||
is covered in more detail in the [installing plugins documentation
|
||||
page](/docs/extending/plugins.html).
|
||||
page](/docs/extending/plugins).
|
||||
|
|
|
@ -15,17 +15,17 @@ each can be found below:
|
|||
|
||||
- `PACKER_CONFIG` - The location of the core configuration file. The format
|
||||
of the configuration file is basic JSON. See the [core configuration
|
||||
page](/docs/other/core-configuration.html).
|
||||
page](/docs/other/core-configuration).
|
||||
|
||||
- `PACKER_CONFIG_DIR` - The location of the `.packer.d` config directory
|
||||
|
||||
- `PACKER_LOG` - Setting this to any value other than "" (empty string) or
|
||||
"0" will enable the logger. See the [debugging
|
||||
page](/docs/other/debugging.html).
|
||||
page](/docs/other/debugging).
|
||||
|
||||
- `PACKER_LOG_PATH` - The location of the log file. Note: `PACKER_LOG` must
|
||||
be set for any logging to occur. See the [debugging
|
||||
page](/docs/other/debugging.html).
|
||||
page](/docs/other/debugging).
|
||||
|
||||
- `PACKER_NO_COLOR` - Setting this to any value will disable color in the
|
||||
terminal.
|
||||
|
@ -33,12 +33,12 @@ each can be found below:
|
|||
- `PACKER_PLUGIN_MAX_PORT` - The maximum port that Packer uses for
|
||||
communication with plugins, since plugin communication happens over TCP
|
||||
connections on your local host. The default is 25,000. See the [core
|
||||
configuration page](/docs/other/core-configuration.html).
|
||||
configuration page](/docs/other/core-configuration).
|
||||
|
||||
- `PACKER_PLUGIN_MIN_PORT` - The minimum port that Packer uses for
|
||||
communication with plugins, since plugin communication happens over TCP
|
||||
connections on your local host. The default is 10,000. See the [core
|
||||
configuration page](/docs/other/core-configuration.html).
|
||||
configuration page](/docs/other/core-configuration).
|
||||
|
||||
- `PACKER_PLUGIN_PATH` - a PATH variable for finding third-party packer
|
||||
plugins. For example: `~/custom-dir-1:~/custom-dir-2`.
|
||||
|
|
|
@ -18,7 +18,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/plugins.html).
|
||||
development basics](/docs/extending/plugins).
|
||||
|
||||
~> **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.
|
||||
|
@ -256,4 +256,4 @@ func (p *PostProcessor) PostProcess(ctx context.Context, ui packer.Ui, source pa
|
|||
}
|
||||
```
|
||||
|
||||
To know more about the template engine build function, please refer to the [template engine docs](/docs/templates/engine.html).
|
||||
To know more about the template engine build function, please refer to the [template engine docs](/docs/templates/engine).
|
||||
|
|
|
@ -22,7 +22,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/plugins.html).
|
||||
development basics](/docs/extending/plugins).
|
||||
|
||||
Post-processor plugins implement the `packer.PostProcessor` interface and are
|
||||
served using the `plugin.ServePostProcessor` function.
|
||||
|
|
|
@ -19,11 +19,11 @@ sidebar_current: docs-extending-custom-provisioners
|
|||
Packer Provisioners are the components of Packer that install and configure
|
||||
software into a running machine prior to turning that machine into an image. An
|
||||
example of a provisioner is the [shell
|
||||
provisioner](/docs/provisioners/shell.html), which runs shell scripts within
|
||||
provisioner](/docs/provisioners/shell), 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/plugins.html).
|
||||
development basics](/docs/extending/plugins).
|
||||
|
||||
Provisioner plugins implement the `packer.Provisioner` interface and are served
|
||||
using the `plugin.ServeProvisioner` function.
|
||||
|
|
|
@ -23,7 +23,7 @@ developing plugins, the documentation for that is available below, in the
|
|||
[developing plugins](#developing-plugins) section.
|
||||
|
||||
The current official listing of available Packer plugins can be found
|
||||
[here](/community-tools.html#third-party-plugins). This is an incomplete list,
|
||||
[here](/community-tools#third-party-plugins). This is an incomplete list,
|
||||
and more plugins can be found by searching. Typically, searching "packer plugin
|
||||
_x_" will find what you're looking for if it exists. We hope to create an
|
||||
offical registry for third party plugins in the future.
|
||||
|
@ -86,7 +86,7 @@ The valid types for plugins are:
|
|||
|
||||
This page will document how you can develop your own Packer plugins. Prior to
|
||||
reading this, it is assumed that you're comfortable with Packer and also know
|
||||
the [basics of how Plugins work](/docs/extending/plugins.html), from a user
|
||||
the [basics of how Plugins work](/docs/extending/plugins), from a user
|
||||
standpoint.
|
||||
|
||||
Packer plugins must be written in [Go](https://golang.org/), so it is also
|
||||
|
|
|
@ -125,7 +125,7 @@ types described above:
|
|||
|
||||
Key/value pairs can be separated by either a comma or a line break. Values
|
||||
can be arbitrary expressions. Keys are strings; they can be left unquoted if
|
||||
they are a valid [identifier](./syntax.html#identifiers), but must be quoted
|
||||
they are a valid [identifier](./syntax#identifiers), but must be quoted
|
||||
otherwise. You can use a non-literal expression as a key by wrapping it in
|
||||
parentheses, like `(var.business_unit_tag_name) = "SRE"`.
|
||||
|
||||
|
@ -136,13 +136,13 @@ Packer makes one named values available.
|
|||
The following named values are available:
|
||||
|
||||
- `source.<SOURCE TYPE>.<NAME>` is an object representing a
|
||||
[source](./sources.html) of the given type
|
||||
[source](./sources) of the given type
|
||||
and name.
|
||||
|
||||
### Available Functions
|
||||
|
||||
For a full list of available functions, see [the function
|
||||
reference](/docs/configuration/from-1.5/functions.html).
|
||||
reference](/docs/configuration/from-1.5/functions).
|
||||
|
||||
## `for` Expressions
|
||||
|
||||
|
@ -235,7 +235,7 @@ The above expression is equivalent to the following `for` expression:
|
|||
|
||||
Splat expressions are for lists only (and thus cannot be used [to reference
|
||||
resources created with
|
||||
`for_each`](/docs/configuration/resources.html#referring-to-instances-1), which
|
||||
`for_each`](/docs/configuration/resources#referring-to-instances-1), which
|
||||
are represented as maps). However, if a splat expression is applied to a value
|
||||
that is _not_ a list or tuple then the value is automatically wrapped in a
|
||||
single-element list before processing.
|
||||
|
@ -338,8 +338,8 @@ block. If you need to declare resource instances based on a nested data
|
|||
structure or combinations of elements from multiple data structures you can use
|
||||
expressions and functions to derive a suitable value. For some common examples
|
||||
of such situations, see the
|
||||
[`flatten`](/docs/configuration/from-1.5/functions/collection/flatten.html) and
|
||||
[`setproduct`](/docs/configuration/from-1.5/functions/collection/setproduct.html)
|
||||
[`flatten`](/docs/configuration/from-1.5/functions/collection/flatten) and
|
||||
[`setproduct`](/docs/configuration/from-1.5/functions/collection/setproduct)
|
||||
functions.
|
||||
|
||||
### Best Practices for `dynamic` Blocks
|
||||
|
|
|
@ -34,5 +34,5 @@ b
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`coalescelist`](./coalescelist.html) performs a similar operation with
|
||||
- [`coalescelist`](./coalescelist) performs a similar operation with
|
||||
list arguments rather than individual arguments.
|
||||
|
|
|
@ -41,5 +41,5 @@ symbol to expand the outer list as arguments:
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`coalesce`](./coalesce.html) performs a similar operation with string
|
||||
- [`coalesce`](./coalesce) performs a similar operation with string
|
||||
arguments rather than list arguments.
|
||||
|
|
|
@ -31,9 +31,9 @@ Indirectly-nested lists, such as those in maps, are _not_ flattened.
|
|||
## Flattening nested structures for `for_each`
|
||||
|
||||
The
|
||||
[resource `for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[resource `for_each`](/docs/configuration/resources#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
and
|
||||
[`dynamic` block](/docs/configuration/expressions.html#dynamic-blocks)
|
||||
[`dynamic` block](/docs/configuration/expressions#dynamic-blocks)
|
||||
language features both require a collection value that has one element for
|
||||
each repetition.
|
||||
|
||||
|
@ -106,6 +106,6 @@ the associations between the subnets and their containing networks.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`setproduct`](./setproduct.html) finds all of the combinations of multiple
|
||||
- [`setproduct`](./setproduct) finds all of the combinations of multiple
|
||||
lists or sets of values, which can also be useful when preparing collections
|
||||
for use with `for_each` constructs.
|
||||
|
|
|
@ -26,5 +26,5 @@ value is not present in the list.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`element`](./element.html) retrieves a particular element from a list given
|
||||
- [`element`](./element) retrieves a particular element from a list given
|
||||
its index.
|
||||
|
|
|
@ -26,4 +26,4 @@ be identical as long as the keys in the map don't change.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`values`](./values.html) returns a list of the _values_ from a map.
|
||||
- [`values`](./values) returns a list of the _values_ from a map.
|
||||
|
|
|
@ -30,4 +30,4 @@ what?
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`element`](./element.html) retrieves a value from a _list_ given its _index_.
|
||||
- [`element`](./element) retrieves a value from a _list_ given its _index_.
|
||||
|
|
|
@ -24,4 +24,4 @@ with all of the same elements as the given sequence but in reverse order.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`strrev`](../string/strrev.html) reverses a string.
|
||||
- [`strrev`](../string/strrev) reverses a string.
|
||||
|
|
|
@ -33,9 +33,9 @@ the ordering of the given elements is not preserved.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`contains`](./contains.html) tests whether a given list or set contains
|
||||
- [`contains`](./contains) tests whether a given list or set contains
|
||||
a given element value.
|
||||
- [`setproduct`](./setproduct.html) computes the _Cartesian product_ of multiple
|
||||
- [`setproduct`](./setproduct) computes the _Cartesian product_ of multiple
|
||||
sets.
|
||||
- [`setunion`](./setunion.html) computes the _union_ of
|
||||
- [`setunion`](./setunion) computes the _union_ of
|
||||
multiple sets.
|
||||
|
|
|
@ -118,9 +118,9 @@ elements all have a consistent type:
|
|||
## Finding combinations for `for_each`
|
||||
|
||||
The
|
||||
[resource `for_each`](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[resource `for_each`](/docs/configuration/resources#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
and
|
||||
[`dynamic` block](/docs/configuration/expressions.html#dynamic-blocks)
|
||||
[`dynamic` block](/docs/configuration/expressions#dynamic-blocks)
|
||||
language features both require a collection value that has one element for
|
||||
each repetition.
|
||||
|
||||
|
@ -214,12 +214,12 @@ elements in the input variables.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`contains`](./contains.html) tests whether a given list or set contains
|
||||
- [`contains`](./contains) tests whether a given list or set contains
|
||||
a given element value.
|
||||
- [`flatten`](./flatten.html) is useful for flattening heirarchical data
|
||||
- [`flatten`](./flatten) is useful for flattening heirarchical data
|
||||
into a single list, for situations where the relationships between two
|
||||
object types are defined explicitly.
|
||||
- [`setintersection`](./setintersection.html) computes the _intersection_ of
|
||||
- [`setintersection`](./setintersection) computes the _intersection_ of
|
||||
multiple sets.
|
||||
- [`setunion`](./setunion.html) computes the _union_ of multiple
|
||||
- [`setunion`](./setunion) computes the _union_ of multiple
|
||||
sets.
|
||||
|
|
|
@ -36,9 +36,9 @@ the ordering of the given elements is not preserved.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`contains`](./contains.html) tests whether a given list or set contains
|
||||
- [`contains`](./contains) tests whether a given list or set contains
|
||||
a given element value.
|
||||
- [`setintersection`](./setintersection.html) computes the _intersection_ of
|
||||
- [`setintersection`](./setintersection) computes the _intersection_ of
|
||||
multiple sets.
|
||||
- [`setproduct`](./setproduct.html) computes the _Cartesian product_ of multiple
|
||||
- [`setproduct`](./setproduct) computes the _Cartesian product_ of multiple
|
||||
sets.
|
||||
|
|
|
@ -30,5 +30,5 @@ list.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`substr`](../string/substr.html) performs a similar function for characters in a
|
||||
- [`substr`](../string/substr) performs a similar function for characters in a
|
||||
string, although it uses a length instead of an end index.
|
||||
|
|
|
@ -13,7 +13,7 @@ in that map.
|
|||
|
||||
The values are returned in lexicographical order by their corresponding _keys_,
|
||||
so the values will be returned in the same order as their keys would be
|
||||
returned from [`keys`](./keys.html).
|
||||
returned from [`keys`](./keys).
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -28,4 +28,4 @@ returned from [`keys`](./keys.html).
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`keys`](./keys.html) returns a list of the _keys_ from a map.
|
||||
- [`keys`](./keys) returns a list of the _keys_ from a map.
|
||||
|
|
|
@ -15,7 +15,7 @@ whether the expression produced a result without any errors.
|
|||
|
||||
This is a special function that is able to catch errors produced when evaluating
|
||||
its argument. For most situations where you could use `can` it's better to use
|
||||
[`try`](./try.html) instead, because it allows for more concise definition of
|
||||
[`try`](./try) instead, because it allows for more concise definition of
|
||||
fallback values for failing expressions.
|
||||
|
||||
The `can` function can only catch and handle _dynamic_ errors resulting from
|
||||
|
@ -27,7 +27,7 @@ as a malformed resource reference.
|
|||
variable validation rules. Although it can technically accept any sort of
|
||||
expression and be used elsewhere in the configuration, we recommend against
|
||||
using it in other contexts. For error handling elsewhere in the configuration,
|
||||
prefer to use [`try`](./try.html).
|
||||
prefer to use [`try`](./try).
|
||||
|
||||
## Examples
|
||||
|
||||
|
@ -56,5 +56,5 @@ A local value with the name "nonexist" has not been declared.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`try`](./try.html), which tries evaluating a sequence of expressions and
|
||||
- [`try`](./try), which tries evaluating a sequence of expressions and
|
||||
returns the result of the first one that succeeds.
|
||||
|
|
|
@ -110,5 +110,5 @@ A local value with the name "nonexist" has not been declared.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`can`](./can.html), which tries evaluating an expression and returns a
|
||||
- [`can`](./can), which tries evaluating an expression and returns a
|
||||
boolean value indicating whether it succeeded.
|
||||
|
|
|
@ -102,7 +102,7 @@ configuration as needed:
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`format`](../string/format.html) is a more general formatting function for arbitrary
|
||||
- [`format`](../string/format) is a more general formatting function for arbitrary
|
||||
data.
|
||||
- [`timestamp`](./timestamp.html) returns the current date and time in a format
|
||||
- [`timestamp`](./timestamp) returns the current date and time in a format
|
||||
suitable for input to `formatdate`.
|
||||
|
|
|
@ -32,7 +32,7 @@ of adding the given direction to the given timestamp.
|
|||
-> **Breaking change note:** Packer previously let you decide your own "Date
|
||||
and Time format" syntax. With HCL2 and for parity with Terraform, Packer will
|
||||
be using the [RFC 3339](https://tools.ietf.org/html/rfc3339) "Date and Time
|
||||
format" syntax. As a string. [`formatdate`](./formatdate.html) still allows you
|
||||
format" syntax. As a string. [`formatdate`](./formatdate) still allows you
|
||||
to format a date.
|
||||
|
||||
## Examples
|
||||
|
|
|
@ -24,7 +24,7 @@ Packer run.
|
|||
-> **Breaking change note:** Packer previously let you decide your own "Date
|
||||
and Time format" syntax. With HCL2 and for parity with Terraform, Packer will
|
||||
be using the [RFC 3339](https://tools.ietf.org/html/rfc3339) "Date and Time
|
||||
format" syntax. As a string. [`formatdate`](./formatdate.html) still allows you
|
||||
format" syntax. As a string. [`formatdate`](./formatdate) still allows you
|
||||
to format a date.
|
||||
|
||||
## Examples
|
||||
|
@ -36,5 +36,5 @@ to format a date.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`formatdate`](./formatdate.html) can convert the resulting timestamp to
|
||||
- [`formatdate`](./formatdate) can convert the resulting timestamp to
|
||||
other date and time formats.
|
||||
|
|
|
@ -35,7 +35,7 @@ Hello World
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`base64encode`](./base64encode.html) performs the opposite operation,
|
||||
- [`base64encode`](./base64encode) performs the opposite operation,
|
||||
encoding the UTF-8 bytes for a string as Base64.
|
||||
- [`base64gzip`](./base64gzip.html) applies gzip compression to a string
|
||||
- [`base64gzip`](./base64gzip) applies gzip compression to a string
|
||||
and returns the result with Base64 encoding.
|
||||
|
|
|
@ -36,7 +36,7 @@ SGVsbG8gV29ybGQ=
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`base64decode`](./base64decode.html) performs the opposite operation,
|
||||
- [`base64decode`](./base64decode) performs the opposite operation,
|
||||
decoding Base64 data and interpreting it as a UTF-8 string.
|
||||
- [`base64gzip`](./base64gzip.html) applies gzip compression to a string
|
||||
- [`base64gzip`](./base64gzip) applies gzip compression to a string
|
||||
and returns the result with Base64 encoding all in one operation.
|
||||
|
|
|
@ -42,7 +42,7 @@ number of fields, or this function will produce an error.
|
|||
## Use with the `for_each` meta-argument
|
||||
|
||||
You can use the result of `csvdecode` with
|
||||
[the `for_each` meta-argument](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
[the `for_each` meta-argument](/docs/configuration/resources#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings)
|
||||
to describe a collection of similar objects whose differences are
|
||||
described by the rows in the given CSV file.
|
||||
|
||||
|
@ -90,7 +90,7 @@ create or destroy associated instances as appropriate.
|
|||
|
||||
If there is no reasonable value you can use as a unique identifier in your CSV
|
||||
then you could instead use
|
||||
[the `count` meta-argument](/docs/configuration/resources.html#count-multiple-resource-instances-by-count)
|
||||
[the `count` meta-argument](/docs/configuration/resources#count-multiple-resource-instances-by-count)
|
||||
to define an object for each CSV row, with each one identified by its index into
|
||||
the list returned by `csvdecode`. However, in that case any future updates to
|
||||
the CSV may be disruptive if they change the positions of particular objects in
|
||||
|
|
|
@ -16,7 +16,7 @@ of the result of decoding that string.
|
|||
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
|
||||
|
||||
This function maps JSON values to
|
||||
[Packer language values](../expressions.html#types-and-values)
|
||||
[Packer language values](../expressions#types-and-values)
|
||||
in the following way:
|
||||
|
||||
| JSON type | Packer type |
|
||||
|
@ -45,5 +45,5 @@ true
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`jsonencode`](./jsonencode.html) performs the opposite operation, _encoding_
|
||||
- [`jsonencode`](./jsonencode) performs the opposite operation, _encoding_
|
||||
a value as JSON.
|
||||
|
|
|
@ -13,7 +13,7 @@ description: The jsonencode function encodes a given value as a JSON string.
|
|||
The JSON encoding is defined in [RFC 7159](https://tools.ietf.org/html/rfc7159).
|
||||
|
||||
This function maps
|
||||
[Packer language values](../expressions.html#types-and-values)
|
||||
[Packer language values](../expressions#types-and-values)
|
||||
to JSON values in the following way:
|
||||
|
||||
| Packer type | JSON type |
|
||||
|
@ -42,5 +42,5 @@ rarely a problem in practice.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`jsondecode`](./jsondecode.html) performs the opposite operation, _decoding_
|
||||
- [`jsondecode`](./jsondecode) performs the opposite operation, _decoding_
|
||||
a JSON string to obtain its represented value.
|
||||
|
|
|
@ -17,7 +17,7 @@ This function supports a subset of [YAML 1.2](https://yaml.org/spec/1.2/spec.htm
|
|||
as described below.
|
||||
|
||||
This function maps YAML values to
|
||||
[Packer language values](../expressions.html#types-and-values)
|
||||
[Packer language values](../expressions#types-and-values)
|
||||
in the following way:
|
||||
|
||||
| YAML type | Packer type |
|
||||
|
@ -96,7 +96,7 @@ Call to function "yamldecode" failed: unsupported tag "!not-supported".
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`jsondecode`](./jsondecode.html) is a similar operation using JSON instead
|
||||
- [`jsondecode`](./jsondecode) is a similar operation using JSON instead
|
||||
of YAML.
|
||||
- [`yamlencode`](./yamlencode.html) performs the opposite operation, _encoding_
|
||||
- [`yamlencode`](./yamlencode) performs the opposite operation, _encoding_
|
||||
a value as YAML.
|
||||
|
|
|
@ -9,13 +9,13 @@ description: The yamlencode function encodes a given value as a YAML string.
|
|||
# `yamlencode` Function
|
||||
|
||||
`yamlencode` encodes a given value to a string using
|
||||
[YAML 1.2](https://yaml.org/spec/1.2/spec.html) block syntax.
|
||||
[YAML 1.2](https://yaml.org/spec/1.2/spec) block syntax.
|
||||
|
||||
~> **Warning:** This function is currently **experimental** and its exact
|
||||
result format may change in future versions of Packer, based on feedback.
|
||||
Do not use `yamldecode` to construct a value for any resource argument where
|
||||
changes to the result would be disruptive. To get a consistent string
|
||||
representation of a value use [`jsonencode`](./jsonencode.html) instead; its
|
||||
representation of a value use [`jsonencode`](./jsonencode) instead; its
|
||||
results are also valid YAML because YAML is a JSON superset.
|
||||
|
||||
<!--
|
||||
|
@ -29,7 +29,7 @@ results are also valid YAML because YAML is a JSON superset.
|
|||
-->
|
||||
|
||||
This function maps
|
||||
[Packer language values](../expressions.html#types-and-values)
|
||||
[Packer language values](../expressions#types-and-values)
|
||||
to YAML tags in the following way:
|
||||
|
||||
| Packer type | YAML type |
|
||||
|
@ -77,12 +77,12 @@ mean that this is rarely a problem in practice.
|
|||
|
||||
`yamlencode` always uses YAML's "block style" for mappings and sequences, unless
|
||||
the mapping or sequence is empty. To generate flow-style YAML, use
|
||||
[`jsonencode`](./jsonencode.html) instead: YAML flow-style is a superset
|
||||
[`jsonencode`](./jsonencode) instead: YAML flow-style is a superset
|
||||
of JSON syntax.
|
||||
|
||||
## Related Functions
|
||||
|
||||
- [`jsonencode`](./jsonencode.html) is a similar operation using JSON instead
|
||||
- [`jsonencode`](./jsonencode) is a similar operation using JSON instead
|
||||
of YAML.
|
||||
- [`yamldecode`](./yamldecode.html) performs the opposite operation, _decoding_
|
||||
- [`yamldecode`](./yamldecode) performs the opposite operation, _decoding_
|
||||
a YAML string to obtain its represented value.
|
||||
|
|
|
@ -15,7 +15,7 @@ with the current working directory.
|
|||
Referring directly to filesystem paths in resource arguments may cause
|
||||
spurious diffs if the same configuration is applied from multiple systems or on
|
||||
different host operating systems. We recommend using filesystem paths only
|
||||
for transient values, such as the argument to [`file`](./file.html) (where
|
||||
for transient values, such as the argument to [`file`](./file) (where
|
||||
only the contents are then stored) or in `connection` and `provisioner` blocks.
|
||||
|
||||
## Examples
|
||||
|
|
|
@ -27,7 +27,7 @@ it uses backslash `\` as the path segment separator. On Unix systems, the slash
|
|||
Referring directly to filesystem paths in resource arguments may cause
|
||||
spurious diffs if the same configuration is applied from multiple systems or on
|
||||
different host operating systems. We recommend using filesystem paths only
|
||||
for transient values, such as the argument to [`file`](./file.html) (where
|
||||
for transient values, such as the argument to [`file`](./file) (where
|
||||
only the contents are then stored) or in `connection` and `provisioner` blocks.
|
||||
|
||||
## Examples
|
||||
|
@ -39,6 +39,6 @@ baz.txt
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`dirname`](./dirname.html) returns all of the segments of a filesystem path
|
||||
- [`dirname`](./dirname) returns all of the segments of a filesystem path
|
||||
_except_ the last, discarding the portion that would be returned by
|
||||
`basename`.
|
||||
|
|
|
@ -26,7 +26,7 @@ any slashes in the given path will be replaced by backslashes before returning.
|
|||
Referring directly to filesystem paths in resource arguments may cause
|
||||
spurious diffs if the same configuration is applied from multiple systems or on
|
||||
different host operating systems. We recommend using filesystem paths only
|
||||
for transient values, such as the argument to [`file`](./file.html) (where
|
||||
for transient values, such as the argument to [`file`](./file) (where
|
||||
only the contents are then stored) or in `connection` and `provisioner` blocks.
|
||||
|
||||
## Examples
|
||||
|
@ -38,5 +38,5 @@ foo/bar
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`basename`](./basename.html) returns _only_ the last portion of a filesystem
|
||||
- [`basename`](./basename) returns _only_ the last portion of a filesystem
|
||||
path, discarding the portion that would be returned by `dirname`.
|
||||
|
|
|
@ -28,7 +28,7 @@ dependency graph, so this function cannot be used with files that are generated
|
|||
dynamically during a Packer operation. We do not recommend using dynamic
|
||||
local files in Packer configurations, but in rare situations where this is
|
||||
necessary you can use
|
||||
[the `local_file` data source](/docs/providers/local/d/file.html)
|
||||
[the `local_file` data source](/docs/providers/local/d/file)
|
||||
to read files while respecting resource dependencies.
|
||||
|
||||
## Examples
|
||||
|
@ -40,5 +40,5 @@ Hello World
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`fileexists`](./fileexists.html) determines whether a file exists
|
||||
- [`fileexists`](./fileexists) determines whether a file exists
|
||||
at a given path.
|
||||
|
|
|
@ -34,4 +34,4 @@ fileexists("custom-section.sh") ? file("custom-section.sh") : local.default_cont
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`file`](./file.html) reads the contents of a file at a given path
|
||||
- [`file`](./file) reads the contents of a file at a given path
|
||||
|
|
|
@ -65,7 +65,7 @@ before Packer takes any actions.
|
|||
```
|
||||
|
||||
A common use of `fileset` is to create one resource instance per matched file, using
|
||||
[the `for_each` meta-argument](/docs/configuration/resources.html#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
[the `for_each` meta-argument](/docs/configuration/resources#for_each-multiple-resource-instances-defined-by-a-map-or-set-of-strings):
|
||||
|
||||
```hcl
|
||||
resource "example_thing" "example" {
|
||||
|
|
|
@ -20,7 +20,7 @@ max(5, 12, 9)
|
|||
```
|
||||
|
||||
For more details on syntax, see
|
||||
[_Function Calls_](./expressions.html#function-calls)
|
||||
[_Function Calls_](./expressions#function-calls)
|
||||
on the Expressions page.
|
||||
|
||||
The HCL language does not support user-defined functions, and so only
|
||||
|
|
|
@ -24,7 +24,7 @@ cidrhost(prefix, hostnum)
|
|||
no more than the number of digits remaining in the address after the given
|
||||
prefix. For more details on how this function interprets CIDR prefixes and
|
||||
populates host numbers, see the worked example for
|
||||
[`cidrsubnet`](./cidrsubnet.html).
|
||||
[`cidrsubnet`](./cidrsubnet).
|
||||
|
||||
Conventionally host number zero is used to represent the address of the
|
||||
network itself and the host number that would fill all the host bits with
|
||||
|
@ -48,5 +48,5 @@ fd00:fd12:3456:7890::22
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`cidrsubnet`](./cidrsubnet.html) calculates a subnet address under a given
|
||||
- [`cidrsubnet`](./cidrsubnet) calculates a subnet address under a given
|
||||
network address prefix.
|
||||
|
|
|
@ -30,7 +30,7 @@ additional bits added to the prefix.
|
|||
This function accepts both IPv6 and IPv4 prefixes, and the result always uses
|
||||
the same addressing scheme as the given prefix.
|
||||
|
||||
Unlike the related function [`cidrsubnets`](./cidrsubnets.html), `cidrsubnet`
|
||||
Unlike the related function [`cidrsubnets`](./cidrsubnets), `cidrsubnet`
|
||||
allows you to give a specific network number to use. `cidrsubnets` can allocate
|
||||
multiple network addresses at once, but numbers them automatically starting
|
||||
with zero.
|
||||
|
@ -91,7 +91,7 @@ This gives us some additional information but also confirms (using a slightly
|
|||
different notation) the conversion from decimal to binary and shows the range
|
||||
of possible host addresses in this network.
|
||||
|
||||
While [`cidrhost`](./cidrhost.html) allows calculating single host IP addresses,
|
||||
While [`cidrhost`](./cidrhost) allows calculating single host IP addresses,
|
||||
`cidrsubnet` on the other hand creates a new network prefix _within_ the given
|
||||
network prefix. In other words, it creates a subnet.
|
||||
|
||||
|
@ -146,7 +146,7 @@ Hosts/Net: 14 Class A, Private Internet
|
|||
The new subnet has four bits available for host numbering, which means
|
||||
that there are 14 host addresses available for assignment once we subtract
|
||||
the network's own address and the broadcast address. You can thus use
|
||||
[`cidrhost`](./cidrhost.html) function to calculate those host addresses by
|
||||
[`cidrhost`](./cidrhost) function to calculate those host addresses by
|
||||
providing it a value between 1 and 14:
|
||||
|
||||
```shell
|
||||
|
@ -161,9 +161,9 @@ For more information on CIDR notation and subnetting, see
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`cidrhost`](./cidrhost.html) calculates the IP address for a single host
|
||||
- [`cidrhost`](./cidrhost) calculates the IP address for a single host
|
||||
within a given network address prefix.
|
||||
- [`cidrnetmask`](./cidrnetmask.html) converts an IPv4 network prefix in CIDR
|
||||
- [`cidrnetmask`](./cidrnetmask) converts an IPv4 network prefix in CIDR
|
||||
notation into netmask notation.
|
||||
- [`cidrsubnets`](./cidrsubnets.html) can allocate multiple consecutive
|
||||
- [`cidrsubnets`](./cidrsubnets) can allocate multiple consecutive
|
||||
addresses under a prefix at once, numbering them automatically.
|
||||
|
|
|
@ -25,7 +25,7 @@ value is therefore a list with one element per `newbits` argument, each
|
|||
a string containing an address range in CIDR notation.
|
||||
|
||||
For more information on IP addressing concepts, see the documentation for the
|
||||
related function [`cidrsubnet`](./cidrsubnet.html). `cidrsubnet` calculates
|
||||
related function [`cidrsubnet`](./cidrsubnet). `cidrsubnet` calculates
|
||||
a single subnet address within a prefix while allowing you to specify its
|
||||
subnet number, while `cidrsubnets` can calculate many at once, potentially of
|
||||
different sizes, and assigns subnet numbers automatically.
|
||||
|
@ -60,7 +60,7 @@ the same addressing scheme as the given prefix.
|
|||
```
|
||||
|
||||
You can use nested `cidrsubnets` calls with
|
||||
[`for` expressions](/docs/configuration/expressions.html#for-expressions)
|
||||
[`for` expressions](/docs/configuration/expressions#for-expressions)
|
||||
to concisely allocate groups of network address blocks:
|
||||
|
||||
```
|
||||
|
@ -87,9 +87,9 @@ to concisely allocate groups of network address blocks:
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`cidrhost`](./cidrhost.html) calculates the IP address for a single host
|
||||
- [`cidrhost`](./cidrhost) calculates the IP address for a single host
|
||||
within a given network address prefix.
|
||||
- [`cidrnetmask`](./cidrnetmask.html) converts an IPv4 network prefix in CIDR
|
||||
- [`cidrnetmask`](./cidrnetmask) converts an IPv4 network prefix in CIDR
|
||||
notation into netmask notation.
|
||||
- [`cidrsubnet`](./cidrsubnet.html) calculates a single subnet address, allowing
|
||||
- [`cidrsubnet`](./cidrsubnet) calculates a single subnet address, allowing
|
||||
you to specify its network number.
|
||||
|
|
|
@ -24,5 +24,5 @@ given value, which may be a fraction.
|
|||
|
||||
## Related Functions
|
||||
|
||||
- [`floor`](./floor.html), which rounds to the nearest whole number _less than_
|
||||
- [`floor`](./floor), which rounds to the nearest whole number _less than_
|
||||
or equal.
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue