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)
|
||||
|
|
@ -261,36 +260,36 @@ build {
|
|||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"client_id": "{{env `ARM_CLIENT_ID`}}",
|
||||
"client_secret": "{{env `ARM_CLIENT_SECRET`}}",
|
||||
"subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
|
||||
"resource_group": "{{env `ARM_IMAGE_RESOURCEGROUP_ID`}}"
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "azure-chroot",
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"client_id": "{{env `ARM_CLIENT_ID`}}",
|
||||
"client_secret": "{{env `ARM_CLIENT_SECRET`}}",
|
||||
"subscription_id": "{{env `ARM_SUBSCRIPTION_ID`}}",
|
||||
"resource_group": "{{env `ARM_IMAGE_RESOURCEGROUP_ID`}}"
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "azure-chroot",
|
||||
|
||||
"client_id": "{{user `client_id`}}",
|
||||
"client_secret": "{{user `client_secret`}}",
|
||||
"subscription_id": "{{user `subscription_id`}}",
|
||||
"client_id": "{{user `client_id`}}",
|
||||
"client_secret": "{{user `client_secret`}}",
|
||||
"subscription_id": "{{user `subscription_id`}}",
|
||||
|
||||
"image_resource_id": "/subscriptions/{{user `subscription_id`}}/resourceGroups/{{user `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
|
||||
"image_resource_id": "/subscriptions/{{user `subscription_id`}}/resourceGroups/{{user `resource_group`}}/providers/Microsoft.Compute/images/MyDebianOSImage-{{timestamp}}",
|
||||
|
||||
"source": "credativ:Debian:9:latest"
|
||||
}
|
||||
],
|
||||
"provisioners": [
|
||||
{
|
||||
"inline": ["apt-get update", "apt-get upgrade -y"],
|
||||
"inline_shebang": "/bin/sh -x",
|
||||
"type": "shell"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
"source": "credativ:Debian:9:latest"
|
||||
}
|
||||
],
|
||||
"provisioners": [
|
||||
{
|
||||
"inline": ["apt-get update", "apt-get upgrade -y"],
|
||||
"inline_shebang": "/bin/sh -x",
|
||||
"type": "shell"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -67,4 +66,4 @@ In addition to the builder options, a
|
|||
|
||||
@include 'packer-plugin-sdk/communicator/SSH-not-required.mdx'
|
||||
|
||||
@include 'packer-plugin-sdk/communicator/SSH-Private-Key-File-not-required.mdx'
|
||||
@include 'packer-plugin-sdk/communicator/SSH-Private-Key-File-not-required.mdx'
|
||||
|
|
|
|||
|
|
@ -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,8 +46,9 @@ 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>"
|
||||
"<https://cloudpanel-api.1and1.com/v1>"
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
||||
## Example
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -189,18 +188,19 @@ can also be supplied to override the typical auto-generated key:
|
|||
- `use_private_ip` (boolean) - Use private ip addresses to connect to the
|
||||
instance via ssh.
|
||||
|
||||
- `shape_config` (object) - The shape configuration for an instance. The shape configuration determines the resources
|
||||
- `shape_config` (object) - The shape configuration for an instance. The shape configuration determines the resources
|
||||
allocated to an instance. Options:
|
||||
- `ocpus` (required when using flexible shapes or memory_in_gbs is set) (float32) - The total number of OCPUs available to the instance.
|
||||
- `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
|
||||
"user_data_file" values will have precedence. An instance's metadata can
|
||||
be obtained from at [http://169.254.169.254](http://169.254.169.254) on
|
||||
the launched instance.
|
||||
key/value pairs provided in the configuration. While this can be used to
|
||||
set metadata\["user_data"\] the explicit "user_data" and
|
||||
"user_data_file" values will have precedence. An instance's metadata can
|
||||
be obtained from at [http://169.254.169.254](http://169.254.169.254) on
|
||||
the launched instance.
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
||||
- `user_data` (string) - User data to be used by cloud-init. See [the Oracle
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -63,7 +62,7 @@ can also be supplied to override the typical auto-generated key:
|
|||
- `snapshot_password` (string) - Password for the snapshot.
|
||||
<!-- markdown-link-check-disable -->
|
||||
- `url` (string) - Endpoint for the ProfitBricks REST API. Default URL
|
||||
"<https://api.profitbricks.com/rest/v2>"
|
||||
"<https://api.profitbricks.com/rest/v2>"
|
||||
<!-- markdown-link-check-enable -->
|
||||
|
||||
## Example
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -223,7 +222,7 @@ builder.
|
|||
Defaults to `lsi`.
|
||||
|
||||
- `cloud_init` (bool) - If true, add a Cloud-Init CDROM drive after the virtual machine has been converted to a template.
|
||||
Defaults to `false`.
|
||||
Defaults to `false`.
|
||||
|
||||
- `cloud_init_storage_pool` - (string) - Name of the Proxmox storage pool
|
||||
to store the Cloud-Init CDROM on. If not given, the storage pool of the boot device will be used.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -185,13 +184,13 @@ build {
|
|||
|
||||
## Regarding output directory and new box
|
||||
|
||||
After Packer completes building and provisioning a new Vagrant Box file, it is worth
|
||||
noting that the new box file will need to be added to Vagrant. For a beginner to Packer
|
||||
After Packer completes building and provisioning a new Vagrant Box file, it is worth
|
||||
noting that the new box file will need to be added to Vagrant. For a beginner to Packer
|
||||
and Vagrant, it may seem as if a simple 'vagrant up' in the output directory will run the
|
||||
the newly created Box. This is not the case.
|
||||
the newly created Box. This is not the case.
|
||||
|
||||
Rather, create a new directory (to avoid Vagarant init collisions), add the new
|
||||
package.box to Vagrant and init. Then run vagrant up to bring up the new box created
|
||||
Rather, create a new directory (to avoid Vagarant init collisions), add the new
|
||||
package.box to Vagrant and init. Then run vagrant up to bring up the new box created
|
||||
by Packer. You will now be able to connect to the new box with provisioned changes.
|
||||
|
||||
```
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -35,16 +34,13 @@ From **v1.7.1**, the `hcl2_upgrade` command can upgrade a variables file.
|
|||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"aws_region": null,
|
||||
"aws_secondary_region": "{{ env `AWS_DEFAULT_REGION` }}",
|
||||
"aws_secret_key": "",
|
||||
"aws_access_key": "",
|
||||
},
|
||||
"sensitive-variables": [
|
||||
"aws_secret_key",
|
||||
"aws_access_key",
|
||||
]
|
||||
"variables": {
|
||||
"aws_region": null,
|
||||
"aws_secondary_region": "{{ env `AWS_DEFAULT_REGION` }}",
|
||||
"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,17 +47,18 @@ 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
|
||||
`/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
|
||||
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
|
||||
config directory will be: `C:/packer.d/` and other values will not be checked.
|
||||
Examples:
|
||||
|
||||
- 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
|
||||
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
|
||||
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
|
||||
|
|
@ -107,7 +104,7 @@ the machine, provision it, and create the resulting machine image, which is
|
|||
returned as an implementation of the `packer.Artifact` interface.
|
||||
|
||||
The `Run` method takes three parameters. The context.Context used to cancel the
|
||||
build. The `packer.Ui` object is used to send output to the console.
|
||||
build. The `packer.Ui` object is used to send output to the console.
|
||||
`packer.Hook` is used to execute hooks, which are covered in more detail in the
|
||||
Provisioning section below.
|
||||
|
||||
|
|
@ -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,8 +42,9 @@ 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).
|
||||
|
||||
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).
|
||||
|
||||
The core and the SDK handle all of the communication details inside the server.
|
||||
|
||||
|
|
@ -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,28 +199,29 @@ 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)
|
||||
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.
|
||||
```sh
|
||||
curl -L -o .goreleaser.yml \
|
||||
https://raw.githubusercontent.com/hashicorp/packer-plugin-scaffolding/main/.goreleaser.yml
|
||||
```
|
||||
```sh
|
||||
curl -L -o .goreleaser.yml \
|
||||
https://raw.githubusercontent.com/hashicorp/packer-plugin-scaffolding/main/.goreleaser.yml
|
||||
```
|
||||
3. Copy the [GitHub Actions workflow from the packer-plugin-scaffolding repository](https://github.com/hashicorp/packer-plugin-scaffolding/blob/main/.github/workflows/release.yml) to `.github/workflows/release.yml` in your repository.
|
||||
```sh
|
||||
mkdir -p .github/workflows &&
|
||||
curl -L -o .github/workflows/release.yml \
|
||||
https://raw.githubusercontent.com/hashicorp/packer-plugin-scaffolding/main/.github/workflows/release.yml
|
||||
```
|
||||
```sh
|
||||
mkdir -p .github/workflows &&
|
||||
curl -L -o .github/workflows/release.yml \
|
||||
https://raw.githubusercontent.com/hashicorp/packer-plugin-scaffolding/main/.github/workflows/release.yml
|
||||
```
|
||||
4. Go to your repository page on GitHub and navigate to Settings > Secrets. Add
|
||||
the following secrets:
|
||||
- `GPG_PRIVATE_KEY` - Your ASCII-armored GPG private key. You can export this with `gpg --armor --export-secret-keys [key ID or email]`.
|
||||
- `PASSPHRASE` - The passphrase for your GPG private key.
|
||||
the following secrets:
|
||||
- `GPG_PRIVATE_KEY` - Your ASCII-armored GPG private key. You can export this with `gpg --armor --export-secret-keys [key ID or email]`.
|
||||
- `PASSPHRASE` - The passphrase for your GPG private key.
|
||||
5. Push a new valid version tag (e.g. `v1.2.3`) to test that the GitHub Actions
|
||||
releaser is working. The tag must be a valid
|
||||
[Semantic Version](https://semver.org/) preceded with a `v`. Once the tag is pushed, the github actions you just configured will automatically build release binaries that Packer can download using `packer init`. For more details on how
|
||||
to install a plugin using `packer init`, see the
|
||||
[init docs](/docs/commands/init).
|
||||
releaser is working. The tag must be a valid
|
||||
[Semantic Version](https://semver.org/) preceded with a `v`. Once the tag is pushed, the github actions you just configured will automatically build release binaries that Packer can download using `packer init`. For more details on how
|
||||
to install a plugin using `packer init`, see the
|
||||
[init docs](/docs/commands/init).
|
||||
|
||||
### Registering Plugin Documentation
|
||||
|
||||
|
|
@ -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,11 +39,10 @@ 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 |
|
||||
| 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 |
|
||||
|
||||
## Installing Plugins
|
||||
|
||||
|
|
@ -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
|
||||
|
|
@ -74,39 +72,40 @@ architecture, contact your maintainer to request an upgrade.
|
|||
### Create a required_plugins block
|
||||
|
||||
1. Add a
|
||||
[`required_plugins`](/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements)
|
||||
block to your [packer block](/docs/templates/hcl_templates/blocks/packer). Each block will tell Packer what version(s) of a
|
||||
particular plugin can be installed. Make sure to set a valid [version
|
||||
constraint string](/docs/templates/hcl_templates/blocks/packer#version-constraints).
|
||||
[`required_plugins`](/docs/templates/hcl_templates/blocks/packer#specifying-plugin-requirements)
|
||||
block to your [packer block](/docs/templates/hcl_templates/blocks/packer). Each block will tell Packer what version(s) of a
|
||||
particular plugin can be installed. Make sure to set a valid [version
|
||||
constraint string](/docs/templates/hcl_templates/blocks/packer#version-constraints).
|
||||
|
||||
Here is an example `required_plugins` block:
|
||||
|
||||
```hcl
|
||||
packer {
|
||||
required_plugins {
|
||||
myawesomecloud = {
|
||||
version = ">= 2.7.0"
|
||||
source = "github.com/azr/myawesomecloud"
|
||||
}
|
||||
happycloud = {
|
||||
version = ">= 1.1.3"
|
||||
source = "github.com/azr/happycloud"
|
||||
}
|
||||
```hcl
|
||||
packer {
|
||||
required_plugins {
|
||||
myawesomecloud = {
|
||||
version = ">= 2.7.0"
|
||||
source = "github.com/azr/myawesomecloud"
|
||||
}
|
||||
happycloud = {
|
||||
version = ">= 1.1.3"
|
||||
source = "github.com/azr/happycloud"
|
||||
}
|
||||
}
|
||||
```
|
||||
}
|
||||
```
|
||||
|
||||
2. Run [`packer init`](/docs/commands/init) from your project directory (the
|
||||
directory containing your Packer templates) to install all missing plugin
|
||||
binaries. Given the above example, Packer will try to look for a GitHub
|
||||
repository owned by user or organization `azr` named
|
||||
`packer-plugin-myawesomecloud` and `packer-plugin-happycloud`.
|
||||
directory containing your Packer templates) to install all missing plugin
|
||||
binaries. Given the above example, Packer will try to look for a GitHub
|
||||
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
|
||||
|
|
@ -145,64 +144,64 @@ build {
|
|||
</Tab>
|
||||
<Tab heading="JSON">
|
||||
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"account_file": "account.json",
|
||||
"bucket": "my-bucket",
|
||||
"project": "my-project",
|
||||
"serial": ""
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "qemu",
|
||||
"accelerator": "kvm",
|
||||
"boot_command": [
|
||||
"<tab> console=ttyS0,115200n8 inst.text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/fedora-31-ks.cfg rd.live.check=0<enter><wait>"
|
||||
],
|
||||
"disk_size": "15000",
|
||||
"format": "raw",
|
||||
"iso_checksum": "sha256:225ebc160e40bb43c5de28bad9680e3a78a9db40c9e3f4f42f3ee3f10f95dbeb",
|
||||
"iso_url": "https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/31/Server/x86_64/iso/Fedora-Server-dvd-x86_64-31-1.9.iso",
|
||||
"headless": "true",
|
||||
"http_directory": "http",
|
||||
"http_port_max": "10089",
|
||||
"http_port_min": "10082",
|
||||
"output_directory": "output",
|
||||
"shutdown_timeout": "30m",
|
||||
"shutdown_command": "echo 'vagrant'|sudo -S shutdown -P now",
|
||||
"ssh_username": "vagrant",
|
||||
"ssh_password": "vagrant",
|
||||
"vm_name": "disk.raw",
|
||||
"qemu_binary": "/usr/bin/kvm",
|
||||
"qemuargs": [
|
||||
["-m", "1024"],
|
||||
["-cpu", "host"],
|
||||
["-chardev", "tty,id=pts,path={{user `serial`}}"],
|
||||
["-device", "isa-serial,chardev=pts"],
|
||||
["-device", "virtio-net,netdev=user.0"]
|
||||
]
|
||||
}
|
||||
],
|
||||
"post-processors": [
|
||||
[
|
||||
{
|
||||
"type": "compress",
|
||||
"output": "output/disk.raw.tar.gz"
|
||||
},
|
||||
{
|
||||
"type": "googlecompute-import",
|
||||
"project_id": "{{user `project`}}",
|
||||
"account_file": "{{user `account_file`}}",
|
||||
"bucket": "{{user `bucket`}}",
|
||||
"image_name": "fedora31-server-packertest",
|
||||
"image_description": "Fedora 31 Server",
|
||||
"image_family": "fedora31-server"
|
||||
}
|
||||
```json
|
||||
{
|
||||
"variables": {
|
||||
"account_file": "account.json",
|
||||
"bucket": "my-bucket",
|
||||
"project": "my-project",
|
||||
"serial": ""
|
||||
},
|
||||
"builders": [
|
||||
{
|
||||
"type": "qemu",
|
||||
"accelerator": "kvm",
|
||||
"boot_command": [
|
||||
"<tab> console=ttyS0,115200n8 inst.text inst.ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/fedora-31-ks.cfg rd.live.check=0<enter><wait>"
|
||||
],
|
||||
"disk_size": "15000",
|
||||
"format": "raw",
|
||||
"iso_checksum": "sha256:225ebc160e40bb43c5de28bad9680e3a78a9db40c9e3f4f42f3ee3f10f95dbeb",
|
||||
"iso_url": "https://download-ib01.fedoraproject.org/pub/fedora/linux/releases/31/Server/x86_64/iso/Fedora-Server-dvd-x86_64-31-1.9.iso",
|
||||
"headless": "true",
|
||||
"http_directory": "http",
|
||||
"http_port_max": "10089",
|
||||
"http_port_min": "10082",
|
||||
"output_directory": "output",
|
||||
"shutdown_timeout": "30m",
|
||||
"shutdown_command": "echo 'vagrant'|sudo -S shutdown -P now",
|
||||
"ssh_username": "vagrant",
|
||||
"ssh_password": "vagrant",
|
||||
"vm_name": "disk.raw",
|
||||
"qemu_binary": "/usr/bin/kvm",
|
||||
"qemuargs": [
|
||||
["-m", "1024"],
|
||||
["-cpu", "host"],
|
||||
["-chardev", "tty,id=pts,path={{user `serial`}}"],
|
||||
["-device", "isa-serial,chardev=pts"],
|
||||
["-device", "virtio-net,netdev=user.0"]
|
||||
]
|
||||
}
|
||||
],
|
||||
"post-processors": [
|
||||
[
|
||||
{
|
||||
"type": "compress",
|
||||
"output": "output/disk.raw.tar.gz"
|
||||
},
|
||||
{
|
||||
"type": "googlecompute-import",
|
||||
"project_id": "{{user `project`}}",
|
||||
"account_file": "{{user `account_file`}}",
|
||||
"bucket": "{{user `bucket`}}",
|
||||
"image_name": "fedora31-server-packertest",
|
||||
"image_description": "Fedora 31 Server",
|
||||
"image_family": "fedora31-server"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
|
|
|||
|
|
@ -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