iSharkFly-Docs
/
packer-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: Various doc clean-ups to fix code block formatting and syntax highlighting (#8868)

This commit is contained in:
Wilken Rivera 2020-03-12 10:05:08 -04:00 committed by GitHub
parent 79f1fab836
commit 7b705545d9
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
119 changed files with 477 additions and 435 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
builder/amazon/chroot/builder.go
View File

@ -120,45 +120,44 @@ type Config struct {
SourceAmi string `mapstructure:"source_ami" required:"true"`
// Filters used to populate the source_ami field. Example:
//
//```json
//{
// "source_ami_filter": {
// "filters": {
// "virtualization-type": "hvm",
// "name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
// "root-device-type": "ebs"
// },
// "owners": ["099720109477"],
// "most_recent": true
// }
//}
//```
//
// ``` json
// {
// "source_ami_filter": {
// "filters": {
// "virtualization-type": "hvm",
// "name": "ubuntu/images/*ubuntu-xenial-16.04-amd64-server-*",
// "root-device-type": "ebs"
// },
// "owners": ["099720109477"],
// "most_recent": true
// }
// }
// ```
//This selects the most recent Ubuntu 16.04 HVM EBS AMI from Canonical. NOTE:
//This will fail unless *exactly* one AMI is returned. In the above example,
//`most_recent` will cause this to succeed by selecting the newest image.
//
// This selects the most recent Ubuntu 16.04 HVM EBS AMI from Canonical. NOTE:
// This will fail unless *exactly* one AMI is returned. In the above example,
// `most_recent` will cause this to succeed by selecting the newest image.
//- `filters` (map of strings) - filters used to select a `source_ami`.
// NOTE: This will fail unless *exactly* one AMI is returned. Any filter
// described in the docs for
// [DescribeImages](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)
// is valid.
//
// - `filters` (map of strings) - filters used to select a `source_ami`.
// NOTE: This will fail unless *exactly* one AMI is returned. Any filter
// described in the docs for
// [DescribeImages](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html)
// is valid.
//- `owners` (array of strings) - Filters the images by their owner. You
// may specify one or more AWS account IDs, "self" (which will use the
// account whose credentials you are using to run Packer), or an AWS owner
// alias: for example, "amazon", "aws-marketplace", or "microsoft". This
// option is required for security reasons.
//
// - `owners` (array of strings) - Filters the images by their owner. You
// may specify one or more AWS account IDs, "self" (which will use the
// account whose credentials you are using to run Packer), or an AWS owner
// alias: for example, "amazon", "aws-marketplace", or "microsoft". This
// option is required for security reasons.
//- `most_recent` (boolean) - Selects the newest created image when true.
// This is most useful for selecting a daily distro build.
//
// - `most_recent` (boolean) - Selects the newest created image when true.
// This is most useful for selecting a daily distro build.
//
// You may set this in place of `source_ami` or in conjunction with it. If you
// set this in conjunction with `source_ami`, the `source_ami` will be added
// to the filter. The provided `source_ami` must meet all of the filtering
// criteria provided in `source_ami_filter`; this pins the AMI returned by the
// filter, but will cause Packer to fail if the `source_ami` does not exist.
//You may set this in place of `source_ami` or in conjunction with it. If you
//set this in conjunction with `source_ami`, the `source_ami` will be added
//to the filter. The provided `source_ami` must meet all of the filtering
//criteria provided in `source_ami_filter`; this pins the AMI returned by the
//filter, but will cause Packer to fail if the `source_ami` does not exist.
SourceAmiFilter awscommon.AmiFilterOptions `mapstructure:"source_ami_filter" required:"false"`
// Tags to apply to the volumes that are *launched*. This is a [template
// engine](/docs/templates/engine.html), see [Build template

2
builder/amazon/common/access_config.go
View File

@ -116,7 +116,7 @@ type AccessConfig struct {
// credential types) and GetFederationToken (for federation\_token
// credential types) for more details.
//
// ``` json
// ```json
// {
// "vault_aws_engine": {
// "name": "myrole",

4
builder/amazon/common/block_device.go
View File

@ -21,8 +21,8 @@ import (
// The following mapping will tell Packer to encrypt the root volume of the
// build instance at launch using a specific non-default kms key:
//
// ``` json
// "[{
// ```json
// [{
// "device_name": "/dev/sda1",
// "encrypted": true,
// "kms_key_id": "1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d"

10
builder/amazon/common/run_config.go
View File

@ -107,7 +107,7 @@ type RunConfig struct {
// `true`, will cause a timeout.
// Example of a valid shutdown command:
//
// ``` json
// ```json
// {
// "type": "windows-shell",
// "inline": ["\"c:\\Program Files\\Amazon\\Ec2ConfigService\\ec2config.exe\" -sysprep"]
@ -175,7 +175,7 @@ type RunConfig struct {
InstanceType string `mapstructure:"instance_type" required:"true"`
// Filters used to populate the `security_group_ids` field. Example:
//
// ``` json
// ```json
// {
// "security_group_filter": {
// "filters": {
@ -216,7 +216,7 @@ type RunConfig struct {
// Filters used to populate the `source_ami`
// field. Example:
//
// ``` json
// ```json
// {
// "source_ami_filter": {
// "filters": {
@ -293,7 +293,7 @@ type RunConfig struct {
// Filters used to populate the `subnet_id` field.
// Example:
//
// ``` json
// ```json
// {
// "subnet_filter": {
// "filters": {
@ -350,7 +350,7 @@ type RunConfig struct {
// Filters used to populate the `vpc_id` field.
// Example:
//
// ``` json
// ```json
// {
// "vpc_filter": {
// "filters": {

2
builder/azure/arm/config.go
View File

@ -297,7 +297,7 @@ type Config struct {
//
// An example plan\_info object is defined below.
//
// ``` json
// ```json
// {
// "plan_info": {
// "plan_name": "rabbitmq",

4
builder/googlecompute/config.go
View File

@ -68,7 +68,7 @@ type Config struct {
//
// example:
//
// ``` json
// ```json
// {
// "kmsKeyName": "projects/${project}/locations/${region}/keyRings/computeEngine/cryptoKeys/computeEngine/cryptoKeyVersions/4"
// }
@ -128,7 +128,7 @@ type Config struct {
// The service account scopes for launched
// instance. Defaults to:
//
// ``` json
// ```json
// [
// "https://www.googleapis.com/auth/userinfo.email",
// "https://www.googleapis.com/auth/compute",

3
builder/openstack/run_config.go
View File

@ -35,7 +35,8 @@ type RunConfig struct {
SourceImageName string `mapstructure:"source_image_name" required:"true"`
// Filters used to populate filter options. Example:
//
// ``` json {
// ```json
//{
// "source_image_filter": {
// "filters": {
// "name": "ubuntu-16.04",

19
builder/qemu/builder.go
View File

@ -234,7 +234,8 @@ type Config struct {
//
// The following shows a sample usage:
//
// ``` json {
// ```json
//{
// "qemuargs": [
// [ "-m", "1024M" ],
// [ "--no-acpi", "" ],
@ -252,9 +253,11 @@ type Config struct {
// would produce the following (not including other defaults supplied by
// the builder and not otherwise conflicting with the qemuargs):
//
// ``` text qemu-system-x86 -m 1024m --no-acpi -netdev
// ```text
// qemu-system-x86 -m 1024m --no-acpi -netdev
// user,id=mynet0,hostfwd=hostip:hostport-guestip:guestport -device
// virtio-net,netdev=mynet0" ```
// virtio-net,netdev=mynet0"
// ```
//
// ~> **Windows Users:** [QEMU for Windows](https://qemu.weilnetz.de/)
// builds are available though an environmental variable does need to be
@ -264,17 +267,21 @@ type Config struct {
// The following shows the environment variable that needs to be set for
// Windows QEMU support:
//
// ``` text setx SDL_STDIO_REDIRECT=0 ```
// ```text
// setx SDL_STDIO_REDIRECT=0
// ```
//
// You can also use the `SSHHostPort` template variable to produce a packer
// template that can be invoked by `make` in parallel:
//
// ``` json {
// ```json
//{
// "qemuargs": [
// [ "-netdev", "user,hostfwd=tcp::{{ .SSHHostPort }}-:22,id=forward"],
// [ "-device", "virtio-net,netdev=forward,id=net0"]
// ]
// } ```
// }
// ```
//
// `make -j 3 my-awesome-packer-templates` spawns 3 packer processes, each
// of which will bind to their own SSH port as determined by each process.

2
builder/virtualbox/common/export_config.go
View File

@ -17,7 +17,7 @@ type ExportConfig struct {
// This can be useful for passing product information to include in the
// resulting appliance file. Packer JSON configuration file example:
//
// ``` json
// ```json
// {
// "type": "virtualbox-iso",
// "export_opts":

8
builder/virtualbox/iso/builder.go
View File

@ -96,9 +96,13 @@ type Config struct {
// Virtualbox 6, install an [extension
// pack](https://www.virtualbox.org/wiki/Downloads#VirtualBox6.0.14OracleVMVirtualBoxExtensionPack)
// and you will need to enable EFI mode for nvme to work, ex:
// "vboxmanage": [
//
// ```json
// "vboxmanage": [
// [ "modifyvm", "{{.Name}}", "--firmware", "EFI" ],
// ]
// ]
// ```
//
HardDriveInterface string `mapstructure:"hard_drive_interface" required:"false"`
// The number of ports available on any SATA controller created, defaults
// to 1. VirtualBox supports up to 30 ports on a maximum of 1 SATA

4
common/bootcommand/config.go
View File

@ -81,7 +81,7 @@ import (
// Example boot command. This is actually a working boot command used to start an
// CentOS 6.4 installer:
//
// ``` json
// ```json
// "boot_command": [
// "<tab><wait>",
// " ks=http://{{ .HTTPIP }}:{{ .HTTPPort }}/centos6-ks.cfg<enter>"
@ -91,7 +91,7 @@ import (
// The example shown below is a working boot command used to start an Ubuntu
// 12.04 installer:
//
// ``` json
// ```json
// [
// "<esc><esc><enter><wait>",
// "/install/vmlinuz noapic ",

8
common/iso_config.go
View File

@ -33,14 +33,14 @@ import (
// Examples:
// go-getter can guess the checksum type based on `iso_checksum` len.
//
// ``` json
// ```json
// {
// "iso_checksum": "946a6077af6f5f95a51f82fdc44051c7aa19f9cfc5f737954845a6050543d7c2",
// "iso_url": "ubuntu.org/.../ubuntu-14.04.1-server-amd64.iso"
// }
// ```
//
// ``` json
// ```json
// {
// "iso_checksum_type": "file",
// "iso_checksum": "ubuntu.org/..../ubuntu-14.04.1-server-amd64.iso.sum",
@ -48,14 +48,14 @@ import (
// }
// ```
//
// ``` json
// ```json
// {
// "iso_checksum_url": "./shasums.txt",
// "iso_url": "ubuntu.org/.../ubuntu-14.04.1-server-amd64.iso"
// }
// ```
//
// ``` json
// ```json
// {
// "iso_checksum_type": "sha256",
// "iso_checksum_url": "./shasums.txt",

8
helper/communicator/config.go
View File

@ -51,10 +51,10 @@ type Config struct {
//
// ```json
// {
// "communicator": "ssh",
// "ssh_username": "myuser",
// "pause_before_connecting": "10m"
// }
// "communicator": "ssh",
// "ssh_username": "myuser",
// "pause_before_connecting": "10m"
// }
// ```
//
// In this example, Packer will check whether it can connect, as normal. But once

2
website/source/docs/builders/alicloud-ecs.html.md.erb
View File

@ -43,7 +43,7 @@ builder.
Here is a basic example for Alicloud.
``` json
```json
{
"variables": {
"access_key": "{{env `ALICLOUD_ACCESS_KEY`}}",

66
website/source/docs/builders/amazon-chroot.html.md.erb
View File

@ -104,7 +104,7 @@ Block devices can be nested in the
Here is a basic example. It is completely valid except for the access keys:
``` json
```json
{
"type": "amazon-chroot",
"access_key": "YOUR KEY HERE",
@ -131,7 +131,7 @@ However, if you want to change or add the mount points, you may using the
`chroot_mounts` configuration. Here is an example configuration which only
mounts `/proc` and `/dev`:
``` json
```json
{
"chroot_mounts": [
["proc", "proc", "/proc"],
@ -173,7 +173,7 @@ For debian based distributions you can setup a
file which will prevent packages installed by your provisioners from starting
services:
``` json
```json
{
"type": "shell",
"inline": [
@ -208,37 +208,39 @@ involving the `nvme_device_path` option above. Read that for more information.
A working example for mounting an NVMe device is below:
```json
{
"variables": {
"region" : "us-east-2"
},
"builders": [
{
"variables": {
"region" : "us-east-2"
"type": "amazon-chroot",
"region": "{{user `region`}}",
"source_ami_filter": {
"filters": {
"virtualization-type": "hvm",
"name": "amzn-ami-hvm-*",
"root-device-type": "ebs"
},
"owners": ["137112412989"],
"most_recent": true
},
"builders": [
{
"type": "amazon-chroot",
"region": "{{user `region`}}",
"source_ami_filter": {
"filters": {
"virtualization-type": "hvm",
"name": "amzn-ami-hvm-*",
"root-device-type": "ebs"
},
"owners": ["137112412989"],
"most_recent": true
},
"ena_support": true,
"ami_name": "amazon-chroot-test-{{timestamp}}",
"nvme_device_path": "/dev/nvme1n1p",
"device_path": "/dev/sdf"
}
],
"provisioners": [
{
"type": "shell",
"inline": ["echo Test > /tmp/test.txt"]
}
]
"ena_support": true,
"ami_name": "amazon-chroot-test-{{timestamp}}",
"nvme_device_path": "/dev/nvme1n1p",
"device_path": "/dev/sdf"
}
],
"provisioners": [
{
"type": "shell",
"inline": ["echo Test > /tmp/test.txt"]
}
]
}
```
Note that in the `nvme_device_path` you must end with the `p`; if you try to
define the partition in this path (e.g. `nvme_device_path`: `/dev/nvme1n1p1`)
@ -253,7 +255,7 @@ The device setup commands partition the device with one partition for use as an
HVM image and format it ext4. This builder block should be followed by
provisioning commands to install the os and bootloader.
``` json
```json
{
"type": "amazon-chroot",
"ami_name": "packer-from-scratch {{timestamp}}",

8
website/source/docs/builders/amazon-ebs.html.md.erb
View File

@ -105,7 +105,7 @@ Here is a basic example. You will need to provide access keys, and may need to
change the AMI IDs according to what images exist at the time the template is
run:
``` json
```json
{
"variables": {
"aws_access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
@ -151,7 +151,7 @@ configuration of `launch_block_device_mappings` will expand the root volume
`ami_block_device_mappings` AWS will attach additional volumes `/dev/sdb` and
`/dev/sdc` when we boot a new instance of our AMI.
``` json
```json
{
"type": "amazon-ebs",
"access_key": "YOUR KEY HERE",
@ -214,7 +214,7 @@ Here is an example using the optional AMI tags. This will add the tags
provide your access keys, and may need to change the source AMI ID based on
what images exist when this template is run:
``` json
```json
{
"type": "amazon-ebs",
"access_key": "YOUR KEY HERE",
@ -246,7 +246,7 @@ in the `launch_block_device_mappings` block for the device.
For Amazon Windows 2016 AMIs it is necessary to run Sysprep commands which can
be easily added to the provisioner section.
``` json
```json
{
"type": "powershell",
"inline": [

2
website/source/docs/builders/amazon-ebssurrogate.html.md.erb
View File

@ -100,7 +100,7 @@ Block devices can be nested in the
## Basic Example
``` json
```json
{
"type" : "amazon-ebssurrogate",
"secret_key" : "YOUR SECRET KEY HERE",

2
website/source/docs/builders/amazon-ebsvolume.html.md.erb
View File

@ -102,7 +102,7 @@ Block devices can be nested in the
## Basic Example
``` json
```json
{
"type" : "amazon-ebsvolume",
"secret_key" : "YOUR SECRET KEY HERE",

4
website/source/docs/builders/amazon-instance.html.md.erb
View File

@ -115,7 +115,7 @@ Block devices can be nested in the
Here is a basic example. It is completely valid except for the access keys:
``` json
```json
{
"type": "amazon-instance",
"access_key": "YOUR KEY HERE",
@ -246,7 +246,7 @@ assuming a role.
The `ec2-upload-bundle` requires a policy document that looks something like
this:
``` json
```json
{
"Version": "2012-10-17",
"Statement": [

12
website/source/docs/builders/amazon.html.md
View File

@ -65,7 +65,7 @@ explained below:
Static credentials can be provided in the form of an access key id and secret.
These look like:
``` json
```json
{
"access_key": "AKIAIOSFODNN7EXAMPLE",
"secret_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
@ -108,7 +108,7 @@ The format for the credentials file is like so
You may also configure the profile to use by setting the `profile`
configuration option, or setting the `AWS_PROFILE` environment variable:
``` json
```json
{
"profile": "customprofile",
"region": "us-east-1",
@ -128,7 +128,7 @@ which reduces the chance of leakage.
The following policy document provides the minimal set permissions necessary
for Packer to work:
``` json
```json
{
"Version": "2012-10-17",
"Statement": [{
@ -198,7 +198,7 @@ The example policy below may help packer work with IAM roles. Note that this
example provides more than the minimal set of permissions needed for packer to
work, but specifics will depend on your use-case.
``` json
```json
{
"Sid": "PackerIAMPassRole",
"Effect": "Allow",
@ -215,7 +215,7 @@ work, but specifics will depend on your use-case.
In case when you're creating a temporary instance profile you will require to have following
IAM policies.
``` json
```json
{
"Sid": "PackerIAMCreateRole",
"Effect": "Allow",
@ -254,7 +254,7 @@ following policies at a minimum:
If you are using a key provided by a different account than the one you are
using to run the Packer build, your key will also need
``` json
```json
"kms:CreateGrant",
"kms:DescribeKey"
```

6
website/source/docs/builders/azure-arm.html.md.erb
View File

@ -169,7 +169,7 @@ Providing `temp_resource_group_name` or `location` in combination with
Here is a basic example for Azure.
``` json
```json
{
"type": "azure-arm",
@ -216,7 +216,7 @@ after that. The possible states, in case you want to wait for another state,
[are documented
here](https://technet.microsoft.com/en-us/library/hh824815.aspx)
``` json
```json
{
"provisioners": [
{
@ -249,7 +249,7 @@ Agent](https://docs.microsoft.com/en-us/azure/virtual-machines/extensions/agent-
The following provisioner snippet shows how to deprovision a Linux VM.
Deprovision should be the last operation executed by a build.
``` json
```json
{
"provisioners": [
{

6
website/source/docs/builders/azure-chroot.html.md.erb
View File

@ -83,7 +83,7 @@ However, if you want to change or add the mount points, you may using the
`chroot_mounts` configuration. Here is an example configuration which only
mounts `/prod` and `/dev`:
``` json
```json
{
"chroot_mounts": [
["proc", "proc", "/proc"],
@ -134,7 +134,7 @@ On a VM with a system-assigned managed identity that has the contributor role
on its own resource group, the following config can be used to create an
updated Debian image:
``` json
```json
{
"builders": [{
"type": "azure-chroot",
@ -162,7 +162,7 @@ to update your VM.
Set the `ARM_IMAGE_RESOURCEGROUP_ID` variable to an existing resource group in the
subscription where the resulting image will be created.
``` json
```json
{
"variables": {
"client_id": "{{env `ARM_CLIENT_ID`}}",

4
website/source/docs/builders/cloudstack.html.md
View File

@ -203,13 +203,13 @@ The available variables are:
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
that is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank. Example: "{{.HTTPIP}}:{{.HTTPPort}}/path/to/a/file/in/http_directory"
blank. Example: `{{.HTTPIP}}:{{.HTTPPort}}/path/to/a/file/in/http_directory`
## Basic Example
Here is a basic example.
``` json
```json
{
"type": "cloudstack",
"api_url": "https://cloudstack.company.com/client/api",

2
website/source/docs/builders/digitalocean.html.md
View File

@ -101,7 +101,7 @@ builder.
Here is a basic example. It is completely valid as soon as you enter your own
access tokens:
``` json
```json
{
"type": "digitalocean",
"api_token": "YOUR API KEY",

16
website/source/docs/builders/docker.html.md.erb
View File

@ -38,7 +38,7 @@ documentation.
Below is a fully functioning example. It doesn't do anything useful, since no
provisioners are defined, but it will effectively repackage an image.
``` json
```json
{
"type": "docker",
"image": "ubuntu",
@ -52,7 +52,7 @@ Below is another example, the same as above but instead of exporting the
running container, this one commits the container to an image. The image can
then be more easily tagged, pushed, etc.
``` json
```json
{
"type": "docker",
"image": "ubuntu",
@ -71,7 +71,7 @@ Docker](https://docs.docker.com/engine/reference/commandline/commit/).
Example uses of all of the options, assuming one is building an NGINX image
from ubuntu as an simple example:
``` json
```json
{
"type": "docker",
"image": "ubuntu",
@ -163,7 +163,7 @@ created image. This is accomplished using a sequence definition (a collection
of post-processors that are treated as as single pipeline, see
[Post-Processors](/docs/templates/post-processors.html) for more information):
``` json
```json
{
"post-processors": [
[
@ -203,7 +203,7 @@ definition (a collection of post-processors that are treated as as single
pipeline, see [Post-Processors](/docs/templates/post-processors.html) for more
information):
``` json
```json
{
"post-processors": [
[
@ -229,7 +229,7 @@ Going a step further, if you wanted to tag and push an image to multiple
container repositories, this could be accomplished by defining two,
nearly-identical sequence definitions, as demonstrated by the example below:
``` json
```json
{
"post-processors": [
[
@ -267,7 +267,7 @@ containers, so you must either commit or discard them.
The following is a fully functional template for building a Windows
container.
``` json
```json
{
"builders": [
{
@ -287,7 +287,7 @@ Packer can tag and push images for use in [Amazon EC2 Container
Registry](https://aws.amazon.com/ecr/). The post processors work as described
above and example configuration properties are shown below:
``` json
```json
{
"post-processors": [
[

2
website/source/docs/builders/file.html.md
View File

@ -21,7 +21,7 @@ wait times.
Below is a fully functioning example. It create a file at `target` with the
specified `content`.
``` json
```json
{
"type": "file",
"content": "Lorem ipsum dolor sit amet",

6
website/source/docs/builders/googlecompute.html.md.erb
View File

@ -119,7 +119,7 @@ repackage an existing GCE image. The account\_file is obtained in the previous
section. If it parses as JSON it is assumed to be the file itself, otherwise,
it is assumed to be the path to the file containing the JSON.
``` json
```json
{
"builders": [
{
@ -148,7 +148,7 @@ Or alternatively by navigating to
Once this is set up, the following is a complete working packer config after
setting a valid `account_file` and `project_id`:
``` json
```json
{
"builders": [
{
@ -184,7 +184,7 @@ Virtualization for VM
Instances](https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances)
for details.
``` json
```json
{
"builders": [
{

4
website/source/docs/builders/hetzner-cloud.html.md
View File

@ -55,7 +55,7 @@ builder.
- `image_filter` (object) - Filters used to populate the `filter`
field. Example:
``` json
```json
{
"image_filter": {
"with_selector": [
@ -113,7 +113,7 @@ builder.
Here is a basic example. It is completely valid as soon as you enter your own
access tokens:
``` json
```json
{
"builders": [{
"type": "hcloud",

4
website/source/docs/builders/hyperone.html.md
View File

@ -216,7 +216,7 @@ builder.
Here is a basic example. It is completely valid as soon as you enter your own
token.
``` json
```json
{
"type": "hyperone",
"token": "YOUR_AUTH_TOKEN",
@ -229,7 +229,7 @@ token.
## Chroot Example
``` json
```json
{
"type": "hyperone",
"token": "YOUR_AUTH_TOKEN",

6
website/source/docs/builders/hyperv-iso.html.md.erb
View File

@ -29,7 +29,7 @@ Here is a basic example. This example is not functional. It will start the OS
installer but then fail because we don't provide the preseed file for Ubuntu
to self-install. Still, the example serves to show the basic configuration:
``` json
```json
{
"type": "hyperv-iso",
"iso_url": "http://releases.ubuntu.com/12.04/ubuntu-12.04.5-server-amd64.iso",
@ -173,7 +173,7 @@ if (test-path $isoFolder){
Packer config:
``` json
```json
{
"builders": [
{
@ -704,7 +704,7 @@ virtual switch with an `External` connection type.
### Packer config:
``` json
```json
{
"variables": {
"vm_name": "ubuntu-xenial",

10
website/source/docs/builders/hyperv-vmcx.html.md.erb
View File

@ -30,7 +30,7 @@ could be used as a starting point for more advanced templates.
Import from folder:
``` json
```json
{
"type": "hyperv-vmcx",
"clone_from_vmcx_path": "c:/path/to/ubuntu-12.04.5-server-amd64",
@ -42,7 +42,7 @@ Import from folder:
Clone from existing virtual machine:
``` json
```json
{
"clone_from_vm_name": "ubuntu-12.04.5-server-amd64",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now",
@ -121,7 +121,7 @@ to the machine, simulating a human actually typing the keyboard.
The example shown below is a working boot command used to start an Ubuntu
12.04 installer:
``` json
```json
[
"<esc><esc><enter><wait>",
"/install/vmlinuz noapic ",
@ -200,7 +200,7 @@ if (test-path $isoFolder){
Packer config:
``` json
```json
{
"builders": [
{
@ -731,7 +731,7 @@ virtual switch with an `External` connection type.
### Packer config:
``` json
```json
{
"variables": {
"vm_name": "ubuntu-xenial",

2
website/source/docs/builders/jdcloud.html.md
View File

@ -41,7 +41,7 @@ are given below:
Here is a basic example for JDCloud.
``` json
```json
{
"builders": [
{

2
website/source/docs/builders/linode.html.md
View File

@ -79,7 +79,7 @@ Here is a Linode builder example. The `linode_token` should be replaced with an
actual [Linode Personal Access
Token](https://www.linode.com/docs/platform/api/getting-started-with-the-linode-api/#get-an-access-token).
``` json
```json
{
"type": "linode",
"linode_token": "YOUR API TOKEN",

2
website/source/docs/builders/null.html.md
View File

@ -23,7 +23,7 @@ artifact.
Below is a fully functioning example. It doesn't do anything useful, since no
provisioners are defined, but it will connect to the specified host via ssh.
``` json
```json
{
"type": "null",
"ssh_host": "127.0.0.1",

2
website/source/docs/builders/oneandone.html.md
View File

@ -50,7 +50,7 @@ builder.
Here is a basic example:
``` json
```json
{
"builders":[
{

8
website/source/docs/builders/openstack.html.md.erb
View File

@ -76,7 +76,7 @@ builder.
Here is a basic example. This is a example to build on DevStack running in a
VM.
``` json
```json
{
"type": "openstack",
"identity_endpoint": "http://<devstack-ip>:5000/v3",
@ -98,7 +98,7 @@ VM.
Here is a basic example. This is a working example to build a Ubuntu 12.04 LTS
(Precise Pangolin) on Rackspace OpenStack cloud offering.
``` json
```json
{
"type": "openstack",
"username": "foo",
@ -116,7 +116,7 @@ Here is a basic example. This is a working example to build a Ubuntu 12.04 LTS
This example builds an Ubuntu 14.04 image on a private OpenStack cloud, powered
by Metacloud.
``` json
```json
{
"type": "openstack",
"ssh_username": "root",
@ -165,7 +165,7 @@ A basic example of Instance with a remote root Block Storage service volume.
This is a working example to build an image on private OpenStack cloud powered
by Selectel VPC.
``` json
```json
{
"type": "openstack",
"identity_endpoint": "https://api.selvpc.com/identity/v3",

10
website/source/docs/builders/oracle-classic.html.md
View File

@ -146,7 +146,7 @@ If this is set, a few more options become available.
may need to change the `ssh_username`, for example. That might look like
this:
``` json
```json
{
"builders": [
{
@ -187,7 +187,7 @@ Here is a basic example. Note that account specific configuration has been
obfuscated; you will need to add a working `username`, `password`,
`identity_domain`, and `api_endpoint` in order for the example to work.
``` json
```json
{
"builders": [
{
@ -227,7 +227,7 @@ for more details on how to define a trusted host.
Save this file as `windows_attributes.json`:
``` json
```json
{
"userdata": {
"administrator_password": "password",
@ -239,7 +239,7 @@ Save this file as `windows_attributes.json`:
Following is a minimal but working Packer config that references this
attributes file:
``` json
```json
{
"variables": {
"opc_username": "{{ env `OPC_USERNAME`}}",
@ -278,7 +278,7 @@ attributes file:
Here is an example using a persistent volume. Note the `persistent_volume_size`
setting.
``` json
```json
{
"variables": {
"opc_username": "{{ env `OPC_USERNAME`}}",

2
website/source/docs/builders/oracle-oci.html.md
View File

@ -179,7 +179,7 @@ builder.
Here is a basic example. Note that account specific configuration has been
substituted with the letter `a` and OCIDS have been shortened for brevity.
``` json
```json
{
"availability_domain": "aaaa:PHX-AD-1",
"base_image_ocid": "ocid1.image.oc1.phx.aaaaaaaa5yu6pw3riqtuhxzov7fdngi4tsteganmao54nq3pyxu3hxcuzmoa",

8
website/source/docs/builders/osc-bsu.html.md
View File

@ -176,7 +176,7 @@ builder.
Example:
``` json
```json
{
"source_omi_filter": {
"filters": {
@ -218,7 +218,7 @@ builder.
- `net_filter` (object) - Filters used to populate the `net_id` field.
Example:
``` json
```json
{
"net_filter": {
"filters": {
@ -283,7 +283,7 @@ configuration of `launch_block_device_mappings` will expand the root volume
`ami_block_device_mappings` Outscale will attach additional volumes `/dev/sdb` and
`/dev/sdc` when we boot a new VM of our OMI.
``` json
```json
{
"type": "osc-bsu",
"access_key": "YOUR KEY HERE",
@ -327,7 +327,7 @@ In configuration directives marked as a template engine above, the following var
Here is an example using the optional OMIS tags. This will add the tags `OS_Version` and `Release` to the finished OMI. As before, you will need to provide your access keys, and may need to change the source OMIS ID based on what images exist when this template is run:
``` json
```json
{
"type": "osc-bsu",
"access_key": "YOUR KEY HERE",

6
website/source/docs/builders/osc-bsusurrogate.html.md
View File

@ -187,7 +187,7 @@ builder.
Example:
``` json
```json
{
"source_omi_filter": {
"filters": {
@ -229,7 +229,7 @@ builder.
- `net_filter` (object) - Filters used to populate the `net_id` field.
Example:
``` json
```json
{
"net_filter": {
"filters": {
@ -250,7 +250,7 @@ builder.
## Basic Example
``` json
```json
{
"type" : "osc-bsusurrogate",
"secret_key" : "YOUR SECRET KEY HERE",

6
website/source/docs/builders/osc-bsuvolume.html.md
View File

@ -142,7 +142,7 @@ builder.
Example:
``` json
```json
{
"source_omi_filter": {
"filters": {
@ -180,7 +180,7 @@ builder.
- `net_filter` (object) - Filters used to populate the `net_id` field.
Example:
``` json
```json
{
"net_filter": {
"filters": {
@ -201,7 +201,7 @@ builder.
## Basic Example
``` json
```json
{
"builders": [
{

10
website/source/docs/builders/osc-chroot.html.md
View File

@ -217,7 +217,7 @@ each category, the available configuration keys are alphabetized.
Example:
``` json
```json
{
"source_omi_filter": {
"filters": {
@ -248,7 +248,7 @@ each category, the available configuration keys are alphabetized.
Here is a basic example. It is completely valid except for the access keys:
``` json
```json
{
"type": "osc-chroot",
"access_key": "YOUR KEY HERE",
@ -275,7 +275,7 @@ However, if you want to change or add the mount points, you may using the
`chroot_mounts` configuration. Here is an example configuration which only
mounts `/proc` and `/dev`:
``` json
```json
{
"chroot_mounts": [
["proc", "proc", "/proc"],
@ -317,7 +317,7 @@ For debian based distributions you can setup a
file which will prevent packages installed by your provisioners from starting
services:
``` json
```json
{
"type": "shell",
"inline": [
@ -350,7 +350,7 @@ The device setup commands partition the device with one partition for use as an
HVM image and format it ext4. This builder block should be followed by
provisioning commands to install the os and bootloader.
``` json
```json
{
"type": "osc-chroot",
"ami_name": "packer-from-scratch {{timestamp}}",

2
website/source/docs/builders/outscale.html.md
View File

@ -52,7 +52,7 @@ The OUTSCALE provider offers a flexible means of providing credentials for authe
Static credentials can be provided in the form of an access key id and secret.
These look like:
``` json
```json
{
"access_key": "AKIAIOSFODNN7EXAMPLE",
"secret_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",

4
website/source/docs/builders/parallels-iso.html.md.erb
View File

@ -29,7 +29,7 @@ Here is a basic example. This example is not functional. It will start the OS
installer but then fail because we don't provide the preseed file for Ubuntu to
self-install. Still, the example serves to show the basic configuration:
``` json
```json
{
"type": "parallels-iso",
"guest_os_type": "ubuntu",
@ -277,7 +277,7 @@ Extra `prlctl` commands are defined in the template in the `prlctl` section. In
example below `prlctl` is used to explicitly enable the adaptive hypervisor, and
disable 3d acceleration:
``` json
```json
{
"prlctl": [
["set", "{{.Name}}", "--3d-accelerate", "off"],

4
website/source/docs/builders/parallels-pvm.html.md.erb
View File

@ -28,7 +28,7 @@ create the image. The imported machine is deleted prior to finishing the build.
Here is a basic example. This example is functional if you have an PVM matching
the settings here.
``` json
```json
{
"type": "parallels-pvm",
"parallels_tools_flavor": "lin",
@ -202,7 +202,7 @@ Extra `prlctl` commands are defined in the template in the `prlctl` section. An
example is shown below that sets the memory and number of CPUs within the
virtual machine:
``` json
```json
{
"prlctl": [
["set", "{{.Name}}", "--memsize", "1024"],

2
website/source/docs/builders/profitbricks.html.md
View File

@ -66,7 +66,7 @@ builder.
Here is a basic example:
``` json
```json
{
"builders": [
{

2
website/source/docs/builders/proxmox.html.md
View File

@ -180,7 +180,7 @@ Here is a basic example creating a Fedora 29 server image with a Kickstart
file served with Packer's HTTP server. Note that the iso file needs to be
manually downloaded.
``` json
```json
{
"variables": {
"username": "apiuser@pve",

2
website/source/docs/builders/qemu.html.md.erb
View File

@ -26,7 +26,7 @@ necessary to run the virtual machine on KVM or Xen.
Here is a basic example. This example is functional so long as you fixup paths
to files, URLS for ISOs and checksums.
``` json
```json
{
"builders":
[

2
website/source/docs/builders/scaleway.html.md
View File

@ -87,7 +87,7 @@ builder.
Here is a basic example. It is completely valid as soon as you enter your own
access tokens:
``` json
```json
{
"type": "scaleway",
"organization_id": "YOUR ORGANIZATION ID",

2
website/source/docs/builders/tencentcloud-cvm.html.md
View File

@ -127,7 +127,7 @@ a [communicator](/docs/templates/communicator.html) can be configured for this b
Here is a basic example for Tencentcloud.
``` json
```json
{
"variables": {
"secret_id": "{{env `TENCENTCLOUD_ACCESS_KEY`}}",

4
website/source/docs/builders/triton.html.md
View File

@ -155,7 +155,7 @@ builder.
- `source_machine_image_filter` (object) - Filters used to populate the
`source_machine_image` field. Example:
``` json
```json
{
"source_machine_image_filter": {
"name": "ubuntu-16.04",
@ -169,7 +169,7 @@ builder.
Below is a minimal example to create an image on the Joyent public cloud:
``` json
```json
{
"builders": [
{

4
website/source/docs/builders/ucloud-uhost.html.md
View File

@ -87,7 +87,7 @@ builder.
Here is a basic example for build UCloud CentOS image:
``` json
```json
{
"variables": {
"ucloud_public_key": "{{env `UCLOUD_PUBLIC_KEY`}}",
@ -112,7 +112,7 @@ Here is a basic example for build UCloud CentOS image:
Here is a example for build UCloud Ubuntu image:
``` json
```json
{
"variables": {
"ucloud_public_key": "{{env `UCLOUD_PUBLIC_KEY`}}",

2
website/source/docs/builders/vagrant.html.md
View File

@ -144,7 +144,7 @@ the Compress post-processor will not work with this builder.
Sample for `hashicorp/precise64` with virtualbox provider.
```
```json
{
"builders": [
{

8
website/source/docs/builders/virtualbox-iso.html.md.erb
View File

@ -28,7 +28,7 @@ Here is a basic example. This example is not functional. It will start the OS
installer but then fail because we don't provide the preseed file for Ubuntu to
self-install. Still, the example serves to show the basic configuration:
``` json
```json
{
"type": "virtualbox-iso",
"guest_os_type": "Ubuntu_64",
@ -156,7 +156,7 @@ delay of 100ms between groups. The delay alleviates issues with latency and CPU
contention. If you notice missing keys, you can tune this delay by specifying
"boot_keygroup_interval" in your Packer template, for example:
```
```json
{
"builders": [
{
@ -227,7 +227,7 @@ used to do things such as set RAM, CPUs, etc.
Extra VBoxManage commands are defined in the template in the `vboxmanage`
section. An example is shown below that sets the VRAM within the virtual machine:
``` json
```json
{
"vboxmanage": [
["modifyvm", "{{.Name}}", "--vram", "64"]
@ -250,7 +250,7 @@ required for many VBoxManage calls.
If you want to create an EFI enabled VM, make sure you set the `iso_interface`
to "sata". Otherwise your attached drive will not be bootable. Example:
``` json
```json
"iso_interface": "sata",
"vboxmanage": [
[ "modifyvm", "{{.Name}}", "--firmware", "EFI" ]

6
website/source/docs/builders/virtualbox-ovf.html.md.erb
View File

@ -38,7 +38,7 @@ build.
Here is a basic example. This example is functional if you have an OVF matching
the settings here.
``` json
```json
{
"type": "virtualbox-ovf",
"source_path": "source.ovf",
@ -146,7 +146,7 @@ delay of 100ms between groups. The delay alleviates issues with latency and CPU
contention. If you notice missing keys, you can tune this delay by specifying
"boot_keygroup_interval" in your Packer template, for example:
```
```json
{
"builders": [
{
@ -213,7 +213,7 @@ Extra VBoxManage commands are defined in the template in the `vboxmanage`
section. An example is shown below that sets the memory and number of CPUs
within the virtual machine:
``` json
```json
{
"vboxmanage": [
["modifyvm", "{{.Name}}", "--memory", "1024"],

8
website/source/docs/builders/virtualbox-vm.html.md.erb
View File

@ -27,7 +27,7 @@ from the applied provisioners.
Here is a basic example. which serves to show the basic configuration:
``` json
```json
{
"type" : "virtualbox-vm",
"communicator" : "winrm",
@ -92,7 +92,7 @@ builder.
can be useful for passing product information to include in the resulting
appliance file. Packer JSON configuration file example:
``` json
```json
{
"type": "virtualbox-vm",
"export_opts":
@ -290,7 +290,7 @@ delay of 100ms between groups. The delay alleviates issues with latency and CPU
contention. If you notice missing keys, you can tune this delay by specifying
"boot_keygroup_interval" in your Packer template, for example:
```
```json
{
"builders": [
{
@ -357,7 +357,7 @@ used to do things such as set RAM, CPUs, etc.
Extra VBoxManage commands are defined in the template in the `vboxmanage`
section. An example is shown below that sets the VRAM within the virtual machine:
``` json
```json
{
"vboxmanage": [
["modifyvm", "{{.Name}}", "--vram", "64"]

6
website/source/docs/builders/vmware-iso.html.md.erb
View File

@ -37,7 +37,7 @@ Here is a basic example. This example is not functional. It will start the OS
installer but then fail because we don't provide the preseed file for Ubuntu to
self-install. Still, the example serves to show the basic configuration:
``` json
```json
{
"type": "vmware-iso",
"iso_url": "http://old-releases.ubuntu.com/releases/precise/ubuntu-12.04.2-server-amd64.iso",
@ -228,7 +228,7 @@ Depending on your network configuration, it may be difficult to use packer's
built-in HTTP server with ESXi. Instead, you can provide a kickstart or preseed
file by attaching a floppy disk. An example below, based on RHEL:
``` json
```json
{
"builders": [
{
@ -246,7 +246,7 @@ It's also worth noting that `ks=floppy` has been deprecated. Later versions of
the Anaconda installer (used in RHEL/CentOS 7 and Fedora) may require
a different syntax to source a kickstart file from a mounted floppy image.
``` json
```json
{
"builders": [
{

2
website/source/docs/builders/vmware-vmx.html.md.erb
View File

@ -34,7 +34,7 @@ VMware virtual machine.
Here is an example. This example is fully functional as long as the source path
points to a real VMX file with the proper settings:
``` json
```json
{
"type": "vmware-vmx",
"source_path": "/path/to/a/vm.vmx",

2
website/source/docs/builders/yandex.html.md.erb
View File

@ -38,7 +38,7 @@ Or use the `YC_SERVICE_ACCOUNT_KEY_FILE` environment variable.
## Basic Example
``` json
```json
{
"type": "yandex",
"token": "YOUR OAUTH TOKEN",

2
website/source/docs/communicators/ssh.html.md
View File

@ -56,7 +56,7 @@ build. If your template contains multiple builds, you can have a different
communicator configured for each. Here's an extremely basic example of
configuring the SSH communicator for an Amazon builder:
``` json
```json
{
"builders": [
{

2
website/source/docs/extending/plugins.html.md
View File

@ -219,7 +219,7 @@ While developing plugins, you can configure your Packer configuration to point
directly to the compiled plugin in order to test it. For example, building the
CustomCloud plugin, I may configure packer like so:
``` json
```json
{
"builders": {
"custom-cloud": "/an/absolute/path/to/packer-builder-custom-cloud"

2
website/source/docs/other/debugging.html.md
View File

@ -112,7 +112,7 @@ Adding the following provisioner to the packer template, allows for the
cloud-init process to fully finish before packer starts provisioning the source
AMI.
``` json
```json
{
"type": "shell",
"inline": [

2
website/source/docs/post-processors/alicloud-import.html.md
View File

@ -97,7 +97,7 @@ artifact. The user must have the role `AliyunECSImageImportDefaultRole` with
role and policy for you if you have the privilege, otherwise, you have to ask
the administrator configure for you in advance.
``` json
```json
"post-processors":[
{
"access_key":"{{user `access_key`}}",

6
website/source/docs/post-processors/amazon-import.html.md
View File

@ -164,7 +164,7 @@ Here is a basic example. This assumes that the builder has produced an OVA
artifact for us to work with, and IAM roles for import exist in the AWS account
being imported into.
``` json
```json
{
"type": "amazon-import",
"access_key": "YOUR KEY HERE",
@ -183,7 +183,7 @@ being imported into.
This is an example that uses `vmware-iso` builder and exports the `.ova` file
using ovftool.
``` json
```json
"post-processors" : [
[
{
@ -215,7 +215,7 @@ using ovftool.
You'll need at least the following permissions in the policy for your IAM user
in order to successfully upload an image via the amazon-import post-processor.
``` json
```json
"ec2:CancelImportTask",
"ec2:CopyImage",
"ec2:CreateTags",

4
website/source/docs/post-processors/artifice.html.md
View File

@ -81,7 +81,7 @@ This minimal example:
VMX is a fast way to build and test locally, but you can easily substitute
another builder.
``` json
```json
{
"builders": [
{
@ -136,7 +136,7 @@ one set of square braces the post-processors will run individually against the
build artifact (the vmx file in this case) and it will not have the desired
result.
``` json
```json
{
"post-processors": [
[ // <--- Start post-processor chain

2
website/source/docs/post-processors/checksum.html.md
View File

@ -31,7 +31,7 @@ a third-party post-processor.
The example below is fully functional.
``` json
```json
{
"type": "checksum"
}

6
website/source/docs/post-processors/compress.html.md
View File

@ -60,21 +60,21 @@ compress.
Some minimal examples are shown below, showing only the post-processor
configuration:
``` json
```json
{
"type": "compress",
"output": "archive.tar.lz4"
}
```
``` json
```json
{
"type": "compress",
"output": "{{.BuildName}}_bundle.zip"
}
```
``` json
```json
{
"type": "compress",
"output": "log_{{.BuildName}}.gz",

2
website/source/docs/post-processors/digitalocean-import.html.md
View File

@ -90,7 +90,7 @@ Optional:
Here is a basic example:
``` json
```json
{
"type": "digitalocean-import",
"api_token": "{{user `token`}}",

4
website/source/docs/post-processors/docker-import.html.md
View File

@ -45,7 +45,7 @@ is optional.
An example is shown below, showing only the post-processor configuration:
``` json
```json
{
"type": "docker-import",
"repository": "hashicorp/packer",
@ -71,7 +71,7 @@ Docker](https://docs.docker.com/engine/reference/commandline/import/).
Example uses of all of the options, assuming one is building an NGINX image
from ubuntu as an simple example:
``` json
```json
{
"type": "docker-import",
"repository": "local/centos6",

2
website/source/docs/post-processors/docker-save.html.md
View File

@ -39,7 +39,7 @@ The configuration for this post-processor only requires one option.
An example is shown below, showing only the post-processor configuration:
``` json
```json
{
"type": "docker-save",
"path": "foo.tar"

2
website/source/docs/post-processors/docker-tag.html.md
View File

@ -49,7 +49,7 @@ settings are optional.
An example is shown below, showing only the post-processor configuration:
``` json
```json
{
"type": "docker-tag",
"repository": "hashicorp/packer",

2
website/source/docs/post-processors/exoscale-import.html.md
View File

@ -76,7 +76,7 @@ Optional:
Here is a basic example:
``` json
```json
{
"type": "exoscale-import",
"api_key": "{{user `exoscale_api_key`}}",

2
website/source/docs/post-processors/googlecompute-export.html.md
View File

@ -80,7 +80,7 @@ In order for this example to work, the account associated with `account.json`
must have write access to both `gs://mybucket1/path/to/file1.tar.gz` and
`gs://mybucket2/path/to/file2.tar.gz`.
``` json
```json
{
"builders": [
{

4
website/source/docs/post-processors/googlecompute-import.html.md
View File

@ -82,7 +82,7 @@ Here is a basic example. This assumes that the builder has produced an
compressed raw disk image artifact for us to work with, and that the GCS bucket
has been created.
``` json
```json
{
"type": "googlecompute-import",
"account_file": "account.json",
@ -100,7 +100,7 @@ server was running in GCE with the nested hypervisor feature enabled.
$ packer build -var serial=$(tty) build.json
``` json
```json
{
"variables": {
"serial": ""

6
website/source/docs/post-processors/manifest.html.md
View File

@ -53,7 +53,7 @@ post-processors such as Docker and Artifice.
You can simply add `{"type":"manifest"}` to your post-processor section. Below
is a more complete example:
``` json
```json
{
"post-processors": [
{
@ -70,7 +70,7 @@ is a more complete example:
An example manifest file looks like:
``` json
```json
{
"builds": [
{
@ -100,7 +100,7 @@ artifacts from the manifest by using `packer_run_uuid`.
The above manifest was generated with this packer.json:
``` json
```json
{
"builders": [
{

122
website/source/docs/post-processors/shell-local.html.md
View File

@ -19,7 +19,7 @@ some task with packer outputs and variables.
The example below is fully functional.
``` json
```json
{
"type": "shell-local",
"inline": ["echo foo"]
@ -173,6 +173,7 @@ still in beta. There will be some limitations as a result. For example, it will
likely not work unless both Packer and the scripts you want to run are both on
the C drive.
```json
{
"builders": [
{
@ -197,6 +198,7 @@ the C drive.
}
]
}
```
## Default Environmental Variables
@ -236,7 +238,7 @@ of files produced by a `builder` to a json file after each `builder` is run.
For example, if you wanted to package a file from the file builder into a
tarball, you might write this:
``` json
```json
{
"builders": [
{
@ -280,11 +282,13 @@ For a shell script, that means the script **must** exit with a zero code. You
Example of running a .cmd file on windows:
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest1"],
"scripts": ["./scripts/test_cmd.cmd"]
},
```json
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest1"],
"scripts": ["./scripts/test_cmd.cmd"]
}
```
Contents of "test\_cmd.cmd":
@ -293,23 +297,27 @@ Contents of "test\_cmd.cmd":
Example of running an inline command on windows: Required customization:
tempfile\_extension
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest2"],
"tempfile_extension": ".cmd",
"inline": ["echo %SHELLLOCALTEST%"]
},
```json
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest2"],
"tempfile_extension": ".cmd",
"inline": ["echo %SHELLLOCALTEST%"]
}
```
Example of running a bash command on windows using WSL: Required
customizations: use\_linux\_pathing and execute\_command
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest3"],
"execute_command": ["bash", "-c", "{{.Vars}} {{.Script}}"],
"use_linux_pathing": true,
"script": "./scripts/example_bash.sh"
}
```json
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest3"],
"execute_command": ["bash", "-c", "{{.Vars}} {{.Script}}"],
"use_linux_pathing": true,
"script": "./scripts/example_bash.sh"
}
```
Contents of "example\_bash.sh":
@ -319,53 +327,63 @@ Contents of "example\_bash.sh":
Example of running a powershell script on windows: Required customizations:
env\_var\_format and execute\_command
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest4"],
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"script": "./scripts/example_ps.ps1"
}
```json
{
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest4"],
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"script": "./scripts/example_ps.ps1"
}
```
Example of running a powershell script on windows as "inline": Required
customizations: env\_var\_format, tempfile\_extension, and execute\_command
{
"type": "shell-local",
"tempfile_extension": ".ps1",
"environment_vars": ["SHELLLOCALTEST=ShellTest5"],
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"inline": ["write-output $env:SHELLLOCALTEST"]
}
```json
{
"type": "shell-local",
"tempfile_extension": ".ps1",
"environment_vars": ["SHELLLOCALTEST=ShellTest5"],
"execute_command": ["powershell.exe", "{{.Vars}} {{.Script}}"],
"env_var_format": "$env:%s=\"%s\"; ",
"inline": ["write-output $env:SHELLLOCALTEST"]
}
```
### Unix Host
Example of running a bash script on unix:
{
"type": "shell-local",
"environment_vars": ["PROVISIONERTEST=ProvisionerTest1"],
"scripts": ["./scripts/example_bash.sh"]
}
```json
{
"type": "shell-local",
"environment_vars": ["PROVISIONERTEST=ProvisionerTest1"],
"scripts": ["./scripts/example_bash.sh"]
}
```
Example of running a bash "inline" on unix:
{
"type": "shell-local",
"environment_vars": ["PROVISIONERTEST=ProvisionerTest2"],
"inline": ["echo hello",
"echo $PROVISIONERTEST"]
}
```json
{
"type": "shell-local",
"environment_vars": ["PROVISIONERTEST=ProvisionerTest2"],
"inline": ["echo hello",
"echo $PROVISIONERTEST"]
}
```
Example of running a python script on unix:
{
"type": "shell-local",
"script": "hello.py",
"environment_vars": ["HELLO_USER=packeruser"],
"execute_command": ["/bin/sh", "-c", "{{.Vars}} /usr/local/bin/python {{.Script}}"]
}
```json
{
"type": "shell-local",
"script": "hello.py",
"environment_vars": ["HELLO_USER=packeruser"],
"execute_command": ["/bin/sh", "-c", "{{.Vars}} /usr/local/bin/python {{.Script}}"]
}
```
Where "hello.py" contains:

2
website/source/docs/post-processors/ucloud-import.html.md
View File

@ -63,7 +63,7 @@ are two categories: required and optional parameters.
Here is a basic example. This assumes that the builder has produced a RAW artifact for us to work with. This will take the RAW image generated by a builder and upload it to UFile. Once uploaded, the import process will start, creating an UCloud UHost image to the region `cn-bj2`.
``` json
```json
"post-processors":[
{
"type":"ucloud-import",

2
website/source/docs/post-processors/vagrant-cloud.html.md
View File

@ -121,7 +121,7 @@ Failure to chain the post-processors together in this way will result in the
wrong artifact being supplied to the Vagrant Cloud post-processor. This will
likely cause the Vagrant Cloud post-processor to error and fail.
``` json
```json
{
"variables": {
"cloud_token": "{{ env `VAGRANT_CLOUD_TOKEN` }}",

2
website/source/docs/post-processors/vagrant.html.md
View File

@ -111,7 +111,7 @@ post-processor lets you do this.
Specify overrides within the `override` configuration by provider name:
``` json
```json
{
"type": "vagrant",
"compression_level": 1,

4
website/source/docs/post-processors/vsphere-template.html.md
View File

@ -22,7 +22,7 @@ a VM as a template and leaving it in a path of choice.
An example is shown below, showing only the post-processor configuration:
``` json
```json
{
"type": "vsphere-template",
"host": "vcenter.local",
@ -91,7 +91,7 @@ sequence definition (a collection of post-processors that are treated as as
single pipeline, see [Post-Processors](/docs/templates/post-processors.html)
for more information):
``` json
```json
{
"post-processors": [
[

2
website/source/docs/provisioners/ansible-local.html.md.erb
View File

@ -32,7 +32,7 @@ do this.
The example below is fully functional.
``` json
```json
{
"type": "ansible-local",
"playbook_file": "local.yml"

16
website/source/docs/provisioners/ansible.html.md.erb
View File

@ -75,7 +75,7 @@ Optional Parameters:
- `ansible_env_vars` (array of strings) - Environment variables to set before
running Ansible. Usage example:
``` json
```json
"ansible_env_vars": [ "ANSIBLE_HOST_KEY_CHECKING=False", "ANSIBLE_SSH_ARGS='-o ForwardAgent=yes -o ControlMaster=auto -o ControlPersist=60s'", "ANSIBLE_NOCOLOR=True" ]
```
This is a [template engine](/docs/templates/engine.html). Therefore, you
@ -86,7 +86,7 @@ Optional Parameters:
password that Packer uses to connect to a Windows instance via WinRM, you
can use the template variable {{.WinRMPassword}} in this option. Example:
``` json
```json
"ansible_env_vars": [ "WINRM_PASSWORD={{.WinRMPassword}}" ],
```
@ -102,7 +102,7 @@ Optional Parameters:
These arguments *will not* be passed through a shell and arguments should
not be quoted. Usage example:
``` json
```json
"extra_arguments": [ "--extra-vars", "Region={{user `Region`}} Stage={{user `Stage`}}" ]
```
@ -111,7 +111,7 @@ Optional Parameters:
connect to a Windows instance via WinRM, you can use the template variable
{{.WinRMPassword}} in this option. For example:
``` json
```json
"extra_arguments": [
"--extra-vars", "winrm_password={{ .WinRMPassword }}"
]
@ -212,7 +212,7 @@ commonly useful Ansible variables:
To debug underlying issues with Ansible, add `"-vvvv"` to `"extra_arguments"`
to enable verbose logging.
``` json
```json
"extra_arguments": [ "-vvvv" ]
```
@ -233,7 +233,7 @@ Redhat / CentOS builds have been known to fail with the following error due to
Building within a chroot (e.g. `amazon-chroot`) requires changing the Ansible
connection to chroot and running Ansible as root/sudo.
``` json
```json
{
"builders": [
{
@ -329,7 +329,7 @@ class Connection(SSHConnection):
This template should build a Windows Server 2012 image on Google Cloud
Platform:
``` json
```json
{
"variables": {},
"provisioners": [
@ -410,7 +410,7 @@ source /tmp/venv/bin/activate && ANSIBLE_FORCE_COLOR=1 PYTHONUNBUFFERED=1 /tmp/v
The ansible provisioner template remains very simple. For example:
``` json
```json
{
"type": "ansible",
"command": "/Path/To/call_ansible.sh",

2
website/source/docs/provisioners/breakpoint.html.md.erb
View File

@ -21,7 +21,7 @@ and between every provisioner.
## Basic Example
``` json
```json
{
"type": "breakpoint",
"note": "foo bar baz"

10
website/source/docs/provisioners/chef-client.html.md.erb
View File

@ -25,7 +25,7 @@ installed, using the official Chef installers provided by Chef.
The example below is fully functional. It will install Chef onto the remote
machine and run Chef client.
``` json
```json
{
"type": "chef-client",
"server_url": "https://mychefserver.com/"
@ -318,7 +318,7 @@ mode.
Set the necessary Packer variables using environment variables or provide a
[var file](/docs/templates/user-variables.html).
``` json
```json
"variables": {
"chef_dir": "/tmp/packer-chef-client"
}
@ -330,7 +330,7 @@ Make sure we have the correct directories and permissions for the `chef-client`
provisioner. You will need to bootstrap the Chef run by providing the necessary
cookbooks using Berkshelf or some other means.
``` json
```json
"provisioners": [
...
{ "type": "shell", "inline": [ "mkdir -p {{user `chef_dir`}}" ] },
@ -383,7 +383,7 @@ mode, while passing a `run_list` using a variable.
Set the necessary Packer variables using environment variables or provide a
[var file](/docs/templates/user-variables.html).
``` json
```json
"variables": {
"chef_dir": "{{env `PACKER_CHEF_DIR`}}",
"chef_run_list": "{{env `PACKER_CHEF_RUN_LIST`}}",
@ -400,7 +400,7 @@ Make sure we have the correct directories and permissions for the `chef-client`
provisioner. You will need to bootstrap the Chef run by providing the necessary
cookbooks using Berkshelf or some other means.
``` json
```json
{
"type": "file",
"source": "{{user `packer_chef_bootstrap_dir`}}",

2
website/source/docs/provisioners/chef-solo.html.md.erb
View File

@ -25,7 +25,7 @@ installed, using the official Chef installers provided by Chef Inc.
The example below is fully functional and expects cookbooks in the "cookbooks"
directory relative to your working directory.
``` json
```json
{
"type": "chef-solo",
"cookbook_paths": ["cookbooks"]

2
website/source/docs/provisioners/converge.html.md.erb
View File

@ -20,7 +20,7 @@ new images.
The example below is fully functional.
``` json
```json
{
"type": "converge",
"module": "https://raw.githubusercontent.com/asteris-llc/converge/master/samples/fileContent.hcl",

4
website/source/docs/provisioners/file.html.md.erb
View File

@ -27,7 +27,7 @@ The file provisioner can upload both single files and complete directories.
## Basic Example
``` json
```json
{
"type": "file",
"source": "app.tar.gz",
@ -132,7 +132,7 @@ total 0
-rw-r--r-- 1 mwhooker staff 0 Jan 27 17:10 files.tar
```
``` json
```json
{
"provisioners": [
{

8
website/source/docs/provisioners/inspec.html.md.erb
View File

@ -21,7 +21,7 @@ by Packer.
This is a fully functional template that will test an image on DigitalOcean.
Replace the mock `api_token` value with your own.
``` json
```json
{
"provisioners": [
{
@ -52,7 +52,7 @@ Optional Parameters:
- `inspec_env_vars` (array of strings) - Environment variables to set before
running InSpec. Usage example:
``` json
```json
"inspec_env_vars": [ "FOO=bar" ]
```
@ -62,7 +62,7 @@ Optional Parameters:
These arguments *will not* be passed through a shell and arguments should
not be quoted. Usage example:
``` json
```json
"extra_arguments": [ "--sudo", "--reporter", "json" ]
```
@ -126,7 +126,7 @@ commonly useful InSpec Attributes:
To debug underlying issues with InSpec, add `"-l"` to `"extra_arguments"` to
enable verbose logging.
``` json
```json
{
"extra_arguments": [ "-l", "debug" ]
}

14
website/source/docs/provisioners/powershell.html.md.erb
View File

@ -22,7 +22,7 @@ for details.
The example below is fully functional.
``` json
```json
{
"type": "powershell",
"inline": ["dir c:\\"]
@ -58,7 +58,7 @@ The example below is fully functional.
you can use the template variable `{{.WinRMPassword}}` to set this as an
environment variable. For example:
``` json
```json
{
"type": "powershell",
"environment_vars": "WINRMPASS={{.WinRMPassword}}",
@ -98,7 +98,7 @@ The example below is fully functional.
uses to connect to the instance via WinRM, you may do so by using the
template variable {{.WinRMPassword}}. For example:
``` json
```json
"elevated_user": "Administrator",
"elevated_password": "{{.WinRMPassword}}",
```
@ -106,7 +106,7 @@ The example below is fully functional.
If you specify an empty `elevated_password` value then the PowerShell
script is run as a service account. For example:
``` json
```json
"elevated_user": "SYSTEM",
"elevated_password": "",
```
@ -188,7 +188,7 @@ reconfigured to work on a remote system with
dollar sign backslash escaped so that it is not interpreted by the remote Bash
shell - Bash being the default shell for Cygwin environments.
``` json
```json
"provisioners": [
{
"type": "powershell",
@ -214,7 +214,7 @@ when they appear *directly* in the users own scripts. Note that where double
quotes appear within double quotes, the addition of a backslash escape is
required for the JSON template to be parsed correctly.
``` json
```json
"provisioners": [
{
"type": "powershell",
@ -244,7 +244,7 @@ Special characters appearing in user environment variable values and in the
`elevated_user` and `elevated_password` fields will be automatically dealt with
for the user. There is no need to use escapes in these instances.
``` json
```json
{
"variables": {
"psvar": "My$tring"

2
website/source/docs/provisioners/puppet-masterless.html.md.erb
View File

@ -32,7 +32,7 @@ this.
The example below is fully functional and expects the configured manifest file
to exist relative to your working directory.
``` json
```json
{
"type": "puppet-masterless",
"manifest_file": "site.pp"

2
website/source/docs/provisioners/puppet-server.html.md.erb
View File

@ -25,7 +25,7 @@ this.
The example below is fully functional and expects a Puppet server to be
accessible from your network.
``` json
```json
{
"type": "puppet-server",
"extra_arguments": "--test --pluginsync",

2
website/source/docs/provisioners/salt-masterless.html.md.erb
View File

@ -19,7 +19,7 @@ master.
The example below is fully functional.
``` json
```json
{
"type": "salt-masterless",
"local_state_tree": "/Users/me/salt"

6
website/source/docs/provisioners/shell-local.html.md.erb
View File

@ -25,7 +25,7 @@ scripts on a remote machine.
The example below is fully functional.
``` json
```json
{
"type": "shell-local",
"command": "echo foo"
@ -242,7 +242,7 @@ Example of running a .cmd file on windows:
"type": "shell-local",
"environment_vars": ["SHELLLOCALTEST=ShellTest1"],
"scripts": ["./scripts/test_cmd.cmd"]
},
}
Contents of "test\_cmd.cmd":
@ -256,7 +256,7 @@ tempfile\_extension
"environment_vars": ["SHELLLOCALTEST=ShellTest2"],
"tempfile_extension": ".cmd",
"inline": ["echo %SHELLLOCALTEST%"]
},
}
Example of running a bash command on windows using WSL: Required
customizations: use\_linux\_pathing and execute\_command

10
website/source/docs/provisioners/shell.html.md.erb
View File

@ -24,7 +24,7 @@ Shell](/docs/provisioners/windows-shell.html) provisioners.
The example below is fully functional.
``` json
```json
{
"type": "shell",
"inline": ["echo foo"]
@ -182,7 +182,7 @@ and Packer will start executing the next one before SSH actually quits and the
machine restarts. For this, put use "pause\_before" to make Packer wait before
executing the next script:
``` json
```json
{
"type": "shell",
"script": "script.sh",
@ -216,7 +216,7 @@ provisioner](/docs/provisioners/file.html) (more secure) or using `ssh-keyscan`
to populate the file (less secure). An example of the latter accessing github
would be:
``` json
```json
{
"type": "shell",
"inline": [
@ -259,7 +259,7 @@ would be:
can create race conditions. Your first provisioner can tell the machine to
wait until it completely boots.
``` json
```json
{
"type": "shell",
"inline": [ "sleep 10" ]
@ -271,7 +271,7 @@ would be:
Packer manages quoting for you, so you should't have to worry about it. Below
is an example of packer template inputs and what you should expect to get out:
``` json
```json
"provisioners": [
{
"type": "shell",

6
website/source/docs/provisioners/windows-restart.html.md.erb
View File

@ -26,7 +26,7 @@ so Windows must be completely booted in order to continue.
The example below is fully functional.
``` json
```json
{
"type": "windows-restart"
}
@ -64,11 +64,11 @@ Optional parameters:
- `restart_check_command` (string) - A command to execute to check if the
restart succeeded. This will be done in a loop. Example usage:
``` json
```json
{
"type": "windows-restart",
"restart_check_command": "powershell -command \"& {Write-Output 'restarted.'}\""
},
}
```
- `restart_timeout` (string) - The timeout to wait for the restart. By

2
website/source/docs/provisioners/windows-shell.html.md.erb
View File

@ -18,7 +18,7 @@ The windows-shell Packer provisioner runs commands on a Windows machine using
The example below is fully functional.
``` json
```json
{
"type": "windows-shell",
"inline": ["dir c:\\"]

4
website/source/docs/templates/builders.html.md vendored
View File

@ -23,7 +23,7 @@ referenced from the documentation for that specific builder.
Within a template, a section of builder definitions looks like this:
``` json
```json
{
"builders": [
// ... one or more builder definitions here
@ -45,7 +45,7 @@ settings. These are placed directly within the builder definition.
An example builder definition is shown below, in this case configuring the AWS
builder:
``` json
```json
{
"type": "amazon-ebs",
"access_key": "...",

8
website/source/docs/templates/engine.html.md vendored
View File

@ -91,7 +91,7 @@ Here is a full list of the available functions for reference.
These are unique to the SSH communicator and are unset when using other communicators.
__SSHPublicKey__ and __SSHPrivateKey__ can have escape sequences and special characters so their output should be single quoted to avoid surprises. For example:
```
```json
{
...
"provisioners": [
@ -213,7 +213,7 @@ are available to customize the
[`execute_command`](/docs/provisioners/shell.html#execute_command) parameter
used to determine how Packer will run the shell command.
``` liquid
```json
{
"provisioners": [
{
@ -353,7 +353,7 @@ isotime = June 7, 7:22:43pm 2014
Please note that double quote characters need escaping inside of templates (in
this case, on the `ami_name` value):
``` json
```json
{
"builders": [
{
@ -396,7 +396,7 @@ build_name = foo-bar-provider
Please note that double quote characters need escaping inside of templates (in
this case, on the `fixed-string` value):
``` json
```json
{
"post-processors": [
[

4
website/source/docs/templates/index.html.md vendored
View File

@ -70,7 +70,7 @@ JSON doesn't support comments and Packer reports unknown keys as validation
errors. If you'd like to comment your template, you can prefix a *root level*
key with an underscore. Example:
``` json
```json
{
"_comment": "This is a comment",
"builders": [
@ -93,7 +93,7 @@ There are a number of parameters which need to be provided for a functional
build to take place. See the [Amazon builder](/docs/builders/amazon.html)
documentation for more information.
``` json
```json
{
"builders": [
{

12
website/source/docs/templates/post-processors.html.md vendored
View File

@ -25,7 +25,7 @@ post-processor.
Within a template, a section of post-processor definitions looks like this:
``` json
```json
{
"post-processors": [
// ... one or more post-processor definitions here
@ -53,7 +53,7 @@ A **simple definition** is just a string; the name of the post-processor. An
example is shown below. Simple definitions are used when no additional
configuration is needed for the post-processor.
``` json
```json
{
"post-processors": ["compress"]
}
@ -66,7 +66,7 @@ post-processor. A detailed definition is used when additional configuration is
needed beyond simply the type for the post-processor. An example is shown
below.
``` json
```json
{
"post-processors": [
{
@ -88,7 +88,7 @@ compressed then uploaded, but the compressed result is not kept.
It is very important that any post processors that need to be run in order, be
sequenced!
``` json
```json
{
"post-processors": [
[
@ -113,7 +113,7 @@ In some cases, however, you may want to keep the intermediary artifacts. You
can tell Packer to keep these artifacts by setting the `keep_input_artifact`
configuration to `true`. An example is shown below:
``` json
```json
{
"post-processors": [
{
@ -151,7 +151,7 @@ will affect that post-processor and stop the sequence.
The `-except` option can specifically skip a named post processor. The `-only`
option *ignores* post-processors.
``` json
```json
[
{
// can be skipped when running `packer build -except vbox`

Some files were not shown because too many files have changed in this diff Show More