website: remove obselete nav data (#10811)
* website: remove obselete sidebar_title frontmatter from docs * website: bump to latest docs-page * website: update plugin creation and registration docs * website: fix broken links
This commit is contained in:
Zachary Shilton
GitHub
parent
3e497e3712
commit
830140157d
|
|
@ -7,19 +7,27 @@ import {
|
|||
import renderPageMdx from '@hashicorp/react-docs-page/render-page-mdx'
|
||||
import resolveNavData from './utils/resolve-nav-data'
|
||||
|
||||
async function generateStaticPaths(navDataFile, contentDir, options = {}) {
|
||||
const navData = await resolveNavData(navDataFile, contentDir, options)
|
||||
async function generateStaticPaths({
|
||||
navDataFile,
|
||||
localContentDir,
|
||||
remotePluginsFile,
|
||||
}) {
|
||||
const navData = await resolveNavData(navDataFile, localContentDir, {
|
||||
remotePluginsFile,
|
||||
})
|
||||
const paths = await getPathsFromNavData(navData)
|
||||
return paths
|
||||
}
|
||||
|
||||
async function generateStaticProps(
|
||||
navDataFile,
|
||||
async function generateStaticProps({
|
||||
additionalComponents,
|
||||
localContentDir,
|
||||
mainBranch = 'main',
|
||||
navDataFile,
|
||||
params,
|
||||
product,
|
||||
{ remotePluginsFile, additionalComponents, mainBranch = 'main' } = {}
|
||||
) {
|
||||
remotePluginsFile,
|
||||
}) {
|
||||
const navData = await resolveNavData(navDataFile, localContentDir, {
|
||||
remotePluginsFile,
|
||||
})
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `alicloud-ecs` Packer builder plugin provide the capability to build
|
||||
customized images based on an existing base images.
|
||||
page_title: Alicloud Image Builder
|
||||
sidebar_title: Alicloud ECS
|
||||
---
|
||||
|
||||
# Alicloud Image Builder
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
description: Packer supports building VHDs in Azure Resource manager.
|
||||
page_title: Azure arm - Builders
|
||||
sidebar_title: ARM
|
||||
---
|
||||
|
||||
# Azure Resource Manager Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
|
||||
a VM in Azure.
|
||||
page_title: Azure chroot - Builders
|
||||
sidebar_title: chroot
|
||||
---
|
||||
|
||||
# Azure Builder (chroot)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
multiple builders depending on the strategy you want to use to build the
|
||||
images.
|
||||
page_title: Azure images - Builders
|
||||
sidebar_title: Azure
|
||||
---
|
||||
|
||||
# Azure Virtual Machine Image Builders
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
source, runs any provisioning necessary on the instance after launching it and
|
||||
then creates a new template from that instance.
|
||||
page_title: CloudStack - Builders
|
||||
sidebar_title: CloudStack
|
||||
---
|
||||
|
||||
# CloudStack Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Community-maintained builders are not part of the core Packer binary, but
|
||||
can run alongside Packer with minimal extra effort.
|
||||
page_title: Community - Builders
|
||||
sidebar_title: Community-Supported
|
||||
---
|
||||
|
||||
# Community Builders
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
modify the core source code of Packer itself. Documentation for creating new
|
||||
builders is covered in the custom builders page of the Packer plugin section.
|
||||
page_title: Custom - Builders
|
||||
sidebar_title: Custom
|
||||
---
|
||||
|
||||
# Custom Builder
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ description: >
|
|||
|
||||
launched within DigitalOcean.
|
||||
page_title: DigitalOcean - Builders
|
||||
sidebar_title: DigitalOcean
|
||||
---
|
||||
|
||||
# DigitalOcean Builder
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
from a file. It can be used to debug post-processors without incurring high
|
||||
wait times.
|
||||
page_title: File - Builders
|
||||
sidebar_title: File
|
||||
---
|
||||
|
||||
# File Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The googlecompute Packer builder is able to create images for use with Google
|
||||
Cloud Compute Engine (GCE) based on existing images.
|
||||
page_title: Google Compute - Builders
|
||||
sidebar_title: Google Cloud
|
||||
---
|
||||
|
||||
# Google Compute Builder
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: |
|
|||
image. This reusable image can then be used as the foundation of new servers
|
||||
that are launched within the Hetzner Cloud.
|
||||
page_title: Hetzner Cloud - Builders
|
||||
sidebar_title: Hetzner Cloud
|
||||
---
|
||||
|
||||
# Hetzner Cloud Builder
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
The builder takes a source image, runs any provisioning necessary on
|
||||
the image after launching it, then creates a reusable image.
|
||||
page_title: HyperOne - Builders
|
||||
sidebar_title: HyperOne
|
||||
---
|
||||
|
||||
# HyperOne Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Hyper-V Packer builder is able to create Hyper-V virtual machines and
|
||||
export them.
|
||||
page_title: Hyper-V - Builders
|
||||
sidebar_title: Hyper-V
|
||||
---
|
||||
|
||||
# HyperV Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
The Hyper-V Packer builder is able to create Hyper-V virtual machines and
|
||||
export them.
|
||||
page_title: Hyper-V ISO - Builders
|
||||
sidebar_title: ISO
|
||||
---
|
||||
|
||||
# Hyper-V Builder (from an ISO)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >-
|
|||
The Hyper-V Packer builder is able to clone an existing Hyper-V virtual
|
||||
machine and export them.
|
||||
page_title: Hyper-V Builder (from a vmcx)
|
||||
sidebar_title: VMCX
|
||||
---
|
||||
|
||||
# Hyper-V Builder (from a vmcx)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Builders are responsible for creating machines and generating images from them
|
||||
for various platforms.
|
||||
page_title: Builders
|
||||
sidebar_title: Builders
|
||||
---
|
||||
|
||||
# Builders
|
||||
|
|
@ -17,4 +16,3 @@ See the [`source`](/docs/templates/hcl_templates/blocks/source) block documentat
|
|||
about configuring builders in the Packer language.
|
||||
For information on an individual builder, choose it from the sidebar. Each
|
||||
builder has its own configuration options and parameters.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `jdcloud` Packer builder helps you to build instance images
|
||||
based on an existing image
|
||||
page_title: JDCloud Image Builder
|
||||
sidebar_title: JDCloud
|
||||
---
|
||||
|
||||
# JDCloud Image Builder
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ description: >
|
|||
|
||||
within all Linode regions.
|
||||
page_title: Linode - Builders
|
||||
sidebar_title: Linode
|
||||
---
|
||||
|
||||
# Linode Builder
|
||||
|
|
@ -48,6 +47,7 @@ can also be supplied to override the typical auto-generated key:
|
|||
|
||||
See https://github.com/tcort/markdown-link-check/issues/109
|
||||
-->
|
||||
|
||||
### Required
|
||||
|
||||
- `linode_token` (string) - The client TOKEN to use to access your account.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
container, runs provisioners within this container, then exports the container
|
||||
as a tar.gz of the root file system.
|
||||
page_title: LXC - Builders
|
||||
sidebar_title: LXC
|
||||
---
|
||||
|
||||
# LXC Builder
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
|
||||
an LXD image.
|
||||
page_title: LXD - Builders
|
||||
sidebar_title: LXD
|
||||
---
|
||||
|
||||
# LXD Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The ncloud builder allows you to create server images using the NAVER Cloud
|
||||
Platform.
|
||||
page_title: Naver Cloud Platform - Builders
|
||||
sidebar_title: NAVER Cloud
|
||||
---
|
||||
|
||||
# NAVER CLOUD PLATFORM Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
without incurring high wait times. It does not create any kind of image or
|
||||
artifact.
|
||||
page_title: Null - Builders
|
||||
sidebar_title: 'Null'
|
||||
---
|
||||
|
||||
# Null Builder
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
description: The 1&1 builder is able to create images for 1&1 cloud.
|
||||
page_title: 1&1 - Builders
|
||||
sidebar_title: 1&1
|
||||
---
|
||||
|
||||
# 1&1 Builder
|
||||
|
|
@ -47,6 +46,7 @@ can also be supplied to override the typical auto-generated key:
|
|||
while waiting for the build to complete. Default value "600".
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
|
||||
- `url` (string) - Endpoint for the 1&1 REST API. Default URL
|
||||
"<https://cloudpanel-api.1and1.com/v1>"
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ description: >
|
|||
|
||||
within OpenStack.
|
||||
page_title: OpenStack - Builders
|
||||
sidebar_title: OpenStack
|
||||
---
|
||||
|
||||
# OpenStack Builder
|
||||
|
|
@ -132,6 +131,7 @@ builders "openstack" {
|
|||
insecure = "true"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -155,6 +155,7 @@ Here is a basic example. This is a working example to build a Ubuntu 12.04 LTS
|
|||
"flavor": "2"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="HCL2">
|
||||
|
|
@ -170,6 +171,7 @@ builders "openstack" {
|
|||
flavor = "2"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
|
@ -190,6 +192,7 @@ by Metacloud.
|
|||
"flavor": "2"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="HCL2">
|
||||
|
|
@ -202,10 +205,10 @@ builders "openstack" {
|
|||
flavor = "2"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
In this case, the connection information for connecting to OpenStack doesn't
|
||||
appear in the template. That is because I source a standard OpenStack script
|
||||
with environment variables set before I run this. This script is setting
|
||||
|
|
@ -266,6 +269,7 @@ by Selectel VPC.
|
|||
"volume_type": "fast.ru-3a"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="HCL2">
|
||||
|
|
@ -287,10 +291,10 @@ builders "openstack" {
|
|||
volume_type = "fast.ru-3a"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
## Notes on OpenStack Authorization
|
||||
|
||||
The simplest way to get all settings for authorization against OpenStack is to
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The oracle-classic builder is able to create new custom images for use with
|
||||
Oracle Cloud Infrastructure Classic Compute.
|
||||
page_title: Oracle Cloud Infrastructure Classic - Builders
|
||||
sidebar_title: Oracle Classic
|
||||
---
|
||||
|
||||
# Oracle Cloud Infrastructure Classic Compute Builder
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
description: Packer is able to create custom images using Oracle Cloud Infrastructure.
|
||||
page_title: Oracle - Builders
|
||||
sidebar_title: Oracle
|
||||
---
|
||||
|
||||
# Oracle Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The oracle-oci builder is able to create new custom images for use with Oracle
|
||||
Cloud Infrastructure (OCI).
|
||||
page_title: Oracle OCI - Builders
|
||||
sidebar_title: Oracle OCI
|
||||
---
|
||||
|
||||
# Oracle Cloud Infrastructure (OCI) Builder
|
||||
|
|
@ -195,6 +194,7 @@ can also be supplied to override the typical auto-generated key:
|
|||
- `memory_in_gbs` (optional) (float32) - The total amount of memory, in gigabytes, available to the instance.
|
||||
|
||||
<!-- markdown-link-check-disable -->
|
||||
|
||||
- `metadata` (map of strings) - Metadata optionally contains custom metadata
|
||||
key/value pairs provided in the configuration. While this can be used to
|
||||
set metadata\["user_data"\] the explicit "user_data" and
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
|
||||
the root device section in the Outscale documentation.
|
||||
page_title: Outscale BSU - Builders
|
||||
sidebar_title: BSU
|
||||
---
|
||||
|
||||
# OMI Builder (BSU backed)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The osc-bsusurrogate Packer builder is like the chroot builder, but does not
|
||||
require running inside an Outscale virtual machine.
|
||||
page_title: Outscale BSU Surrogate - Builders
|
||||
sidebar_title: BSU Surrogate
|
||||
---
|
||||
|
||||
# BSU Surrogate Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The osc-bsuvolume Packer builder is like the BSU builder, but is intended to
|
||||
create BSU volumes rather than a machine image.
|
||||
page_title: Outscale BSU Volume - Builders
|
||||
sidebar_title: BSU Volume
|
||||
---
|
||||
|
||||
# BSU Volume Builder
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ description: >
|
|||
|
||||
in the Outscale documentation.
|
||||
page_title: Outscale chroot - Builders
|
||||
sidebar_title: chroot
|
||||
---
|
||||
|
||||
# OMI Builder (chroot)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
|
||||
multiple builders depending on the strategy you want to use to build the OMI.
|
||||
page_title: Outscale OMI - Builders
|
||||
sidebar_title: Outscale
|
||||
---
|
||||
|
||||
# Outscale OMI Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Parallels Packer builder is able to create Parallels Desktop for Mac
|
||||
virtual machines and export them in the PVM format.
|
||||
page_title: Parallels - Builders
|
||||
sidebar_title: Parallels
|
||||
---
|
||||
|
||||
# Parallels Builder
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: |
|
|||
virtual machines and export them in the PVM format, starting from an ISO
|
||||
image.
|
||||
page_title: Parallels ISO - Builders
|
||||
sidebar_title: ISO
|
||||
---
|
||||
|
||||
# Parallels Builder (from an ISO)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: |
|
|||
machines and export them in the PVM format, starting from an existing PVM
|
||||
(exported virtual machine image).
|
||||
page_title: Parallels PVM - Builders
|
||||
sidebar_title: PVM
|
||||
---
|
||||
|
||||
# Parallels Builder (from a PVM)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
---
|
||||
description: The ProfitBricks builder is able to create images for ProfitBricks cloud.
|
||||
page_title: ProfitBricks - Builders
|
||||
sidebar_title: ProfitBricks
|
||||
---
|
||||
|
||||
# ProfitBricks Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
template name, runs any provisioning necessary on the image after
|
||||
launching it, then creates a virtual machine template.
|
||||
page_title: Proxmox Clone - Builders
|
||||
sidebar_title: Clone
|
||||
---
|
||||
|
||||
# Proxmox Builder (from an image)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: >
|
|||
The Proxmox Packer builder is able to create Cloud-Init virtual machine images
|
||||
on a Proxmox server.
|
||||
page_title: Proxmox - Builders
|
||||
sidebar_title: Proxmox
|
||||
---
|
||||
|
||||
# Proxmox Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
necessary on the image after launching it, then creates a virtual machine
|
||||
template.
|
||||
page_title: Proxmox ISO - Builders
|
||||
sidebar_title: ISO
|
||||
---
|
||||
|
||||
# Proxmox Builder (from an ISO)
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ modeline: |
|
|||
description: |
|
||||
The Qemu Packer builder is able to create KVM virtual machine images.
|
||||
page_title: QEMU - Builders
|
||||
sidebar_title: QEMU
|
||||
---
|
||||
|
||||
# QEMU Builder
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ description: >
|
|||
|
||||
servers that are launched within Scaleway.
|
||||
page_title: Scaleway - Builders
|
||||
sidebar_title: Scaleway
|
||||
---
|
||||
|
||||
# Scaleway Builder
|
||||
|
|
@ -70,6 +69,7 @@ access tokens:
|
|||
"ssh_private_key_file": "~/.ssh/id_rsa"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
|
||||
<Tab heading="HCL2">
|
||||
|
|
@ -86,10 +86,10 @@ builders "scaleway" {
|
|||
ssh_private_key_file = "~/.ssh/id_rsa"
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
When you do not specify the `ssh_private_key_file`, a temporary SSH keypair
|
||||
is generated to connect the server. This key will only allow the `root` user to
|
||||
connect the server.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `tencentcloud-cvm` Packer builder plugin provide the capability to build
|
||||
customized images based on an existing base images.
|
||||
page_title: Tencentcloud Image Builder
|
||||
sidebar_title: Tencent Cloud
|
||||
---
|
||||
|
||||
# Tencentcloud Image Builder
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@ description: >
|
|||
|
||||
Cloud API to create images.
|
||||
page_title: Triton - Builders
|
||||
sidebar_title: Triton
|
||||
---
|
||||
|
||||
# Triton Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `ucloud-uhost` Packer builder plugin provides the capability to build
|
||||
customized images based on an existing base image for use in UHost Instance.
|
||||
page_title: UCloud Image Builder
|
||||
sidebar_title: UCloud
|
||||
---
|
||||
|
||||
# UCloud Image Builder
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Vagrant Packer builder is able to launch Vagrant boxes and
|
||||
re-package them into .box files
|
||||
page_title: Vagrant - Builders
|
||||
sidebar_title: Vagrant
|
||||
---
|
||||
|
||||
# Vagrant Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
|
||||
export them in the OVA or OVF format.
|
||||
page_title: VirtualBox - Builders
|
||||
sidebar_title: VirtualBox
|
||||
---
|
||||
|
||||
# VirtualBox Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
The VirtualBox Packer builder is able to create VirtualBox virtual machines
|
||||
and export them in the OVF format, starting from an ISO image.
|
||||
page_title: VirtualBox ISO - Builders
|
||||
sidebar_title: ISO
|
||||
---
|
||||
|
||||
# VirtualBox Builder (from an ISO)
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: |
|
|||
and export them in the OVF format, starting from an existing OVF/OVA (exported
|
||||
virtual machine image).
|
||||
page_title: VirtualBox OVF/OVA - Builders
|
||||
sidebar_title: OVF
|
||||
---
|
||||
|
||||
# VirtualBox Builder (from an OVF/OVA)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
|
||||
and export them in the OVF format, starting from an ISO image.
|
||||
page_title: VirtualBox Snapshot - Builders
|
||||
sidebar_title: VM
|
||||
---
|
||||
|
||||
# VirtualBox Builder (from an existing VM)
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The VMware Packer builder is able to create VMware virtual machines for use
|
||||
with any VMware product.
|
||||
page_title: VMware - Builders
|
||||
sidebar_title: VMware
|
||||
---
|
||||
|
||||
# VMware Builder
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ description: |
|
|||
VMware Player on Linux. It can also build machines directly on VMware vSphere
|
||||
Hypervisor using SSH as opposed to the vSphere API.
|
||||
page_title: VMware ISO - Builders
|
||||
sidebar_title: VMWare ISO
|
||||
---
|
||||
|
||||
# VMware Builder (from ISO)
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: |
|
|||
virtual machines on hosts running VMware Fusion Professional for OS X, VMware
|
||||
Workstation for Linux and Windows, and VMware Player on Linux.
|
||||
page_title: VMware VMX - Builders
|
||||
sidebar_title: VMWare VMX
|
||||
---
|
||||
|
||||
# VMware Builder (from VMX)
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
This VMware Packer builder uses the vSphere API to clone an existing vSphere
|
||||
template and create a new virtual machine remotely.
|
||||
page_title: VSphere Clone - Builders
|
||||
sidebar_title: VSphere Clone
|
||||
---
|
||||
|
||||
# VMWare Vsphere Clone Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
This VMware Packer builder starts from an ISO and creates a vm using the
|
||||
vSphere API to build on a remote VMWare machine.
|
||||
page_title: VSphere ISO - Builders
|
||||
sidebar_title: VSphere ISO
|
||||
---
|
||||
|
||||
# Packer Builder for VMware vSphere
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The yandex Packer builder is able to create images for use with
|
||||
Yandex.Cloud based on existing images.
|
||||
page_title: Yandex Compute - Builders
|
||||
sidebar_title: Yandex.Cloud
|
||||
---
|
||||
|
||||
# Yandex Compute Builder
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
template are executed in parallel, unless otherwise specified. And the
|
||||
artifacts that are created will be outputted at the end of the build.
|
||||
page_title: packer build - Commands
|
||||
sidebar_title: <tt>build</tt>
|
||||
---
|
||||
|
||||
# `build` Command
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `packer console` command allows you to experiment with Packer variable
|
||||
interpolations.
|
||||
page_title: packer console - Commands
|
||||
sidebar_title: <tt>console</tt>
|
||||
---
|
||||
|
||||
# `console` Command
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
of Packer. After you update to a new Packer release, you should run the fix
|
||||
command to make sure your templates work with the new release.
|
||||
page_title: packer fix - Commands
|
||||
sidebar_title: <tt>fix</tt>
|
||||
---
|
||||
|
||||
# `fix` Command
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The `packer fmt` Packer command is used to format HCL2
|
||||
configuration files to a canonical format and style.
|
||||
page_title: packer fmt - Commands
|
||||
sidebar_title: <tt>fmt</tt>
|
||||
---
|
||||
|
||||
# `fmt` Command
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
configuration template to it's formatted HCL2 counterpart. The command will
|
||||
return a zero exit status on success, and a non-zero exit status on failure.
|
||||
page_title: packer hcl2_upgrade - Commands
|
||||
sidebar_title: <tt>hcl2_upgrade</tt>
|
||||
---
|
||||
|
||||
-> **Note:** This command is Beta, and currently being improved upon; do not
|
||||
|
|
@ -39,12 +38,9 @@ From **v1.7.1**, the `hcl2_upgrade` command can upgrade a variables file.
|
|||
"aws_region": null,
|
||||
"aws_secondary_region": "{{ env `AWS_DEFAULT_REGION` }}",
|
||||
"aws_secret_key": "",
|
||||
"aws_access_key": "",
|
||||
"aws_access_key": ""
|
||||
},
|
||||
"sensitive-variables": [
|
||||
"aws_secret_key",
|
||||
"aws_access_key",
|
||||
]
|
||||
"sensitive-variables": ["aws_secret_key", "aws_access_key"]
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: |
|
|||
additional options as well. Subcommands are executed with `packer SUBCOMMAND`,
|
||||
where "SUBCOMMAND" is the actual command you wish to execute.
|
||||
page_title: Commands
|
||||
sidebar_title: Commands (CLI)
|
||||
---
|
||||
|
||||
# Packer Commands (CLI)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,6 @@
|
|||
description: |
|
||||
The `packer init` Packer command is used to download Packer plugin binaries.
|
||||
page_title: packer init - Commands
|
||||
sidebar_title: <tt>init</tt>
|
||||
---
|
||||
|
||||
# `init` Command
|
||||
|
|
@ -37,7 +36,6 @@ for the ones that are missing.
|
|||
|
||||
`packer init -upgrade` will try to get the latest versions for all plugins.
|
||||
|
||||
|
||||
Import a plugin using the [`required_plugin`](/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements)
|
||||
block :
|
||||
|
||||
|
|
@ -55,6 +53,7 @@ packer {
|
|||
HashiCorp does not officially verify third party Packer plugins, plugins not under the HashiCorp namespace `hashicorp/*`; as with all open source tools, please do your own due diligence when using a new tool.
|
||||
|
||||
## Plugin Selection
|
||||
|
||||
Plugin selection depends on the source and version constraints defined within the `required_plugins` block.
|
||||
For each of the required plugins Packer will query the source repository `github.com/azr/happycloud` whose fully qualified address
|
||||
is `https://github.com/azr/packer-plugin-happycloud` for a plugin matching the version constraints for the host operating system.
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ description: >
|
|||
|
||||
provisioners it defines and the order they'll run, and more.
|
||||
page_title: packer inspect - Commands
|
||||
sidebar_title: <tt>inspect</tt>
|
||||
---
|
||||
|
||||
# `inspect` Command
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: |
|
|||
success, and a non-zero exit status on failure. Additionally, if a template
|
||||
doesn't validate, any error messages will be outputted.
|
||||
page_title: packer validate - Commands
|
||||
sidebar_title: <tt>validate</tt>
|
||||
---
|
||||
|
||||
# `validate` Command
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Communicators are the mechanism Packer uses to upload files, execute
|
||||
scripts, etc. with the machine being created.
|
||||
page_title: Communicators
|
||||
sidebar_title: Communicators
|
||||
---
|
||||
|
||||
# Communicators
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The SSH communicator uses SSH to upload files, execute scripts, etc. on
|
||||
the machine being created.
|
||||
page_title: Communicators - SSH
|
||||
sidebar_title: SSH
|
||||
---
|
||||
|
||||
# SSH Communicator
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Communicators are the mechanism Packer uses to upload files, execute scripts,
|
||||
etc. with the machine being created.
|
||||
page_title: Communicators - Templates
|
||||
sidebar_title: WINRM
|
||||
---
|
||||
|
||||
# WinRM Communicator
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
There are various ways to configure Packer. By default Packer will use known folders,
|
||||
which can be changed by using environment variables.
|
||||
page_title: Configuring Packer
|
||||
sidebar_title: Configuring Packer
|
||||
---
|
||||
|
||||
# Configuring Packer
|
||||
|
|
@ -21,7 +20,7 @@ The home directory of packer will be the first one of the following env values
|
|||
to be set :
|
||||
|
||||
| unix | windows |
|
||||
|------------------------|-----------------------|
|
||||
| ---------------------- | --------------------- |
|
||||
| `${PACKER_CONFIG_DIR}` | `%PACKER_CONFIG_DIR%` |
|
||||
| `${APPDATA}` | `%APPDATA%` |
|
||||
| `${HOME}` | `%HOME%` |
|
||||
|
|
@ -36,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/` |
|
||||
|
||||
|
|
@ -48,16 +47,17 @@ Packer's configuration directory can potentialy contain plugins and internal
|
|||
Packer files. The config dir of packer will be looked up on the following paths:
|
||||
|
||||
| unix | windows |
|
||||
|-----------------------------|-----------------------------|
|
||||
| --------------------------- | --------------------------- |
|
||||
| `PACKER_HOME_DIR/.packer.d` | `PACKER_HOME_DIR/packer.d/` |
|
||||
|
||||
Examples:
|
||||
* On a 'unix' system, if the `$PACKER_CONFIG_DIR` env var is set to
|
||||
|
||||
- On a 'unix' system, if the `$PACKER_CONFIG_DIR` env var is set to
|
||||
`/home/packer`, the config directory will be: `/home/packer/.packer.d/` and
|
||||
other values will not be checked.
|
||||
* On a 'unix' system, if the `HOME` env var is `/home/azr` or the `USER` env var
|
||||
- On a 'unix' system, if the `HOME` env var is `/home/azr` or the `USER` env var
|
||||
is `azr`, then the config directory will default to `/home/azr/.packer.d/`.
|
||||
* On a 'windows' system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the
|
||||
- On a 'windows' system, if the `PACKER_CONFIG_DIR` env var is set to `C:/`,the
|
||||
config directory will be: `C:/packer.d/` and other values will not be checked.
|
||||
|
||||
## Packer's plugin directory
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Data sources allow data to be fetched for use in Packer configuration. Use of data sources
|
||||
allows a build to use information defined outside of Packer.
|
||||
page_title: Data Sources
|
||||
sidebar_title: Data Sources
|
||||
---
|
||||
|
||||
# Data Sources
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
certain things may not work entirely correctly, or may not appear to work
|
||||
correctly.
|
||||
page_title: Debugging - Other
|
||||
sidebar_title: Debugging
|
||||
---
|
||||
|
||||
# Debugging Packer Builds
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Installing Packer is simple. You can download a precompiled binary or compile
|
||||
from source. This page details both methods.
|
||||
page_title: Install
|
||||
sidebar_title: Installing Packer
|
||||
---
|
||||
|
||||
# Install Packer
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
It is possible to write custom builders using the Packer plugin interface, and
|
||||
this page documents how to do that.
|
||||
page_title: Custom Builders - Extending
|
||||
sidebar_title: Custom Builders
|
||||
---
|
||||
|
||||
# Custom Builders
|
||||
|
|
@ -25,7 +24,6 @@ basics](/docs/extending/plugins).
|
|||
recommend getting comfortable with using Packer and its officially maintained
|
||||
plugins before you dive into writing plugins of your own.
|
||||
|
||||
|
||||
Custom plugins are written in [golang](https://golang.org/), so this guide
|
||||
assumes that you have some familiarity with that programming language.
|
||||
|
||||
|
|
@ -53,8 +51,7 @@ function, check our
|
|||
|
||||
The `Prepare` method for each builder will be called by the Packer core
|
||||
at the beginning of the build. Its purpose is to parse and validate the
|
||||
configuration template provided to Packer with `packer build
|
||||
your_packer_template.json`, but not to execute API calls or begin creating any
|
||||
configuration template provided to Packer with `packer build your_packer_template.json`, but not to execute API calls or begin creating any
|
||||
resources or artifacts.
|
||||
|
||||
The configuration from your Packer template is passed into the Prepare() method
|
||||
|
|
@ -144,7 +141,6 @@ The `Cancel` method can be called at any time and requests cancellation of any
|
|||
builder run in progress. This method should block until the run actually stops.
|
||||
Note that the Cancel method will not be called by Packer versions >= 1.4.0.
|
||||
|
||||
|
||||
#### Context cancellation ( from Packer v1.4 )
|
||||
|
||||
The `<-ctx.Done()` can unblock at any time and signifies request for
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: >
|
|||
Packer Data Sources are the components of Packer that allow data to be fetched for use within the Packer configuration.
|
||||
Use of data sources allows a build to use information defined outside of Packer.
|
||||
page_title: Custom Data Sources - Extending
|
||||
sidebar_title: Custom Data Sources
|
||||
---
|
||||
|
||||
# Custom Data Sources
|
||||
|
|
@ -87,7 +86,6 @@ Execute command will fetch the data and return it as a cty.Value.
|
|||
To get the equivalent cty.Value from an output config, we suggest using our
|
||||
[packer-plugin-sdk hcl2helper functions](https://github.com/hashicorp/packer-plugin-sdk/blob/v0.0.7/hcl2helper/values.go).
|
||||
|
||||
|
||||
## Scaffolding template
|
||||
|
||||
To make your experience easier when developing your new data source plugin, we provide you a
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
|
||||
into another, for example by compressing files, or uploading them.
|
||||
page_title: Custom Post-Processors - Extending
|
||||
sidebar_title: Custom Post-Processors
|
||||
---
|
||||
|
||||
# Custom Post-Processors
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ description: >
|
|||
|
||||
within the machines.
|
||||
page_title: Custom Provisioners - Extending
|
||||
sidebar_title: Custom Provisioners
|
||||
---
|
||||
|
||||
# Custom Provisioners
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
infinite, Packer supports plugins for builders, provisioners, and
|
||||
post-processors.
|
||||
page_title: Extending
|
||||
sidebar_title: Extending Packer
|
||||
---
|
||||
|
||||
# Extending Packer
|
||||
|
|
@ -43,6 +42,7 @@ provisioners, post-processors, and data sources.
|
|||
Each of these components has a corresponding [interface](https://golang.org/doc/effective_go.html#interfaces_and_types).
|
||||
|
||||
All you need to do to create a plugin is:
|
||||
|
||||
1. create an implementation of the desired interface, and
|
||||
2. serve it using the server provided in the [packer-plugin-sdk](https://github.com/hashicorp/packer-plugin-sdk).
|
||||
|
||||
|
|
@ -110,10 +110,10 @@ be referenced by using only the plugin name. For example:
|
|||
If your plugin is named `packer-plugin-my`, the above set definition would make
|
||||
the following components available:
|
||||
|
||||
* the `my-example` builder
|
||||
* the `my` builder
|
||||
* the `my-foo` post-processor
|
||||
* the `my-bar` provisioner
|
||||
- the `my-example` builder
|
||||
- the `my` builder
|
||||
- the `my-foo` post-processor
|
||||
- the `my-bar` provisioner
|
||||
|
||||
</Tab>
|
||||
|
||||
|
|
@ -152,7 +152,6 @@ because the `packer init` command only supports multi-component plugins.
|
|||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
|
||||
Next, build your plugin as you would any other Go application. The resulting
|
||||
binary is the plugin that can be installed using
|
||||
[standard installation procedures](/docs/plugins#installing-plugins).
|
||||
|
|
@ -190,7 +189,7 @@ the logs to be helpful.
|
|||
|
||||
`packer init` does not work using a centralized registry. Instead, it requires
|
||||
you to publish your plugin in a GitHub repo with the name
|
||||
`packer-plugin-*` where * represents the name of your plugin. You also need to
|
||||
`packer-plugin-*` where \* represents the name of your plugin. You also need to
|
||||
create a GitHub release of your plugin with specific assets for the
|
||||
`packer init` download to work. We provide a pre-defined release workflow
|
||||
configuration using
|
||||
|
|
@ -200,6 +199,7 @@ release contains the right assets with the right names for Packer to leverage
|
|||
`packer init` installation.
|
||||
|
||||
Here's what you need to create releases using GitHub Actions:
|
||||
|
||||
1. Generate a GPG key to be used when signing releases (See [GitHub's detailed instructions](https://docs.github.com/en/free-pro-team@latest/github/authenticating-to-github/generating-a-new-gpg-key)
|
||||
for help with this step)
|
||||
2. Copy the [GoReleaser configuration from the packer-plugin-scaffolding repository](https://github.com/hashicorp/packer-plugin-scaffolding/blob/main/.goreleaser.yml) to the root of your repository.
|
||||
|
|
@ -296,9 +296,9 @@ If a plugin maintainer wishes to only include a specific version of released doc
|
|||
|
||||
Here's a non exaustive list of Packer plugins that you can check out:
|
||||
|
||||
* [github.com/hashicorp/packer-plugin-docker](https://github.com/hashicorp/packer-plugin-docker)
|
||||
* [github.com/exoscale/packer-plugin-exoscale](https://github.com/exoscale/packer-plugin-exoscale)
|
||||
* [github.com/sylviamoss/packer-plugin-comment](https://github.com/sylviamoss/packer-plugin-comment)
|
||||
- [github.com/hashicorp/packer-plugin-docker](https://github.com/hashicorp/packer-plugin-docker)
|
||||
- [github.com/exoscale/packer-plugin-exoscale](https://github.com/exoscale/packer-plugin-exoscale)
|
||||
- [github.com/sylviamoss/packer-plugin-comment](https://github.com/sylviamoss/packer-plugin-comment)
|
||||
|
||||
Looking at their code will give you good examples.
|
||||
|
||||
|
|
@ -314,8 +314,8 @@ scope of a plugin.
|
|||
|
||||
Making your unpublished plugin available to Packer is possible by either:
|
||||
|
||||
* Starting Packer from the directory where the plugin binary is located.
|
||||
* Putting the plugin binary in the same directory as Packer.
|
||||
- Starting Packer from the directory where the plugin binary is located.
|
||||
- Putting the plugin binary in the same directory as Packer.
|
||||
|
||||
In both these cases, if the binary is called `packer-plugin-myawesomecloud` and
|
||||
defines an `ebs` builder then you will be able to use an `myawesomecloud-ebs`
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: |
|
|||
the core source code. Packer plugins are able to add new builders,
|
||||
provisioners, hooks, and more.
|
||||
page_title: Plugins
|
||||
sidebar_title: Packer Plugins
|
||||
---
|
||||
|
||||
# Packer Plugins
|
||||
|
|
@ -40,9 +39,8 @@ build.
|
|||
|
||||
Packer plugins are published and maintained by a variety of sources, including HashiCorp, and the Packer community. The Packer website uses tiers and badges to denote the source of a provider. Additionally, namespaces are used to help users identify the organization or publisher responsible for the integration, as shown in the table below.
|
||||
|
||||
|
||||
| Tier | Description | Namespace |
|
||||
| ---------| ------------| ----------|
|
||||
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
|
||||
| <PluginTierLabel tier="official" /> | Official plugins are owned and maintained by HashiCorp. | hashicorp |
|
||||
| <PluginTierLabel tier="community" /> | Community providers are published by individual maintainers, groups of maintainers, or other members of the Packer community. | Third-party organization or maintainer's individual account |
|
||||
|
||||
|
|
@ -65,7 +63,7 @@ it is a single-component plugin.
|
|||
<Tab heading="Packer init (from Packer v1.7.0)">
|
||||
|
||||
~> **Note**: Only _multi-component plugin binaries_ -- that is plugins named
|
||||
packer-plugin-*, like the `packer-plugin-amazon` -- are expected to work with
|
||||
packer-plugin-\*, like the `packer-plugin-amazon` -- are expected to work with
|
||||
Packer init. The legacy `builder`, `post-processor` and `provisioner` plugin
|
||||
types will keep on being detected but Packer cannot install them automatically.
|
||||
If a plugin you use has not been upgraded to use the multi-component plugin
|
||||
|
|
@ -103,10 +101,11 @@ repository owned by user or organization `azr` named
|
|||
`packer-plugin-myawesomecloud` and `packer-plugin-happycloud`.
|
||||
|
||||
## Names and Addresses
|
||||
|
||||
Each plugin has two identifiers:
|
||||
|
||||
* A `source` address, which is only necessary when requiring a plugin outside the HashiCorp domain.
|
||||
* A unique **local name**, which is used everywhere else in a Packer
|
||||
- A `source` address, which is only necessary when requiring a plugin outside the HashiCorp domain.
|
||||
- A unique **local name**, which is used everywhere else in a Packer
|
||||
configuration.
|
||||
|
||||
### Local Names
|
||||
|
|
@ -163,14 +162,14 @@ follows:
|
|||
|
||||
`<HOSTNAME>/<NAMESPACE>/<TYPE>`
|
||||
|
||||
* **Hostname:** The hostname of the location/service that
|
||||
- **Hostname:** The hostname of the location/service that
|
||||
distributes the plugin. Currently, the only valid "hostname" is github.com,
|
||||
but we plan to eventually support plugins downloaded from other domains.
|
||||
|
||||
* **Namespace:** An organizational namespace within the specified host.
|
||||
- **Namespace:** An organizational namespace within the specified host.
|
||||
This often is the organization that publishes the plugin.
|
||||
|
||||
* **Type:** A short name for the platform or system the plugin manages. The
|
||||
- **Type:** A short name for the platform or system the plugin manages. The
|
||||
type is usually the plugin's preferred local name.
|
||||
|
||||
For example, the fictional `myawesomecloud` plugin could belong to the
|
||||
|
|
@ -192,6 +191,7 @@ various outputs, like error messages.
|
|||
## Implicit Github urls
|
||||
|
||||
Using the following example :
|
||||
|
||||
```hcl
|
||||
required_plugins {
|
||||
happycloud = {
|
||||
|
|
@ -202,7 +202,8 @@ Using the following example :
|
|||
```
|
||||
|
||||
The plugin getter will look for plugins located at:
|
||||
* github.com/azr/packer-plugin-happycloud
|
||||
|
||||
- github.com/azr/packer-plugin-happycloud
|
||||
|
||||
Packer will error if you set the `packer-plugin-` prefix in a `source`. This
|
||||
will avoid conflicting with other plugins for other tools, like Terraform.
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Packer Alicloud Import post-processor takes a RAW or VHD artifact from
|
||||
various builders and imports it to an Alicloud customized image list.
|
||||
page_title: Alicloud Import Post-Processor
|
||||
sidebar_title: Alicloud Import
|
||||
---
|
||||
|
||||
# Alicloud Import Post-Processor
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ description: >
|
|||
|
||||
instance.
|
||||
page_title: Artifice - Post-Processors
|
||||
sidebar_title: Artifice
|
||||
---
|
||||
|
||||
# Artifice Post-Processor
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
artifact, compute it checksum and pass to next post-processor original
|
||||
artifacts and checksum files.
|
||||
page_title: Checksum - Post-Processors
|
||||
sidebar_title: Checksum
|
||||
---
|
||||
|
||||
# Checksum Post-Processor
|
||||
|
|
@ -24,7 +23,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-push), or
|
||||
[docker-push](/docs/post-processors/docker/docker-push), or
|
||||
a third-party post-processor.
|
||||
|
||||
## Basic example
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
|
||||
can run alongside Packer with minimal extra effort.
|
||||
page_title: Community - Post-Processors
|
||||
sidebar_title: Community-Supported
|
||||
---
|
||||
|
||||
# Community Post-Processors
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Packer compress post-processor takes an artifact with files (such as from
|
||||
VMware or VirtualBox) and compresses the artifact into a single archive.
|
||||
page_title: Compress - Post-Processors
|
||||
sidebar_title: Compress
|
||||
---
|
||||
|
||||
# Compress Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Packer DigitalOcean Import post-processor takes an image artifact
|
||||
from various builders and imports it to DigitalOcean.
|
||||
page_title: DigitalOcean Import - Post-Processors
|
||||
sidebar_title: DigitalOcean Import
|
||||
---
|
||||
|
||||
# DigitalOcean Import Post-Processor
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
exported images can be easily shared and uploaded to other Google Cloud
|
||||
Projects.
|
||||
page_title: Google Compute Image Exporter - Post-Processors
|
||||
sidebar_title: Google Compute Export
|
||||
---
|
||||
|
||||
# Google Compute Image Exporter Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Google Compute Image Import post-processor takes a compressed raw disk
|
||||
image and imports it to a GCE image available to Google Compute Engine.
|
||||
page_title: Google Compute Image Import - Post-Processors
|
||||
sidebar_title: Google Compute Import
|
||||
---
|
||||
|
||||
# Google Compute Image Import Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
Post-processors run after the image is built by the builder and provisioned by
|
||||
the provisioner(s).
|
||||
page_title: Post-Processors
|
||||
sidebar_title: Post-Processors
|
||||
---
|
||||
|
||||
# Post-Processors
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: >
|
|||
The manifest post-processor writes a JSON file with the build artifacts and
|
||||
IDs from a packer run.
|
||||
page_title: Manifest - Post-Processors
|
||||
sidebar_title: Manifest
|
||||
---
|
||||
|
||||
# Manifest Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The shell-local Packer post processor enables users to do some post processing
|
||||
after artifacts have been built.
|
||||
page_title: Local Shell - Post-Processors
|
||||
sidebar_title: Shell (Local)
|
||||
---
|
||||
|
||||
# Local Shell Post Processor
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: >
|
|||
artifact from various builders and imports it to UCloud customized image list
|
||||
for UHost Instance.
|
||||
page_title: UCloud Import Post-Processors
|
||||
sidebar_title: UCloud Import
|
||||
---
|
||||
|
||||
# UCloud Import Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The Vagrant Cloud post-processor enables the upload of Vagrant boxes to
|
||||
Vagrant Cloud.
|
||||
page_title: Vagrant Cloud - Post-Processors
|
||||
sidebar_title: Vagrant Cloud
|
||||
---
|
||||
|
||||
# Vagrant Cloud Post-Processor
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ description: >
|
|||
|
||||
distributed by Vagrant are created.
|
||||
page_title: Vagrant - Post-Processors
|
||||
sidebar_title: Vagrant
|
||||
---
|
||||
|
||||
# Vagrant Post-Processor
|
||||
|
|
|
|||
|
|
@ -5,7 +5,6 @@ description: >
|
|||
[vSphere](/docs/post-processors/vsphere) post-processor, marks the VM as a
|
||||
template, and leaves it in the path of your choice.
|
||||
page_title: vSphere Template - Post-Processors
|
||||
sidebar_title: vSphere Template
|
||||
---
|
||||
|
||||
# vSphere Template Post-Processor
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: >
|
|||
The Packer vSphere post-processor takes an artifact and uploads it to a
|
||||
vSphere endpoint.
|
||||
page_title: vSphere - Post-Processors
|
||||
sidebar_title: vSphere
|
||||
---
|
||||
|
||||
# vSphere Post-Processor
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
|
||||
images can be easily shared and uploaded to other Yandex.Cloud Cloud folders.
|
||||
page_title: Yandex.Cloud Compute Image Exporter - Post-Processors
|
||||
sidebar_title: Yandex.Cloud Compute Export
|
||||
---
|
||||
|
||||
# Yandex.Cloud Compute Image Exporter Post-Processor
|
||||
|
|
|
|||
|
|
@ -4,7 +4,6 @@ description: >
|
|||
qcow2 image (or from provided Storage object in near future). It uploads qcow2
|
||||
to Yandex Object Storage and create new one Compute Image in target folder.
|
||||
page_title: Yandex.Cloud Compute Image Import - Post-Processors
|
||||
sidebar_title: Yandex.Cloud Compute Import
|
||||
---
|
||||
|
||||
# Yandex.Cloud Compute Image Import Post-Processor
|
||||
|
|
|
|||
|
|
@ -6,7 +6,6 @@ description: >
|
|||
Playbooks and Roles can be uploaded from your build machine (the one running
|
||||
Packer) to the vm.
|
||||
page_title: Ansible Local - Provisioners
|
||||
sidebar_title: Ansible Local
|
||||
---
|
||||
|
||||
# Ansible Local Provisioner
|
||||
|
|
|
|||
|
|
@ -3,7 +3,6 @@ description: |
|
|||
The ansible Packer provisioner allows Ansible playbooks to be run to provision
|
||||
the machine.
|
||||
page_title: Ansible - Provisioners
|
||||
sidebar_title: Ansible (Remote)
|
||||
---
|
||||
|
||||
# Ansible Provisioner
|
||||
|
|
|
|||
|
|
@ -7,7 +7,6 @@ description: >
|
|||
|
||||
particular part of the provisioning process.
|
||||
page_title: breakpoint - Provisioners
|
||||
sidebar_title: Breakpoint
|
||||
---
|
||||
|
||||
# Breakpoint Provisioner
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ description: >
|
|||
|
||||
remote Chef Server to provision the machine.
|
||||
page_title: Chef Client - Provisioners
|
||||
sidebar_title: Chef Client
|
||||
---
|
||||
|
||||
# Chef Client Provisioner
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue