mirror of
https://github.com/hashicorp/packer.git
synced 2026-04-15 22:20:33 -04:00
fix: update redirected and broken links (#12060)
* website: fix broken links on /docs/templates * fix: redirected install-plugins link * fix: debugging link * fix: secrets manager link in docs * fix: secrets manager link in source * fix: amazon ami plugin link in docs * fix: amazon ami plugin link in source * fix: extending plugins link * fix: plugins/builders/amazon links * fix: various builders links * fix: various amazon builder links * fix: redirected terminology link * fix: custom-provisioners link * fix: docker-push redirected plugin link * fix: googlecompute plugin links * fix: hyperv iso plugin links * website: update link to hcl upgrade guide Co-authored-by: Wilken Rivera <wilken@hashicorp.com> Co-authored-by: Wilken Rivera <wilken@hashicorp.com>
This commit is contained in:
parent
78c2aac4bb
commit
879fd9035c
26 changed files with 63 additions and 63 deletions
|
|
@ -107,7 +107,7 @@ const (
|
|||
# Read the documentation for data blocks here:
|
||||
# https://www.packer.io/docs/templates/hcl_templates/blocks/data
|
||||
# Read the documentation for the Amazon AMI Data Source here:
|
||||
# https://www.packer.io/docs/datasources/amazon/ami`
|
||||
# https://www.packer.io/plugins/datasources/amazon/ami`
|
||||
|
||||
amazonSecretsManagerDataHeader = `
|
||||
# The amazon-secretsmanager data block is generated from your aws_secretsmanager template function; a data
|
||||
|
|
@ -115,7 +115,7 @@ const (
|
|||
# Read the documentation for data blocks here:
|
||||
# https://www.packer.io/docs/templates/hcl_templates/blocks/data
|
||||
# Read the documentation for the Amazon Secrets Manager Data Source here:
|
||||
# https://www.packer.io/docs/datasources/amazon/secretsmanager`
|
||||
# https://www.packer.io/plugins/datasources/amazon/secretsmanager`
|
||||
)
|
||||
|
||||
var (
|
||||
|
|
|
|||
|
|
@ -52,7 +52,7 @@ variable "secret_account" {
|
|||
# Read the documentation for data blocks here:
|
||||
# https://www.packer.io/docs/templates/hcl_templates/blocks/data
|
||||
# Read the documentation for the Amazon Secrets Manager Data Source here:
|
||||
# https://www.packer.io/docs/datasources/amazon/secretsmanager
|
||||
# https://www.packer.io/plugins/datasources/amazon/secretsmanager
|
||||
data "amazon-secretsmanager" "autogenerated_1" {
|
||||
name = "sample/app/password"
|
||||
}
|
||||
|
|
@ -76,7 +76,7 @@ data "amazon-secretsmanager" "autogenerated_4" {
|
|||
# Read the documentation for data blocks here:
|
||||
# https://www.packer.io/docs/templates/hcl_templates/blocks/data
|
||||
# Read the documentation for the Amazon AMI Data Source here:
|
||||
# https://www.packer.io/docs/datasources/amazon/ami
|
||||
# https://www.packer.io/plugins/datasources/amazon/ami
|
||||
data "amazon-ami" "autogenerated_1" {
|
||||
access_key = "${var.aws_access_key}"
|
||||
filters = {
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
check out the docs on [extending Packer](/docs/plugins/install-plugins)
|
||||
|
||||
If you have built a plugin and would like to add it to this community list,
|
||||
please make a pull request so that we can document your
|
||||
|
|
@ -52,7 +52,6 @@ contribution here!
|
|||
- [lucidone/baseliner](https://git.sr.ht/~lucidone/baseliner) - Example of using
|
||||
QEMU + Ansible with Packer
|
||||
|
||||
|
||||
- [packer-build](https://github.com/tylert/packer-build) - Build fresh Debian
|
||||
and Ubuntu virtual machine images for Vagrant, VirtualBox and QEMU
|
||||
|
||||
|
|
|
|||
|
|
@ -11,5 +11,5 @@ page_title: Custom - Builders
|
|||
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) page of the Packer plugin
|
||||
builders](/docs/plugins/creation/custom-builders) page of the Packer plugin
|
||||
section.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,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#boot-configuration)
|
||||
be performed by a [boot command](/plugins/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
|
||||
|
|
|
|||
|
|
@ -182,10 +182,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#user_data_file). In Google
|
||||
[user_data_file](/plugins/builders/amazon/ebs#user_data_file). In Google
|
||||
Cloud, this is provided using the `windows-startup-script-cmd`
|
||||
[metadata](/docs/builders/googlecompute#metadata) tag.
|
||||
[Example](/docs/builders/googlecompute#windows-example)
|
||||
[metadata](/plugins/builders/googlecompute#metadata) tag.
|
||||
[Example](/plugins/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
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Packer can optionally read a JSON file for the end user to set core settings.
|
|||
The config file of Packer will be looked up on the following paths:
|
||||
|
||||
| Unix | Windows |
|
||||
| ------------------------------- | -------------------------------- |
|
||||
| -------------------------------- | -------------------------------- |
|
||||
| `${PACKER_CONFIG}` | `%PACKER_CONFIG%` |
|
||||
| `PACKER_HOME_DIR/.packerconfig` | `PACKER_HOME_DIR/packer.config/` |
|
||||
| `${XDG_CONFIG_HOME}/packer` | |
|
||||
|
|
@ -89,7 +89,7 @@ configuration file. None of these are required, since all have 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). It is instead recommended to use [HCL2
|
||||
page](/docs/plugins/install-plugins). It is instead recommended to use [HCL2
|
||||
`required_plugins`](/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements)
|
||||
and the [`packer init`](/docs/commands/init) command to install plugins; if
|
||||
you are using both, the `required_plugin` config will take precedence.
|
||||
|
|
@ -116,11 +116,11 @@ each can be found below:
|
|||
|
||||
- `PACKER_LOG` - Setting this to any value other than "" (empty string) or
|
||||
"0" will enable the logger. See the [debugging
|
||||
page](/docs/other/debugging).
|
||||
page](/docs/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).
|
||||
page](/docs/debugging).
|
||||
|
||||
- `PACKER_NO_COLOR` - Setting this to any value will disable color in the
|
||||
terminal.
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The diagram below depicts the key Packer integration categories and types.
|
|||
Main Packer categories for partners to integrate with include:
|
||||
|
||||
- **Data Sources**
|
||||
- Data Sources allow users to retrieve values from a remote API and store them as variables in the Packer configuration template. An example is the [AWS secrets manager](/docs/datasources/amazon/secretsmanager) data source.
|
||||
- Data Sources allow users to retrieve values from a remote API and store them as variables in the Packer configuration template. An example is the [AWS secrets manager](/plugins/datasources/amazon/secretsmanager) data source.
|
||||
- **Builders**
|
||||
- Builders manage the VM lifecycle. They manage launching a VM/instance, running provisioners against that instance, shutting the instance down, and saving an artifact image from that instance. Your builder handles all of the setup and cleanup costs associated with creating the output image artifact.
|
||||
- **Provisioners**
|
||||
|
|
|
|||
|
|
@ -17,6 +17,7 @@ This page explains how to use the Packer plugin interface to write custom builde
|
|||
## Before You Begin
|
||||
|
||||
We recommend reviewing the following resources before you begin development:
|
||||
|
||||
- [Developing Plugins - Overview](/docs/plugins/creation)
|
||||
- The [Go](https://go.dev/) language. You must write custom plugins in Go, so this guide assumes you are familiar with the language.
|
||||
|
||||
|
|
@ -305,5 +306,5 @@ order to make it available to the Packer core as a plugin. We have created a
|
|||
[scaffolding](https://github.com/hashicorp/packer-plugin-scaffolding/blob/main/builder/scaffolding/builder.go)
|
||||
repo to give you an idea of the relationship between the builder
|
||||
implementation and the server implementation within a repository, and then read
|
||||
[basics of how Plugins work](/docs/extending/plugins), which breaks down all the
|
||||
[basics of how Plugins work](/docs/plugins/install-plugins), which breaks down all the
|
||||
server details.
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ page_title: Custom Data Sources - Extending
|
|||
|
||||
# Custom Data Sources
|
||||
|
||||
Packer data sources let Packer fetch data to use within the configuration, including information defined outside of Packer. For example, the [amazon-ami data source](/docs/datasources/amazon/ami), outputs the data from an Amazon AMI.
|
||||
Packer data sources let Packer fetch data to use within the configuration, including information defined outside of Packer. For example, the [amazon-ami data source](/plugins/datasources/amazon/ami), outputs the data from an Amazon AMI.
|
||||
|
||||
Data Source plugins implement the `packersdk.Datasource` interface and are registered within a plugin Set
|
||||
with `set.RegisterDatasource(...)` function and served using the `set.Run()`.
|
||||
|
|
@ -17,6 +17,7 @@ with `set.RegisterDatasource(...)` function and served using the `set.Run()`.
|
|||
## Before You Begin
|
||||
|
||||
We recommend reviewing the following resources before you begin development:
|
||||
|
||||
- [Developing Plugins - Overview](/docs/plugins/creation)
|
||||
- The [Go](https://go.dev/) language. You must write custom plugins in Go, so this guide assumes you are familiar with the language.
|
||||
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ After computes checksum for artifacts, you can use new artifacts with other
|
|||
post-processors like
|
||||
[artifice](/docs/post-processors/artifice),
|
||||
[compress](/docs/post-processors/compress),
|
||||
[docker-push](/docs/post-processors/docker/docker-push), or
|
||||
[docker-push](/plugins/post-processors/docker/docker-push), or
|
||||
a third-party post-processor.
|
||||
|
||||
## Basic example
|
||||
|
|
|
|||
|
|
@ -12,5 +12,5 @@ page_title: Custom - Provisioners
|
|||
Packer is extensible, allowing you to write new provisioners without having to
|
||||
modify the core source code of Packer itself. Documentation for creating new
|
||||
provisioners is covered in the [custom
|
||||
provisioners](/docs/extending/custom-provisioners) page of the Packer
|
||||
provisioners](/docs/plugins/creation/custom-provisioners) page of the Packer
|
||||
plugin section.
|
||||
|
|
|
|||
|
|
@ -94,4 +94,4 @@ this is soon going to be possible. So here "a.\*" will match nothing.
|
|||
- A list of [community
|
||||
builders](/community-tools#community-builders) is available.
|
||||
|
||||
- Create your own [custom builder](/docs/extending/custom-builders) !
|
||||
- Create your own [custom builder](/docs/plugins/creation/custom-builders) !
|
||||
|
|
|
|||
|
|
@ -58,4 +58,4 @@ build {
|
|||
- A list of [community
|
||||
builders](/community-tools#community-builders) is available.
|
||||
|
||||
- Create your own [custom builder](/docs/extending/custom-builders) !
|
||||
- Create your own [custom builder](/docs/plugins/creation/custom-builders) !
|
||||
|
|
|
|||
|
|
@ -77,11 +77,11 @@ Example of using [upper](/docs/templates/hcl_templates/functions/string/upper) t
|
|||
|
||||
For builder-specific builder variables, please also refer to the builder docs:
|
||||
|
||||
- Amazon EC2: [chroot](/docs/builders/amazon/chroot#build-shared-information-variables),
|
||||
[EBS Volume](/docs/builders/amazon/ebsvolume#build-shared-information-variables),
|
||||
[EBS](/docs/builders/amazon/ebs#build-shared-information-variables),
|
||||
[EBS Surrogate](/docs/builders/amazon/ebssurrogate#build-shared-information-variables),
|
||||
[Instance](/docs/builders/amazon/instance#build-shared-information-variables).
|
||||
- Amazon EC2: [chroot](/plugins/builders/amazon/chroot#build-shared-information-variables),
|
||||
[EBS Volume](/plugins/builders/amazon/ebsvolume#build-shared-information-variables),
|
||||
[EBS](/plugins/builders/amazon/ebs#build-shared-information-variables),
|
||||
[EBS Surrogate](/plugins/builders/amazon/ebssurrogate#build-shared-information-variables),
|
||||
[Instance](/plugins/builders/amazon/instance#build-shared-information-variables).
|
||||
|
||||
The HCL2 Special Build Variables is in beta; please report any issues or requests on the Packer
|
||||
issue tracker on GitHub.
|
||||
|
|
|
|||
2
website/content/docs/templates/index.mdx
vendored
2
website/content/docs/templates/index.mdx
vendored
|
|
@ -28,4 +28,4 @@ From version **1.7.0**, HCL2 becomes officially the preferred way to write Packe
|
|||
configuration(s).
|
||||
|
||||
If you need help upgrading a JSON template to an HCL template, check
|
||||
our upgrade guide [here](/guides/hcl/from-json-v1).
|
||||
our upgrade guide [here](https://developer.hashicorp.com/packer/tutorials/configuration-language/hcl2-upgrade).
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ Within a template, a section of builder definitions looks like this:
|
|||
## Builder Definition
|
||||
|
||||
A single builder definition maps to exactly one
|
||||
[build](/docs/basics/terminology#builds). A builder definition is a
|
||||
[build](/docs/terminology#builds). A builder definition is a
|
||||
JSON object that requires at least a `type` key. The `type` is the name of the
|
||||
builder that will be used to create a machine image for the build.
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,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#boot-configuration) that references a file which
|
||||
be performed by a [boot_command](/plugins/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 required by Debian, the
|
||||
|
|
|
|||
|
|
@ -109,11 +109,11 @@ Here is a full list of the available functions for reference.
|
|||
|
||||
For builder-specific builder variables, please also refer to the builder docs:
|
||||
|
||||
- Amazon EC2: [chroot](/docs/builders/amazon/chroot#build-shared-information-variables),
|
||||
[EBS Volume](/docs/builders/amazon/ebsvolume#build-shared-information-variables),
|
||||
[EBS](/docs/builders/amazon/ebs#build-shared-information-variables),
|
||||
[EBS Surrogate](/docs/builders/amazon/ebssurrogate#build-shared-information-variables),
|
||||
[Instance](/docs/builders/amazon/instance#build-shared-information-variables).
|
||||
- Amazon EC2: [chroot](/plugins/builders/amazon/chroot#build-shared-information-variables),
|
||||
[EBS Volume](/plugins/builders/amazon/ebsvolume#build-shared-information-variables),
|
||||
[EBS](/plugins/builders/amazon/ebs#build-shared-information-variables),
|
||||
[EBS Surrogate](/plugins/builders/amazon/ebssurrogate#build-shared-information-variables),
|
||||
[Instance](/plugins/builders/amazon/instance#build-shared-information-variables).
|
||||
|
||||
This engine is in beta; please report any issues or requests on the Packer
|
||||
issue tracker on GitHub.
|
||||
|
|
@ -209,7 +209,7 @@ Template variables are special variables automatically set by Packer at build
|
|||
time. Some builders, provisioners and other components have template variables
|
||||
that are available only for that component. Template variables are recognizable
|
||||
because they're prefixed by a period, such as `{{ .Name }}`. For example, when
|
||||
using the [`shell`](/docs/builders/vmware-iso) builder template variables
|
||||
using the [`shell`](/plugins/builders/vmware/iso) builder template variables
|
||||
are available to customize the
|
||||
[`execute_command`](/docs/provisioners/shell#execute_command) parameter
|
||||
used to determine how Packer will run the shell command.
|
||||
|
|
@ -274,17 +274,16 @@ of how you'd declare a variable using the isotime function.
|
|||
You can try and modify the following examples in a packer template or in
|
||||
`packer console` to get an idea of how to set different timestamps:
|
||||
|
||||
| Input | Output |
|
||||
| ------------------------------------------ | ----------- |
|
||||
| ``"packer-{{isotime `2006-01-02`}}"`` | "packer-2021-05-17" |
|
||||
| ``"packer-{{isotime `Jan-_2-15:04:05.000`}}"`` | "packer-May-17-23:40:16.786" |
|
||||
| ``"packer-{{isotime `3:04PM`}}"`` | "packer-11:40PM" |
|
||||
| ``"{{ isotime }}"`` | "June 7, 7:22:43pm 2014" |
|
||||
| ``"{{isotime `2006-01-02`}}"`` | "2014-06-07" |
|
||||
| ``"{{isotime `Mon 1504`}}"`` | "Sat 1922" |
|
||||
| ``"{{isotime `02-Jan-06 03\_04\_05`}}"`` | "07-Jun-2014 07\_22\_43" |
|
||||
| ``"{{isotime `Hour15Year200603`}}"`` | "Hour19Year201407" |
|
||||
|
||||
| Input | Output |
|
||||
| ------------------------------------------------ | ---------------------------- |
|
||||
| `` "packer-{{isotime `2006-01-02`}}" `` | "packer-2021-05-17" |
|
||||
| `` "packer-{{isotime `Jan-_2-15:04:05.000`}}" `` | "packer-May-17-23:40:16.786" |
|
||||
| `` "packer-{{isotime `3:04PM`}}" `` | "packer-11:40PM" |
|
||||
| `"{{ isotime }}"` | "June 7, 7:22:43pm 2014" |
|
||||
| `` "{{isotime `2006-01-02`}}" `` | "2014-06-07" |
|
||||
| `` "{{isotime `Mon 1504`}}" `` | "Sat 1922" |
|
||||
| `` "{{isotime `02-Jan-06 03\_04\_05`}}" `` | "07-Jun-2014 07_22_43" |
|
||||
| `` "{{isotime `Hour15Year200603`}}" `` | "Hour19Year201407" |
|
||||
|
||||
Formatting for the function `isotime` uses the magic reference date **Mon Jan 2
|
||||
15:04:05 -0700 MST 2006**, which breaks down to the following:
|
||||
|
|
|
|||
|
|
@ -155,7 +155,7 @@ script to it and run that script using SSH.
|
|||
|
||||
-> **Note:** This example requires an account with Amazon Web Services.
|
||||
There are a number of parameters which need to be provided for a functional
|
||||
build to take place. See the [Amazon builder](/docs/builders/amazon)
|
||||
build to take place. See the [Amazon builder](/plugins/builders/amazon)
|
||||
documentation for more information.
|
||||
|
||||
```json
|
||||
|
|
|
|||
|
|
@ -23,9 +23,9 @@ for the official documentation.
|
|||
|
||||
If you are installing the Windows Operating System from a mounted iso as part of
|
||||
your Packer build, you will need to use an Answer file. For example, you're
|
||||
building an image from scratch using the [vmware-iso](/docs/builders/vmware-iso),
|
||||
[virtualbox-iso](/docs/builders/virtualbox-iso), or
|
||||
[hyperv-iso](/docs/builders/hyperv-iso) builders.
|
||||
building an image from scratch using the [vmware-iso](/plugins/builders/vmware/iso),
|
||||
[virtualbox-iso](/plugins/builders/virtualbox/iso), or
|
||||
[hyperv-iso](/plugins/builders/hyperv/iso) builders.
|
||||
|
||||
If you are not installing the operating system, you won't need to provide an
|
||||
answer file. If you are using a pre-built image
|
||||
|
|
|
|||
|
|
@ -23,9 +23,9 @@ for the official documentation.
|
|||
|
||||
If you are installing the operating system from a mounted iso as part of
|
||||
your Packer build, you will need to use a preseed file. For example, you're
|
||||
building an image from scratch using the [vmware-iso](/docs/builders/vmware-iso),
|
||||
[virtualbox-iso](/docs/builders/virtualbox-iso), or
|
||||
[hyperv-iso](/docs/builders/hyperv-iso) builders.
|
||||
building an image from scratch using the [vmware-iso](/plugins/builders/vmware/iso),
|
||||
[virtualbox-iso](/plugins/builders/virtualbox/iso), or
|
||||
[hyperv-iso](/plugins/builders/hyperv/iso) builders.
|
||||
|
||||
If you are not installing the operating system, you won't need to provide a
|
||||
preseed file. If you are using a pre-built image in a cloud, you don't need to
|
||||
|
|
|
|||
|
|
@ -14,11 +14,11 @@ The majority of the [Packer Builders](/docs/builders) can run just fine in a
|
|||
container, a common model used by most CI/CD services. However, while it is
|
||||
possible to run many builders in containers or nested virtualization, this may
|
||||
require advanced configuration; examples include the [QEMU
|
||||
builder](/docs/builders/qemu) for
|
||||
builder](/plugins/builders/qemu) for
|
||||
[KVM](https://www.linux-kvm.org/page/Main_Page) or
|
||||
[Xen](https://www.xenproject.org/), the [VirtualBox
|
||||
builder](/docs/builders/virtualbox) for OVA or OVF virtual machines, and the
|
||||
[VMware builder](/docs/builders/vmware) for use with VMware products that are
|
||||
builder](/plugins/builders/virtualbox) for OVA or OVF virtual machines, and the
|
||||
[VMware builder](/plugins/builders/vmware) for use with VMware products that are
|
||||
all designed to run on a bare-metal machine or within nested virtualization.
|
||||
|
||||
The [Building a VirtualBox Image with Packer in
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ The Packer VirtualBox builder requires access to VirtualBox. Virtualization is
|
|||
not universally supported on cloud instances, so we recommend you run these
|
||||
builds on either a bare metal server, or cloud instances which support nested
|
||||
virtualization, such as Azure or GCP. This is also true for the
|
||||
[VMware](/docs/builders/vmware) and the [QEMU](/docs/builders/qemu)
|
||||
[VMware](/plugins/builders/vmware) and the [QEMU](/plugins/builders/qemu)
|
||||
Packer builders.
|
||||
|
||||
We will use Chef's [Bento boxes](https://github.com/chef/bento) to provision an
|
||||
|
|
@ -127,7 +127,7 @@ This will use the `build` command in Packer to build the image defined in
|
|||
using is a fork of [Chef/Bento](https://github.com/chef/bento). Packer defaults
|
||||
to building VirtualBox machines by launching a GUI that shows the console.
|
||||
Since this will run in CI/CD, use the [`headless`
|
||||
variable](/docs/builders/virtualbox-iso#headless) to instruct Packer to
|
||||
variable](/plugins/builders/virtualbox/iso#headless) to instruct Packer to
|
||||
start the machine without the console. Packer can build multiple image types,
|
||||
so the [`-only=virtualbox-iso`
|
||||
option](/docs/commands/build#only-foo-bar-baz) instructs Packer to only
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ look up the output file information.
|
|||
## Customizing the iso using the virtualbox-ovf builder
|
||||
|
||||
That output filename generated in the first stage can be used as the
|
||||
[source_path](/docs/builders/virtualbox/ovf#source_path)
|
||||
[source_path](/plugins/builders/virtualbox/ovf#source_path)
|
||||
for the virtualbox-ovf builder.
|
||||
|
||||
<Tabs>
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@
|
|||
- `winrm_password` (string) - The password to use to connect to WinRM.
|
||||
|
||||
- `winrm_host` (string) - The address for WinRM to connect to.
|
||||
|
||||
|
||||
NOTE: If using an Amazon EBS builder, you can specify the interface
|
||||
WinRM connects to via
|
||||
[`ssh_interface`](/docs/builders/amazon-ebs#ssh_interface)
|
||||
[`ssh_interface`](/plugins/builders/amazon/ebs#ssh_interface)
|
||||
|
||||
- `winrm_no_proxy` (bool) - Setting this to `true` adds the remote
|
||||
`host:port` to the `NO_PROXY` environment variable. This has the effect of
|
||||
|
|
@ -30,4 +30,4 @@
|
|||
for WinRM, rather than default (basic authentication), removing the
|
||||
requirement for basic authentication to be enabled within the target
|
||||
guest. Further reading for remote connection authentication can be found
|
||||
[here](https://msdn.microsoft.com/en-us/library/aa384295(v=vs.85).aspx).
|
||||
[here](<https://msdn.microsoft.com/en-us/library/aa384295(v=vs.85).aspx>).
|
||||
|
|
|
|||
Loading…
Reference in a new issue