diff --git a/website/source/docs/basics/terminology.html.markdown b/website/source/docs/basics/terminology.html.markdown
index f41882a48..18f53cde8 100644
--- a/website/source/docs/basics/terminology.html.markdown
+++ b/website/source/docs/basics/terminology.html.markdown
@@ -11,49 +11,42 @@ Luckily, there are relatively few. This page documents all the terminology
required to understand and use Packer. The terminology is in alphabetical
order for easy referencing.
-
-**Artifacts** are the results of a single [build](#term-build), and are
-usually a set of IDs or files to represent a machine image. Every [builder](#term-builder)
-produces a single artifact. As an example, in the case of the Amazon EC2 builder,
-the artifact is a set of AMI IDs (one per region). For the VMware builder,
-the artifact is a directory of files comprising the created virtual machine.
+- `Artifacts` are the results of a single build, and are usually a set of IDs
+or files to represent a machine image. Every builder produces a single
+artifact. As an example, in the case of the Amazon EC2 builder, the artifact is
+a set of AMI IDs (one per region). For the VMware builder, the artifact is a
+directory of files comprising the created virtual machine.
-
-**Builds** are a single task that eventually produces an image for a single
-platform. Multiple builds run in parallel. Example usage in a sentence: "The Packer build
-produced an AMI to run our web application." Or: "Packer is running the builds
-now for VMware, AWS, and VirtualBox."
+- `Builds` are a single task that eventually produces an image for a single
+platform. Multiple builds run in parallel. Example usage in a
+sentence: "The Packer build produced an AMI to run our web application."
+Or: "Packer is running the builds now for VMware, AWS, and VirtualBox."
-
-**Builders** are components of Packer that are able to create a machine
+- `Builders` are components of Packer that are able to create a machine
image for a single platform. Builders read in some configuration and use
-that to run and generate a machine image. A builder is invoked as part of a [build](#term-build)
-in order to create the actual resulting images. Example builders include
+that to run and generate a machine image. A builder is invoked as part of a
+build in order to create the actual resulting images. Example builders include
VirtualBox, VMware, and Amazon EC2. Builders can be created and added to
Packer in the form of plugins.
-
-**Commands** are sub-commands for the `packer` program that perform some
+- `Commands` are sub-commands for the `packer` program that perform some
job. An example command is "build", which is invoked as `packer build`.
Packer ships with a set of commands out of the box in order to define
-its [command-line interface](#). Commands can also be created and added to
+its command-line interface. Commands can also be created and added to
Packer in the form of plugins.
-
-**Post-processors** are components of Packer that take the result of
-a [builder](#term-builder) or another post-processor and process that to
-create a new [artifact](#term-artifact). Examples of post-processors are
+- `Post-processors` are components of Packer that take the result of
+a builder or another post-processor and process that to
+create a new artifact. Examples of post-processors are
compress to compress artifacts, upload to upload artifacts, etc.
-
-**Provisioners** are components of Packer that install and configure
+- `Provisioners` are components of Packer that install and configure
software within a running machine prior to that machine being turned
into a static image. They perform the major work of making the image contain
useful software. Example provisioners include shell scripts, Chef, Puppet,
etc.
-
-**Templates** are JSON files which define one or more [builds](#term-build)
+- `Templates` are JSON files which define one or more builds
by configuring the various components of Packer. Packer is able to read a
template and use that information to create multiple machine images in
parallel.
diff --git a/website/source/docs/builders/amazon-chroot.html.markdown b/website/source/docs/builders/amazon-chroot.html.markdown
index 80aaf57e1..5a545a91a 100644
--- a/website/source/docs/builders/amazon-chroot.html.markdown
+++ b/website/source/docs/builders/amazon-chroot.html.markdown
@@ -17,12 +17,10 @@ this builder is able to build an EBS-backed AMI without launching a new
EC2 instance. This can dramatically speed up AMI builds for organizations
who need the extra fast build.
-
-
This is an advanced builder. If you're just getting
+~> **This is an advanced builder** If you're just getting
started with Packer, we recommend starting with the
-amazon-ebs builder, which is
-much easier to use.
-
+```javascript
{
"type": "amazon-chroot",
"access_key": "YOUR KEY HERE",
@@ -144,7 +142,7 @@ Here is a basic example. It is completely valid except for the access keys:
"source_ami": "ami-e81d5881",
"ami_name": "packer-amazon-chroot {{timestamp}}"
}
-
+```
## Chroot Mounts
@@ -162,14 +160,14 @@ These default mounts are usually good enough for anyone and are sane
defaults. However, if you want to change or add the mount points, you may
using the `chroot_mounts` configuration. Here is an example configuration:
-
+```javascript
{
"chroot_mounts": [
["proc", "proc", "/proc"],
["bind", "/dev", "/dev"]
]
}
-
+```
`chroot_mounts` is a list of a 3-tuples of strings. The three components
of the 3-tuple, in order, are:
@@ -200,7 +198,7 @@ the filesystem.
For debian based distributions you can setup a [policy-rc.d](http://people.debian.org/~hmh/invokerc.d-policyrc.d-specification.txt) file which will
prevent packages installed by your provisioners from starting services:
-
+```javascript
{
"type": "shell",
"inline": [
@@ -209,11 +207,13 @@ prevent packages installed by your provisioners from starting services:
"chmod a+x /usr/sbin/policy-rc.d"
]
},
-# ...
+
+// ...
+
{
"type": "shell",
"inline": [
"rm -f /usr/sbin/policy-rc.d"
]
}
-
+```
diff --git a/website/source/docs/builders/amazon-ebs.html.markdown b/website/source/docs/builders/amazon-ebs.html.markdown
index 5cbd4003a..4bfd78c5b 100644
--- a/website/source/docs/builders/amazon-ebs.html.markdown
+++ b/website/source/docs/builders/amazon-ebs.html.markdown
@@ -173,7 +173,7 @@ each category, the available configuration keys are alphabetized.
Here is a basic example. It is completely valid except for the access keys:
-
+```javascript
{
"type": "amazon-ebs",
"access_key": "YOUR KEY HERE",
@@ -184,14 +184,12 @@ Here is a basic example. It is completely valid except for the access keys:
"ssh_username": "ubuntu",
"ami_name": "packer-quick-start {{timestamp}}"
}
-
+```
-
-Note: Packer can also read the access key and secret
+-> **Note:** Packer can also read the access key and secret
access key from environmental variables. See the configuration reference in
the section above for more information on what environmental variables Packer
will look for.
-
## Accessing the Instance to Debug
@@ -206,7 +204,7 @@ running.
Here is an example using the optional AMI block device mappings. This will add
the /dev/sdb and /dev/sdc block device mappings to the finished AMI.
-
+```javascript
{
"type": "amazon-ebs",
"access_key": "YOUR KEY HERE",
@@ -217,24 +215,24 @@ the /dev/sdb and /dev/sdc block device mappings to the finished AMI.
"ssh_username": "ubuntu",
"ami_name": "packer-quick-start {{timestamp}}",
"ami_block_device_mappings": [
- {
- "device_name": "/dev/sdb",
- "virtual_name": "ephemeral0"
- },
- {
- "device_name": "/dev/sdc",
- "virtual_name": "ephemeral1"
- }
+ {
+ "device_name": "/dev/sdb",
+ "virtual_name": "ephemeral0"
+ },
+ {
+ "device_name": "/dev/sdc",
+ "virtual_name": "ephemeral1"
+ }
]
}
-
+```
## Tag Example
Here is an example using the optional AMI tags. This will add the tags
"OS_Version" and "Release" to the finished AMI.
-
+```javascript
{
"type": "amazon-ebs",
"access_key": "YOUR KEY HERE",
@@ -249,4 +247,4 @@ Here is an example using the optional AMI tags. This will add the tags
"Release": "Latest"
}
}
-
+```
diff --git a/website/source/docs/builders/amazon-instance.html.markdown b/website/source/docs/builders/amazon-instance.html.markdown
index db1cb132b..3fc5de7fc 100644
--- a/website/source/docs/builders/amazon-instance.html.markdown
+++ b/website/source/docs/builders/amazon-instance.html.markdown
@@ -23,12 +23,10 @@ quite a bit.
The builder does _not_ manage AMIs. Once it creates an AMI and stores it
in your account, it is up to you to use, delete, etc. the AMI.
-
-
Note: This builder requires that the
-
Amazon EC2 AMI Tools
+-> **Note** This builder requires that the
+[Amazon EC2 AMI Tools](http://aws.amazon.com/developertools/368)
are installed onto the machine. This can be done within a provisioner, but
must be done before the builder finishes running.
-
+```javascript
{
"type": "amazon-instance",
"access_key": "YOUR KEY HERE",
@@ -230,14 +228,12 @@ Here is a basic example. It is completely valid except for the access keys:
"ami_name": "packer-quick-start {{timestamp}}"
}
-
+```
-
-Note: Packer can also read the access key and secret
+-> **Note:** Packer can also read the access key and secret
access key from environmental variables. See the configuration reference in
the section above for more information on what environmental variables Packer
will look for.
-
## Accessing the Instance to Debug
@@ -271,7 +267,7 @@ across multiple lines for convenience of reading. The bundle volume command
is responsible for executing `ec2-bundle-vol` in order to store and image
of the root filesystem to use to create the AMI.
-```
+```text
sudo -n ec2-bundle-vol \
-k {{.KeyPath}} \
-u {{.AccountId}} \
@@ -287,13 +283,10 @@ sudo -n ec2-bundle-vol \
The available template variables should be self-explanatory based on the
parameters they're used to satisfy the `ec2-bundle-vol` command.
-
- Warning! Some versions of ec2-bundle-vol silently
-ignore all .pem and .gpg files during the bundling of the AMI, which can
-cause problems on some systems, such as Ubuntu. You may want to
-customize the bundle volume command to include those files (see the
---no-filter option of ec2-bundle-vol).
-
+~> **Warning!** Some versions of ec2-bundle-vol silently ignore all .pem and
+.gpg files during the bundling of the AMI, which can cause problems on some
+systems, such as Ubuntu. You may want to customize the bundle volume command
+to include those files (see the `--no-filter` option of ec2-bundle-vol).
### Bundle Upload Command
@@ -301,7 +294,7 @@ The default value for `bundle_upload_command` is shown below. It is split
across multiple lines for convenience of reading. The bundle upload command
is responsible for taking the bundled volume and uploading it to S3.
-```
+```text
sudo -n ec2-upload-bundle \
-b {{.BucketName}} \
-m {{.ManifestPath}} \
diff --git a/website/source/docs/builders/amazon.html.markdown b/website/source/docs/builders/amazon.html.markdown
index d406e9711..cec855f3f 100644
--- a/website/source/docs/builders/amazon.html.markdown
+++ b/website/source/docs/builders/amazon.html.markdown
@@ -25,11 +25,9 @@ AMI. Packer supports the following builders at the moment:
newcomers**. However, it is also the fastest way to build an EBS-backed
AMI since no new EC2 instance needs to be launched.
-
-
Don't know which builder to use? If in doubt, use the
-
amazon-ebs builder. It is
+-> **Don't know which builder to use?** If in doubt, use the
+[amazon-ebs builder](/docs/builders/amazon-ebs.html). It is
much easier to use and Amazon generally recommends EBS-backed images nowadays.
-
+```javascript
{
"Statement": [{
"Effect": "Allow",
@@ -69,4 +67,4 @@ The following policy document provides the minimal set permissions necessary for
"Resource" : "*"
}]
}
-
+```
diff --git a/website/source/docs/builders/digitalocean.html.markdown b/website/source/docs/builders/digitalocean.html.markdown
index f7ff676ea..ee714dcbb 100644
--- a/website/source/docs/builders/digitalocean.html.markdown
+++ b/website/source/docs/builders/digitalocean.html.markdown
@@ -93,13 +93,13 @@ each category, the available configuration keys are alphabetized.
Here is a basic example. It is completely valid as soon as you enter your
own access tokens:
-
+```javascript
{
"type": "digitalocean",
"client_id": "YOUR CLIENT ID",
"api_key": "YOUR API KEY"
}
-
+```
## Finding Image, Region, and Size IDs
diff --git a/website/source/docs/builders/docker.html.markdown b/website/source/docs/builders/docker.html.markdown
index bd6bba41f..d4b0b0151 100644
--- a/website/source/docs/builders/docker.html.markdown
+++ b/website/source/docs/builders/docker.html.markdown
@@ -31,13 +31,13 @@ run Packer within that environment.
Below is a fully functioning example. It doesn't do anything useful, since
no provisioners are defined, but it will effectively repackage an image.
-
+```javascript
{
"type": "docker",
"image": "ubuntu",
"export_path": "image.tar"
}
-
+```
## Basic Example: Commit
@@ -45,13 +45,13 @@ 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.
-
+```javascript
{
"type": "docker",
"image": "ubuntu",
"commit": true
}
-
+```
## Configuration Reference
@@ -113,9 +113,9 @@ If you set `commit`, see the next section.
The example below shows a full configuration that would import and push
the created image:
-
+```javascript
{
- "post-processors": [
+ "post-processors": [
[
{
"type": "docker-import",
@@ -126,12 +126,14 @@ the created image:
]
]
}
-
+```
If you want to do this manually, however, perhaps from a script, you can
import the image using the process below:
- docker import - registry.mydomain.com/mycontainer:latest < artifact.tar
+```text
+$ docker import - registry.mydomain.com/mycontainer:latest < artifact.tar
+```
You can then add additional tags and push the image as usual with `docker tag`
and `docker push`, respectively.
@@ -142,9 +144,9 @@ If you committed your container to an image, you probably want to tag,
save, push, etc. Packer can do this automatically for you. An example is
shown below which tags and pushes the image:
-
+```javascript
{
- "post-processors": [
+ "post-processors": [
[
{
"type": "docker-tag",
@@ -155,7 +157,7 @@ shown below which tags and pushes the image:
]
]
}
-
+```
## Dockerfiles
diff --git a/website/source/docs/builders/googlecompute.markdown b/website/source/docs/builders/googlecompute.markdown
index 94cbaa24b..fb63350a0 100644
--- a/website/source/docs/builders/googlecompute.markdown
+++ b/website/source/docs/builders/googlecompute.markdown
@@ -42,7 +42,7 @@ since no provisioners are defined, but it will effectively repackage an
existing GCE image. The client secrets file and private key file are the
files obtained in the previous section.
-
+```javascript
{
"type": "googlecompute",
"bucket_name": "my-project-packer-images",
@@ -52,7 +52,7 @@ files obtained in the previous section.
"source_image": "debian-7-wheezy-v20140718",
"zone": "us-central1-a"
}
-
+```
## Configuration Reference
@@ -98,9 +98,6 @@ each category, the available options are alphabetized and described.
* `machine_type` (string) - The machine type. Defaults to `n1-standard-1`.
* `metadata` (object of key/value strings)
-
* `network` (string) - The Google Compute network to use for the launched
instance. Defaults to `default`.
@@ -116,9 +113,6 @@ each category, the available options are alphabetized and described.
Defaults to "5m".
* `tags` (array of strings)
-
## Gotchas
diff --git a/website/source/docs/builders/null.html.markdown b/website/source/docs/builders/null.html.markdown
index 2153f90b8..af655922f 100644
--- a/website/source/docs/builders/null.html.markdown
+++ b/website/source/docs/builders/null.html.markdown
@@ -16,14 +16,14 @@ incurring high wait times. It does not create any kind of image or 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.
-
+```javascript
{
"type": "null",
"host": "127.0.0.1",
"ssh_username": "foo",
"ssh_password": "bar"
}
-
+```
## Configuration Reference
diff --git a/website/source/docs/builders/openstack.html.markdown b/website/source/docs/builders/openstack.html.markdown
index b9aa4d6a3..b94a81414 100644
--- a/website/source/docs/builders/openstack.html.markdown
+++ b/website/source/docs/builders/openstack.html.markdown
@@ -69,9 +69,6 @@ each category, the available configuration keys are alphabetized.
to this instance.
* `openstack_provider` (string)
-
* `project` (string) - The project name to boot the instance into. Some
OpenStack installations require this.
@@ -85,9 +82,7 @@ each category, the available configuration keys are alphabetized.
`SDK_PROVIDER` or `OS_AUTH_URL` (in that order), if set.
* `proxy_url` (string)
-
+
* `security_groups` (array of strings) - A list of security groups by name
to add to this instance.
@@ -120,7 +115,7 @@ each category, the available configuration keys are alphabetized.
Here is a basic example. This is a working example to build a
Ubuntu 12.04 LTS (Precise Pangolin) on Rackspace OpenStack cloud offering.
-
+```javascript
{
"type": "openstack",
"username": "",
@@ -134,14 +129,14 @@ Ubuntu 12.04 LTS (Precise Pangolin) on Rackspace OpenStack cloud offering.
"source_image": "23b564c9-c3e6-49f9-bc68-86c7a9ab5018",
"flavor": "2"
}
-
+```
## Basic Example: Private OpenStack cloud
This example builds an Ubuntu 14.04 image on a private OpenStack cloud,
powered by Metacloud.
-
+```javascript
{
"type": "openstack",
"ssh_username": "root",
@@ -149,7 +144,7 @@ powered by Metacloud.
"source_image": "91d9c168-d1e5-49ca-a775-3bfdbb6c97f1",
"flavor": "2"
}
-
+```
In this case, the connection information for connecting to OpenStack
doesn't appear in the template. That is because I source a standard
diff --git a/website/source/docs/builders/parallels-iso.html.markdown b/website/source/docs/builders/parallels-iso.html.markdown
index 52c343f44..2a63ca1a1 100644
--- a/website/source/docs/builders/parallels-iso.html.markdown
+++ b/website/source/docs/builders/parallels-iso.html.markdown
@@ -23,7 +23,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:
-
+```javascript
{
"type": "parallels-iso",
"guest_os_type": "ubuntu",
@@ -36,7 +36,7 @@ Ubuntu to self-install. Still, the example serves to show the basic configuratio
"ssh_wait_timeout": "30s",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now"
}
-
+```
It is important to add a `shutdown_command`. By default Packer halts the
virtual machine and the file system may not be sync'd. Thus, changes made in a
@@ -255,7 +255,7 @@ The available variables are:
Example boot command. This is actually a working boot command used to start
an Ubuntu 12.04 installer:
-
+```javascript
[
"<esc><esc><enter><wait>",
"/install/vmlinuz noapic ",
@@ -267,7 +267,7 @@ an Ubuntu 12.04 installer:
"keyboard-configuration/variant=USA console-setup/ask_detect=false ",
"initrd=/install/initrd.gz -- <enter>"
]
-
+```
## prlctl Commands
In order to perform extra customization of the virtual machine, a template can
@@ -280,14 +280,14 @@ 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:
-
+```javascript
{
"prlctl": [
["set", "{{.Name}}", "--memsize", "1024"],
["set", "{{.Name}}", "--cpus", "2"]
]
}
-
+```
The value of `prlctl` is an array of commands to execute. These commands are
executed in the order defined. So in the above example, the memory will be set
diff --git a/website/source/docs/builders/parallels-pvm.html.markdown b/website/source/docs/builders/parallels-pvm.html.markdown
index 66106e29d..161611f84 100644
--- a/website/source/docs/builders/parallels-pvm.html.markdown
+++ b/website/source/docs/builders/parallels-pvm.html.markdown
@@ -22,7 +22,7 @@ to finishing the build.
Here is a basic example. This example is functional if you have an PVM matching
the settings here.
-
+```javascript
{
"type": "parallels-pvm",
"parallels_tools_flavor": "lin"
@@ -32,7 +32,7 @@ the settings here.
"ssh_wait_timeout": "30s",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now"
}
-
+```
It is important to add a `shutdown_command`. By default Packer halts the
virtual machine and the file system may not be sync'd. Thus, changes made in a
@@ -207,14 +207,14 @@ 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:
-
+```javascript
{
"prlctl": [
["set", "{{.Name}}", "--memsize", "1024"],
["set", "{{.Name}}", "--cpus", "2"]
]
}
-
+```
The value of `prlctl` is an array of commands to execute. These commands are
executed in the order defined. So in the above example, the memory will be set
diff --git a/website/source/docs/builders/qemu.html.markdown b/website/source/docs/builders/qemu.html.markdown
index 68aa5bc4c..1c5ae283a 100644
--- a/website/source/docs/builders/qemu.html.markdown
+++ b/website/source/docs/builders/qemu.html.markdown
@@ -22,7 +22,7 @@ containing the image file 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.
-
+```javascript
{
"builders":
[
@@ -58,7 +58,7 @@ paths to files, URLS for ISOs and checksums.
}
]
}
-
+```
A working CentOS 6.x kickstart file can be found
[at this URL](https://gist.github.com/mitchellh/7328271/#file-centos6-ks-cfg), adapted from an unknown source.
@@ -172,17 +172,17 @@ each category, the available options are alphabetized and described.
switch/value pairs. Any value specified as an empty string is ignored.
All values after the switch are concatenated with no separater.
- WARNING: The qemu command line allows extreme flexibility, so beware of
- conflicting arguments causing failures of your run. For instance, using
- --no-acpi could break the ability to send power signal type commands (e.g.,
- shutdown -P now) to the virtual machine, thus preventing proper shutdown. To
- see the defaults, look in the packer.log file and search for the
- qemu-system-x86 command. The arguments are all printed for review.
+~> **Warning:** The qemu command line allows extreme flexibility, so beware of
+conflicting arguments causing failures of your run. For instance, using
+--no-acpi could break the ability to send power signal type commands (e.g.,
+shutdown -P now) to the virtual machine, thus preventing proper shutdown. To
+see the defaults, look in the packer.log file and search for the
+qemu-system-x86 command. The arguments are all printed for review.
The following shows a sample usage:
-
- . . .
+```javascript
+ // ...
"qemuargs": [
[ "-m", "1024m" ],
[ "--no-acpi", "" ],
@@ -194,14 +194,14 @@ each category, the available options are alphabetized and described.
],
[ "-device", "virtio-net,netdev=mynet0" ]
]
- . . .
-
+ // ...
+```
would produce the following (not including other defaults supplied by the builder and not otherwise conflicting with the qemuargs):
-
- qemu-system-x86 -m 1024m --no-acpi -netdev user,id=mynet0,hostfwd=hostip:hostport-guestip:guestport -device virtio-net,netdev=mynet0"
-
+```text
+qemu-system-x86 -m 1024m --no-acpi -netdev user,id=mynet0,hostfwd=hostip:hostport-guestip:guestport -device virtio-net,netdev=mynet0"
+```
* `qemu_binary` (string) - The name of the Qemu binary to look for. This
defaults to "qemu-system-x86_64", but may need to be changed for some
@@ -303,10 +303,10 @@ The available variables are:
Example boot command. This is actually a working boot command used to start
an CentOS 6.4 installer:
-
+```javascript
"boot_command":
[
"",
" ks=http://10.0.2.2:{{ .HTTPPort }}/centos6-ks.cfg"
]
-
+```
diff --git a/website/source/docs/builders/virtualbox-iso.html.markdown b/website/source/docs/builders/virtualbox-iso.html.markdown
index 4cef35156..3bee4b803 100644
--- a/website/source/docs/builders/virtualbox-iso.html.markdown
+++ b/website/source/docs/builders/virtualbox-iso.html.markdown
@@ -22,7 +22,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:
-
+```javascript
{
"type": "virtualbox-iso",
"guest_os_type": "Ubuntu_64",
@@ -34,7 +34,7 @@ Ubuntu to self-install. Still, the example serves to show the basic configuratio
"ssh_wait_timeout": "30s",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now"
}
-
+```
It is important to add a `shutdown_command`. By default Packer halts the
virtual machine and the file system may not be sync'd. Thus, changes made in a
@@ -280,7 +280,7 @@ The available variables are:
Example boot command. This is actually a working boot command used to start
an Ubuntu 12.04 installer:
-
+```javascript
[
"<esc><esc><enter><wait>",
"/install/vmlinuz noapic ",
@@ -292,7 +292,7 @@ an Ubuntu 12.04 installer:
"keyboard-configuration/variant=USA console-setup/ask_detect=false ",
"initrd=/install/initrd.gz -- <enter>"
]
-
+```
## Guest Additions
@@ -320,14 +320,14 @@ Extra VBoxManage commands are defined in the template in the `vboxmanage` sectio
An example is shown below that sets the memory and number of CPUs within the
virtual machine:
-
+```javascript
{
"vboxmanage": [
["modifyvm", "{{.Name}}", "--memory", "1024"],
["modifyvm", "{{.Name}}", "--cpus", "2"]
]
}
-
+```
The value of `vboxmanage` is an array of commands to execute. These commands
are executed in the order defined. So in the above example, the memory will be
diff --git a/website/source/docs/builders/virtualbox-ovf.html.markdown b/website/source/docs/builders/virtualbox-ovf.html.markdown
index 6db0a536e..66598eda1 100644
--- a/website/source/docs/builders/virtualbox-ovf.html.markdown
+++ b/website/source/docs/builders/virtualbox-ovf.html.markdown
@@ -21,7 +21,7 @@ to finishing the build.
Here is a basic example. This example is functional if you have an OVF matching
the settings here.
-
+```javascript
{
"type": "virtualbox-ovf",
"source_path": "source.ovf",
@@ -30,7 +30,7 @@ the settings here.
"ssh_wait_timeout": "30s",
"shutdown_command": "echo 'packer' | sudo -S shutdown -P now"
}
-
+```
It is important to add a `shutdown_command`. By default Packer halts the
virtual machine and the file system may not be sync'd. Thus, changes made in a
@@ -220,14 +220,14 @@ Extra VBoxManage commands are defined in the template in the `vboxmanage` sectio
An example is shown below that sets the memory and number of CPUs within the
virtual machine:
-
+```javascript
{
"vboxmanage": [
["modifyvm", "{{.Name}}", "--memory", "1024"],
["modifyvm", "{{.Name}}", "--cpus", "2"]
]
}
-
+```
The value of `vboxmanage` is an array of commands to execute. These commands
are executed in the order defined. So in the above example, the memory will be
diff --git a/website/source/docs/builders/vmware-iso.html.markdown b/website/source/docs/builders/vmware-iso.html.markdown
index 334c1974e..1f2e83b70 100644
--- a/website/source/docs/builders/vmware-iso.html.markdown
+++ b/website/source/docs/builders/vmware-iso.html.markdown
@@ -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:
-
+```javascript
{
"type": "vmware-iso",
"iso_url": "http://old-releases.ubuntu.com/releases/precise/ubuntu-12.04.2-server-amd64.iso",
@@ -39,7 +39,7 @@ Ubuntu to self-install. Still, the example serves to show the basic configuratio
"ssh_wait_timeout": "30s",
"shutdown_command": "shutdown -P now"
}
-
+```
## Configuration Reference
@@ -297,7 +297,7 @@ The available variables are:
Example boot command. This is actually a working boot command used to start
an Ubuntu 12.04 installer:
-
+```javascript
[
"<esc><esc><enter><wait>",
"/install/vmlinuz noapic ",
@@ -309,7 +309,7 @@ an Ubuntu 12.04 installer:
"keyboard-configuration/variant=USA console-setup/ask_detect=false ",
"initrd=/install/initrd.gz -- <enter>"
]
-
+```
## VMX Template
@@ -320,13 +320,9 @@ But for advanced users, this template can be customized. This allows
Packer to build virtual machines of effectively any guest operating system
type.
-
-
-This is an advanced feature. Modifying the VMX template
+~> **This is an advanced feature.** Modifying the VMX template
can easily cause your virtual machine to not boot properly. Please only
modify the template if you know what you're doing.
-
-
-Note: Packer supports ESXi 5.1 and above.
-
+-> **Note:** Packer supports ESXi 5.1 and above.
Before using a remote vSphere Hypervisor, you need to enable GuestIPHack by running the following command:
-```
+```text
esxcli system settings advanced set -o /Net/GuestIPHack -i 1
```
diff --git a/website/source/docs/builders/vmware-vmx.html.markdown b/website/source/docs/builders/vmware-vmx.html.markdown
index 1bf587b42..06821fbc9 100644
--- a/website/source/docs/builders/vmware-vmx.html.markdown
+++ b/website/source/docs/builders/vmware-vmx.html.markdown
@@ -26,7 +26,7 @@ contains a new 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:
-
+```javascript
{
"type": "vmware-vmx",
"source_path": "/path/to/a/vm.vmx",
@@ -34,7 +34,7 @@ path points to a real VMX file with the proper settings:
"ssh_password": "root",
"shutdown_command": "shutdown -P now"
}
-
+```
## Configuration Reference
diff --git a/website/source/docs/command-line/fix.html.markdown b/website/source/docs/command-line/fix.html.markdown
index fa96f394c..4657a1807 100644
--- a/website/source/docs/command-line/fix.html.markdown
+++ b/website/source/docs/command-line/fix.html.markdown
@@ -22,12 +22,10 @@ If fixing fails for any reason, the fix command will exit with a non-zero
exit status. Error messages appear on standard error, so if you're redirecting
output, you'll still see error messages.
-
-Even when Packer fix doesn't do anything to the template,
+-> **Even when Packer fix doesn't do anything** to the template,
the template will be outputted to standard out. Things such as configuration
key ordering and indentation may be changed. The output format however, is
pretty-printed for human readability.
-
The full list of fixes that the fix command performs is visible in the
help output, which can be seen via `packer fix -h`.
diff --git a/website/source/docs/command-line/inspect.html.markdown b/website/source/docs/command-line/inspect.html.markdown
index 62c52d282..676fae023 100644
--- a/website/source/docs/command-line/inspect.html.markdown
+++ b/website/source/docs/command-line/inspect.html.markdown
@@ -25,7 +25,7 @@ validate the syntax of your template by necessity.
Given a basic template, here is an example of what the output might
look like:
-```
+```text
$ packer inspect template.json
Variables and their defaults:
diff --git a/website/source/docs/command-line/machine-readable.html.markdown b/website/source/docs/command-line/machine-readable.html.markdown
index 1cdc06b4d..c33bf1cc2 100644
--- a/website/source/docs/command-line/machine-readable.html.markdown
+++ b/website/source/docs/command-line/machine-readable.html.markdown
@@ -22,7 +22,7 @@ all output to become machine-readable on stdout. Logging, if enabled,
continues to appear on stderr. An example of the output is shown
below:
-```
+```text
$ packer -machine-readable version
1376289459,,version,0.2.4
1376289459,,version-prerelease,
@@ -43,7 +43,7 @@ Python.
The format is:
-```
+```text
timestamp,target,type,data...
```
diff --git a/website/source/docs/command-line/validate.html.markdown b/website/source/docs/command-line/validate.html.markdown
index e05c9410a..40479ae2e 100644
--- a/website/source/docs/command-line/validate.html.markdown
+++ b/website/source/docs/command-line/validate.html.markdown
@@ -12,7 +12,7 @@ if a template doesn't validate, any error messages will be outputted.
Example usage:
-```
+```text
$ packer validate my-template.json
Template validation failed. Errors are shown below.
diff --git a/website/source/docs/extend/builder.html.markdown b/website/source/docs/extend/builder.html.markdown
index f9fff68ee..93ed9b5b2 100644
--- a/website/source/docs/extend/builder.html.markdown
+++ b/website/source/docs/extend/builder.html.markdown
@@ -15,11 +15,8 @@ the Packer plugin interface, and this page documents how to do that.
Prior to reading this page, it is assumed you have read the page on
[plugin development basics](/docs/extend/developing-plugins.html).
-
- Warning! This is an advanced topic. If you're new to Packer,
- we recommend getting a bit more comfortable before you dive into writing
- plugins.
-
+~> **Warning!** This is an advanced topic. If you're new to Packer, we
+recommend getting a bit more comfortable before you dive into writing plugins.
## The Interface
@@ -28,13 +25,13 @@ interface. It is reproduced below for easy reference. The actual interface
in the source code contains some basic documentation as well explaining
what each method should do.
-
+```go
type Builder interface {
Prepare(...interface{}) error
Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
Cancel()
}
-
+```
### The "Prepare" Method
@@ -133,19 +130,17 @@ When the machine is ready to be provisioned, run the `packer.HookProvision`
hook, making sure the communicator is not nil, since this is required for
provisioners. An example of calling the hook is shown below:
-
+```go
hook.Run(packer.HookProvision, ui, comm, nil)
-
+```
At this point, Packer will run the provisioners and no additional work
is necessary.
-
-Note: Hooks are still undergoing thought around their
+-> **Note:** Hooks are still undergoing thought around their
general design and will likely change in a future version. They aren't
fully "baked" yet, so they aren't documented here other than to tell you
how to hook in provisioners.
-
## Caching Files
diff --git a/website/source/docs/extend/command.html.markdown b/website/source/docs/extend/command.html.markdown
index 58211ca47..8f6e5414d 100644
--- a/website/source/docs/extend/command.html.markdown
+++ b/website/source/docs/extend/command.html.markdown
@@ -20,11 +20,8 @@ over what keyword invokes the command with the `packer` binary. The keyword
to invoke the command depends on how the plugin is installed and configured
in the core Packer configuration.
-
- Warning! This is an advanced topic. If you're new to Packer,
- we recommend getting a bit more comfortable before you dive into writing
- plugins.
-
+~> **Warning!** This is an advanced topic. If you're new to Packer, we
+recommend getting a bit more comfortable before you dive into writing plugins.
## The Interface
@@ -33,13 +30,13 @@ interface. It is reproduced below for easy reference. The actual interface
in the source code contains some basic documentation as well explaining
what each method should do.
-
+```go
type Command interface {
Help() string
Run(env Environment, args []string) int
Synopsis() string
}
-
+```
### The "Help" Method
@@ -52,7 +49,7 @@ Packer commands generally follow the following format for help, but
it is not required. You're allowed to make the help look like anything
you please.
-```
+```text
Usage: packer COMMAND [options] ARGS...
Brief one or two sentence about the function of the command.
diff --git a/website/source/docs/extend/developing-plugins.html.markdown b/website/source/docs/extend/developing-plugins.html.markdown
index 09bee3f0e..6f73030a9 100644
--- a/website/source/docs/extend/developing-plugins.html.markdown
+++ b/website/source/docs/extend/developing-plugins.html.markdown
@@ -15,11 +15,8 @@ assumed that you're familiar with the language. This page will not be a
Go language tutorial. Thankfully, if you are familiar with Go, the Go toolchain
makes it extremely easy to develop Packer plugins.
-
- Warning! This is an advanced topic. If you're new to Packer,
- we recommend getting a bit more comfortable before you dive into writing
- plugins.
-
+~> **Warning!** This is an advanced topic. If you're new to Packer, we
+recommend getting a bit more comfortable before you dive into writing plugins.
## Plugin System Architecture
@@ -68,7 +65,7 @@ There are two steps involved in creating a plugin:
A basic example is shown below. In this example, assume the `Builder` struct
implements the `packer.Builder` interface:
-
+```go
import (
"github.com/mitchellh/packer/plugin"
)
@@ -79,7 +76,7 @@ type Builder struct{}
func main() {
plugin.ServeBuilder(new(Builder))
}
-
+```
**That's it!** `plugin.ServeBuilder` handles all the nitty gritty of
communicating with Packer core and serving your builder over RPC. It
@@ -92,14 +89,12 @@ installed using standard installation procedures.
The specifics of how to implement each type of interface are covered
in the relevant subsections available in the navigation to the left.
-
-Lock your dependencies. Unfortunately, Go's dependency
+~> **Lock your dependencies!** Unfortunately, Go's dependency
management story is fairly sad. There are various unofficial methods out
there for locking dependencies, and using one of them is highly recomended
since the Packer codebase will continue to improve, potentially breaking
APIs along the way until there is a stable release. By locking your dependencies,
your plugins will continue to work with the version of Packer you lock to.
-
## Logging and Debugging
@@ -112,7 +107,7 @@ Packer will prefix any logs from plugins with the path to that plugin
to make it identifiable where the logs come from. Some example logs are
shown below:
-```
+```text
2013/06/10 21:44:43 ui: Available commands are:
2013/06/10 21:44:43 Loading command: build
2013/06/10 21:44:43 packer-command-build: 2013/06/10 21:44:43 Plugin minimum port: 10000
@@ -144,13 +139,13 @@ 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:
-
+```javascript
{
"builders": {
"custom-cloud": "/an/absolute/path/to/packer-builder-custom-cloud"
}
}
-
+```
This would configure Packer to have the "custom-cloud" plugin, and execute
the binary that I am building during development. This is extremely useful
diff --git a/website/source/docs/extend/plugins.html.markdown b/website/source/docs/extend/plugins.html.markdown
index 5be80be7d..dbef6c5d9 100644
--- a/website/source/docs/extend/plugins.html.markdown
+++ b/website/source/docs/extend/plugins.html.markdown
@@ -46,12 +46,12 @@ Once the plugin is named properly, Packer automatically discovers plugins
in the following directories in the given order. If a conflicting plugin is
found later, it will take precedence over one found earlier.
- 1. The directory where `packer` is, or the executable directory.
+1. The directory where `packer` is, or the executable directory.
- 2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d` on
+2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d` on
Windows.
- 3. The current working directory.
+3. The current working directory.
The valid types for plugins are:
diff --git a/website/source/docs/extend/post-processor.html.markdown b/website/source/docs/extend/post-processor.html.markdown
index a00e90b92..1d14b7485 100644
--- a/website/source/docs/extend/post-processor.html.markdown
+++ b/website/source/docs/extend/post-processor.html.markdown
@@ -21,11 +21,8 @@ Prior to reading this page, it is assumed you have read the page on
Post-processor plugins implement the `packer.PostProcessor` interface and
are served using the `plugin.ServePostProcessor` function.
-
- Warning! This is an advanced topic. If you're new to Packer,
- we recommend getting a bit more comfortable before you dive into writing
- plugins.
-
+~> **Warning!** This is an advanced topic. If you're new to Packer, we
+recommend getting a bit more comfortable before you dive into writing plugins.
## The Interface
@@ -35,13 +32,12 @@ The interface that must be implemented for a post-processor is the
The actual interface in the source code contains some basic documentation as well explaining
what each method should do.
-
-
+```go
type PostProcessor interface {
Configure(interface{}) error
PostProcess(Ui, Artifact) (a Artifact, keep bool, err error)
}
-
+```
### The "Configure" Method
diff --git a/website/source/docs/extend/provisioner.html.markdown b/website/source/docs/extend/provisioner.html.markdown
index 121338bb0..9d63e562a 100644
--- a/website/source/docs/extend/provisioner.html.markdown
+++ b/website/source/docs/extend/provisioner.html.markdown
@@ -16,12 +16,8 @@ Prior to reading this page, it is assumed you have read the page on
Provisioner plugins implement the `packer.Provisioner` interface and
are served using the `plugin.ServeProvisioner` function.
-
- Warning! This is an advanced topic. If you're new to Packer,
- we recommend getting a bit more comfortable before you dive into writing
- plugins.
-
-
+~> **Warning!** This is an advanced topic. If you're new to Packer, we
+recommend getting a bit more comfortable before you dive into writing plugins.
## The Interface
@@ -30,13 +26,12 @@ The interface that must be implemented for a provisioner is the
The actual interface in the source code contains some basic documentation as well explaining
what each method should do.
-
-
+```go
type Provisioner interface {
Prepare(...interface{}) error
Provision(Ui, Communicator) error
}
-
+```
### The "Prepare" Method
@@ -87,7 +82,7 @@ The documentation around the [code itself](https://github.com/mitchellh/packer/b
is really great as an overview of how to use the interface. You should begin
by reading this. Once you have read it, you can see some example usage below:
-
+```go
// Build the remote command.
var cmd packer.RemoteCmd
cmd.Command = "echo foo"
@@ -107,4 +102,4 @@ cmd.Wait()
// Read the stdout!
fmt.Printf("Command output: %s", stdout.String())
-
+```
diff --git a/website/source/docs/installation.html.markdown b/website/source/docs/installation.html.markdown
index 32fde782f..fd09d3197 100644
--- a/website/source/docs/installation.html.markdown
+++ b/website/source/docs/installation.html.markdown
@@ -36,13 +36,13 @@ contains instructions for setting the PATH on Windows.
After installing Packer, verify the installation worked by opening
a new command prompt or console, and checking that `packer` is available:
-```
+```text
$ packer
usage: packer [--version] [--help] []
Available commands are:
build build image(s) from template
- fix fixes templates from old versions of packer
+ fix fixes templates from old versions of packer
inspect see components of a template
validate check that a template is valid
```
@@ -67,7 +67,7 @@ If you're using OS X and [Homebrew](http://brew.sh), you can install Packer by
adding the `binary` tap. Remember that this is updated by a 3rd party, so
it may not be the latest available version.
-```
+```text
$ brew tap homebrew/binary
$ brew install packer
```
diff --git a/website/source/docs/post-processors/compress.html.markdown b/website/source/docs/post-processors/compress.html.markdown
index 79d2445bd..56df31700 100644
--- a/website/source/docs/post-processors/compress.html.markdown
+++ b/website/source/docs/post-processors/compress.html.markdown
@@ -21,9 +21,9 @@ The configuration for this post-processor is extremely simple.
An example is shown below, showing only the post-processor configuration:
-
+```javascript
{
"type": "compress",
"output": "foo.tar.gz"
}
-
+```
diff --git a/website/source/docs/post-processors/docker-import.html.markdown b/website/source/docs/post-processors/docker-import.html.markdown
index 5bfa399d4..23f29e243 100644
--- a/website/source/docs/post-processors/docker-import.html.markdown
+++ b/website/source/docs/post-processors/docker-import.html.markdown
@@ -28,13 +28,13 @@ a repository is required.
An example is shown below, showing only the post-processor configuration:
-
+```javascript
{
"type": "docker-import",
"repository": "mitchellh/packer",
"tag": "0.7"
}
-
+```
This example would take the image created by the Docker builder
and import it into the local Docker process with a name of `mitchellh/packer:0.7`.
diff --git a/website/source/docs/post-processors/docker-push.html.markdown b/website/source/docs/post-processors/docker-push.html.markdown
index 9883ce173..92d233f58 100644
--- a/website/source/docs/post-processors/docker-push.html.markdown
+++ b/website/source/docs/post-processors/docker-push.html.markdown
@@ -26,11 +26,9 @@ This post-processor has only optional configuration:
* `login_server` (string) - The server address to login to.
-
-Note: If you login using the credentials above, the
+-> **Note:** If you login using the credentials above, the
post-processor will automatically log you out afterwards (just the server
specified).
-
## Example
diff --git a/website/source/docs/post-processors/docker-save.html.markdown b/website/source/docs/post-processors/docker-save.html.markdown
index 88fe3be2c..3c4f87634 100644
--- a/website/source/docs/post-processors/docker-save.html.markdown
+++ b/website/source/docs/post-processors/docker-save.html.markdown
@@ -27,9 +27,9 @@ The configuration for this post-processor is extremely simple.
An example is shown below, showing only the post-processor configuration:
-
+```javascript
{
"type": "docker-save",
"path": "foo.tar"
}
-
+```
diff --git a/website/source/docs/post-processors/docker-tag.html.markdown b/website/source/docs/post-processors/docker-tag.html.markdown
index c60aab756..a66d95717 100644
--- a/website/source/docs/post-processors/docker-tag.html.markdown
+++ b/website/source/docs/post-processors/docker-tag.html.markdown
@@ -32,13 +32,13 @@ a repository is required.
An example is shown below, showing only the post-processor configuration:
-
+```javascript
{
"type": "docker-tag",
"repository": "mitchellh/packer",
"tag": "0.7"
}
-
+```
This example would take the image created by the Docker builder
and tag it into the local Docker process with a name of `mitchellh/packer:0.7`.
diff --git a/website/source/docs/post-processors/vagrant-cloud.html.markdown b/website/source/docs/post-processors/vagrant-cloud.html.markdown
index c30c56726..83b7c8e0a 100644
--- a/website/source/docs/post-processors/vagrant-cloud.html.markdown
+++ b/website/source/docs/post-processors/vagrant-cloud.html.markdown
@@ -76,14 +76,14 @@ You'll need to use the Vagrant post-processor before using this post-processor.
An example configuration is below. Note the use of the array specifying
the execution order.
-```json
+```javascript
{
"variables": {
"version": "",
"cloud_token": ""
},
"builders": [{
- ...
+ // ...
}],
"post-processors": [
[{
@@ -100,5 +100,4 @@ the execution order.
}]
]
}
-
```
diff --git a/website/source/docs/post-processors/vagrant.html.markdown b/website/source/docs/post-processors/vagrant.html.markdown
index 6950b2d90..5a26d0352 100644
--- a/website/source/docs/post-processors/vagrant.html.markdown
+++ b/website/source/docs/post-processors/vagrant.html.markdown
@@ -33,11 +33,9 @@ providers.
* VirtualBox
* VMware
-
-Support for additional providers is planned. If the
+-> **Support for additional providers** is planned. If the
Vagrant post-processor doesn't support creating boxes for a provider you
care about, please help by contributing to Packer and adding support for it.
-
## Configuration
@@ -84,16 +82,15 @@ The post-processor lets you do this.
Specify overrides within the `override` configuration by provider name:
-```json
+```javascript
{
- "type": "vagrant",
-
- "compression_level": 1,
- "override": {
- "vmware": {
- "compression_level": 0
- }
+ "type": "vagrant",
+ "compression_level": 1,
+ "override": {
+ "vmware": {
+ "compression_level": 0
}
+ }
}
```
diff --git a/website/source/docs/provisioners/ansible-local.html.markdown b/website/source/docs/provisioners/ansible-local.html.markdown
index ddc6c6399..70a45755b 100644
--- a/website/source/docs/provisioners/ansible-local.html.markdown
+++ b/website/source/docs/provisioners/ansible-local.html.markdown
@@ -15,12 +15,12 @@ from your local machine to the remote machine. Ansible is run in [local mode](h
The example below is fully functional.
-
+```javascript
{
- "type": "ansible-local",
- "playbook_file": "local.yml"
+ "type": "ansible-local",
+ "playbook_file": "local.yml"
}
-
+```
## Configuration Reference
@@ -48,7 +48,8 @@ Optional:
the `extra_arguments` option.
An example inventory file may look like:
-
+
+ ```text
[chi-dbservers]
db-01 ansible_connection=local
db-02 ansible_connection=local
@@ -66,7 +67,7 @@ Optional:
[appservers:children]
chi-appservers
-
+ ```
* `playbook_dir` (string) - a path to the complete ansible directory
structure on your local system to be copied to the remote machine
diff --git a/website/source/docs/provisioners/chef-client.html.markdown b/website/source/docs/provisioners/chef-client.html.markdown
index 36ae9ee8c..c54223997 100644
--- a/website/source/docs/provisioners/chef-client.html.markdown
+++ b/website/source/docs/provisioners/chef-client.html.markdown
@@ -20,12 +20,12 @@ installed, using the official Chef installers provided by Opscode.
The example below is fully functional. It will install Chef onto the
remote machine and run Chef client.
-
+```javascript
{
"type": "chef-client",
"server_url": "https://mychefserver.com/"
}
-
+```
Note: to properly clean up the Chef node and client, you must have
`knife` on your path and properly configured.
@@ -106,7 +106,7 @@ configuration template if you'd like to set custom configurations.
The default value for the configuration template is:
-```
+```liquid
log_level :info
log_location STDOUT
chef_server_url "{{.ServerUrl}}"
@@ -131,7 +131,7 @@ and has a set of variables available to use:
By default, Packer uses the following command (broken across multiple lines
for readability) to execute Chef:
-```
+```liquid
{{if .Sudo}}sudo {{end}}chef-client \
--no-color \
-c {{.ConfigPath}} \
@@ -154,7 +154,7 @@ By default, Packer uses the following command (broken across multiple lines
for readability) to install Chef. This command can be customized if you want
to install Chef in another way.
-```
+```text
curl -L https://www.opscode.com/chef/install.sh | \
{{if .Sudo}}sudo{{end}} bash
```
diff --git a/website/source/docs/provisioners/chef-solo.html.markdown b/website/source/docs/provisioners/chef-solo.html.markdown
index ba0bb3484..a69a7d810 100644
--- a/website/source/docs/provisioners/chef-solo.html.markdown
+++ b/website/source/docs/provisioners/chef-solo.html.markdown
@@ -20,12 +20,12 @@ installed, using the official Chef installers provided by Opscode.
The example below is fully functional and expects cookbooks in the
"cookbooks" directory relative to your working directory.
-
+```javascript
{
"type": "chef-solo",
"cookbook_paths": ["cookbooks"]
}
-
+```
## Configuration Reference
@@ -98,7 +98,7 @@ configuration template if you'd like to set custom configurations.
The default value for the configuration template is:
-```
+```liquid
cookbook_path [{{.CookbookPaths}}]
```
@@ -119,7 +119,7 @@ and has a set of variables available to use:
By default, Packer uses the following command (broken across multiple lines
for readability) to execute Chef:
-```
+```liquid
{{if .Sudo}}sudo {{end}}chef-solo \
--no-color \
-c {{.ConfigPath}} \
@@ -142,7 +142,7 @@ By default, Packer uses the following command (broken across multiple lines
for readability) to install Chef. This command can be customized if you want
to install Chef in another way.
-```
+```text
curl -L https://www.opscode.com/chef/install.sh | \
{{if .Sudo}}sudo{{end}} bash
```
diff --git a/website/source/docs/provisioners/file.html.markdown b/website/source/docs/provisioners/file.html.markdown
index 4dea52ad8..fda01efc2 100644
--- a/website/source/docs/provisioners/file.html.markdown
+++ b/website/source/docs/provisioners/file.html.markdown
@@ -16,13 +16,13 @@ The file provisioner can upload both single files and complete directories.
## Basic Example
-
+```javascript
{
"type": "file",
"source": "app.tar.gz",
"destination": "/tmp/app.tar.gz"
}
-
+```
## Configuration Reference
diff --git a/website/source/docs/provisioners/puppet-masterless.html.markdown b/website/source/docs/provisioners/puppet-masterless.html.markdown
index 8571b9355..5864428a0 100644
--- a/website/source/docs/provisioners/puppet-masterless.html.markdown
+++ b/website/source/docs/provisioners/puppet-masterless.html.markdown
@@ -14,25 +14,23 @@ use remote paths (perhaps obtained using something like the shell provisioner).
Puppet is run in masterless mode, meaning it never communicates to a Puppet
master.
-
-
Note that Puppet will not be installed automatically
-by this provisioner. This provisioner expects that Puppet is already
+-> **Note:** Puppet will _not_ be installed automatically
+by this provisioner. This provisioner expects that Puppet is already
installed on the machine. It is common practice to use the
-
shell provisioner before the
+[shell provisioner[(/docs/provisioners/shell.html) before the
Puppet provisioner to do this.
-
+```javascript
{
"type": "puppet-masterless",
"manifest_file": "site.pp"
}
-
+```
## Configuration Reference
@@ -84,7 +82,7 @@ Optional parameters:
By default, Packer uses the following command (broken across multiple lines
for readability) to execute Puppet:
-```
+```liquid
{{.FacterVars}}{{if .Sudo}} sudo -E {{end}}puppet apply \
--verbose \
--modulepath='{{.ModulePath}}' \
@@ -106,4 +104,3 @@ can contain various template variables, defined below:
* `ModulePath` - The paths to the module directories.
* `Sudo` - A boolean of whether to `sudo` the command or not, depending on
the value of the `prevent_sudo` configuration.
-
diff --git a/website/source/docs/provisioners/puppet-server.html.markdown b/website/source/docs/provisioners/puppet-server.html.markdown
index 11a7bbd96..c1847db23 100644
--- a/website/source/docs/provisioners/puppet-server.html.markdown
+++ b/website/source/docs/provisioners/puppet-server.html.markdown
@@ -10,20 +10,18 @@ Type: `puppet-server`
The `puppet-server` provisioner provisions Packer machines with Puppet
by connecting to a Puppet master.
-
-
Note that Puppet will not be installed automatically
-by this provisioner. This provisioner expects that Puppet is already
+-> **Note:** Puppet will _not_ be installed automatically
+by this provisioner. This provisioner expects that Puppet is already
installed on the machine. It is common practice to use the
-
shell provisioner before the
+[shell provisioner](/docs/provisioners/shell.html) before the
Puppet provisioner to do this.
-
+```javascript
{
"type": "puppet-server",
"options": "--test --pluginsync",
@@ -31,7 +29,7 @@ from your network.:
"server_role": "webserver"
}
}
-
+```
## Configuration Reference
diff --git a/website/source/docs/provisioners/salt-masterless.html.markdown b/website/source/docs/provisioners/salt-masterless.html.markdown
index 76128a87c..c398c26ff 100644
--- a/website/source/docs/provisioners/salt-masterless.html.markdown
+++ b/website/source/docs/provisioners/salt-masterless.html.markdown
@@ -14,12 +14,12 @@ The `salt-masterless` provisioner provisions machines built by Packer using
The example below is fully functional.
-
+```javascript
{
- "type": "salt-masterless",
- "local_state_tree": "/Users/me/salt"
+ "type": "salt-masterless",
+ "local_state_tree": "/Users/me/salt"
}
-
+```
## Configuration Reference
diff --git a/website/source/docs/provisioners/shell.html.markdown b/website/source/docs/provisioners/shell.html.markdown
index 93fa3346d..b5dae4b5d 100644
--- a/website/source/docs/provisioners/shell.html.markdown
+++ b/website/source/docs/provisioners/shell.html.markdown
@@ -15,12 +15,12 @@ on a machine.
The example below is fully functional.
-
+```javascript
{
"type": "shell",
"inline": ["echo foo"]
}
-
+```
## Configuration Reference
@@ -87,7 +87,7 @@ For example, if the default user of an installed operating system is "packer"
and has the password "packer" for sudo usage, then you'll likely want to
change `execute_command` to be:
-```
+```text
"echo 'packer' | {{ .Vars }} sudo -E -S sh '{{ .Path }}'"
```
@@ -128,7 +128,7 @@ return and Packer will start executing the next one before SSH actually
quits and the machine restarts. For this, put a long `sleep` after the
reboot so that SSH will eventually be killed automatically:
-```
+```text
reboot
sleep 60
```
@@ -138,7 +138,7 @@ reboot, causing the provisioner to hang despite a reboot occuring.
In this case, make sure you shut down the network interfaces
on reboot or in your shell script. For example, on Gentoo:
-```
+```text
/etc/init.d/net.eth0 stop
```
@@ -173,9 +173,9 @@ will echo the script statements as it is executing.
can create race conditions. Your first provisoner can tell the machine to
wait until it completely boots.
-
- {
- "type": "shell",
- "inline": [ "sleep 10" ]
- }
-
+```javascript
+{
+ "type": "shell",
+ "inline": [ "sleep 10" ]
+}
+```
diff --git a/website/source/docs/templates/builders.html.markdown b/website/source/docs/templates/builders.html.markdown
index 1a46f54bd..de99a9eca 100644
--- a/website/source/docs/templates/builders.html.markdown
+++ b/website/source/docs/templates/builders.html.markdown
@@ -19,13 +19,13 @@ must be referenced from the documentation for that specific builder.
Within a template, a section of builder definitions looks like this:
-
+```javascript
{
"builders": [
- ... one or more builder definitions here ...
+ // ... one or more builder definitions here
]
}
-
+```
## Builder Definition
@@ -41,13 +41,13 @@ some other settings. These are placed directly within the builder definition.
An example builder definition is shown below, in this case configuring
the AWS builder:
-
+```javascript
{
"type": "amazon-ebs",
"access_key": "...",
"secret_key": "..."
}
-
+```
## Named Builds
diff --git a/website/source/docs/templates/configuration-templates.html.markdown b/website/source/docs/templates/configuration-templates.html.markdown
index c88644ded..cd086af29 100644
--- a/website/source/docs/templates/configuration-templates.html.markdown
+++ b/website/source/docs/templates/configuration-templates.html.markdown
@@ -32,20 +32,20 @@ within the braces, such as `{{timestamp}}`.
Here is an example from the VMware VMX template that shows configuration
templates in action:
-
+```liquid
.encoding = "UTF-8"
displayName = "{{ .Name }}"
guestOS = "{{ .GuestOS }}"
-
+```
In this case, the "Name" and "GuestOS" variables will be replaced, potentially
resulting in a VMX that looks like this:
-
+```liquid
.encoding = "UTF-8"
displayName = "packer"
guestOS = "otherlinux"
-
+```
## Global Functions
@@ -66,54 +66,58 @@ in Packer templates. These are listed below for reference.
Formatting for the function `isotime` uses the magic reference date
**Mon Jan 2 15:04:05 -0700 MST 2006**, which breaks down to the following:
-
-
- |
- Day of Week |
- Month |
- Date |
- Hour |
- Minute |
- Second |
- Year |
- Timezone |
-
-
- | Numeric |
- - |
- 01 |
- 02 |
- 03 (15) |
- 04 |
- 05 |
- 06 |
- -0700 |
-
-
- | Textual |
- Monday (Mon) |
- January (Jan) |
- - |
- - |
- - |
- - |
- - |
- MST |
-
-
+
+
+
+
+ |
+Day of Week |
+Month |
+Date |
+Hour |
+Minute |
+Second |
+Year |
+Timezone |
+
+
+
+| Numeric |
+- |
+01 |
+02 |
+03 (15) |
+04 |
+05 |
+06 |
+-0700 |
+
+
+| Textual |
+Monday (Mon) |
+January (Jan) |
+- |
+- |
+- |
+- |
+- |
+MST |
+
+
+
+```liquid
isotime = June 7, 7:22:43pm 2014
{{isotime "2006-01-02"}} = 2014-06-07
{{isotime "Mon 1506"}} = Sat 1914
{{isotime "01-Jan-06 03\_04\_05"}} = 07-Jun-2014 07\_22\_43
{{isotime "Hour15Year200603"}} = Hour19Year201407
-
+```
## Amazon Specific Functions
diff --git a/website/source/docs/templates/introduction.html.markdown b/website/source/docs/templates/introduction.html.markdown
index f2eb08129..26b618c7d 100644
--- a/website/source/docs/templates/introduction.html.markdown
+++ b/website/source/docs/templates/introduction.html.markdown
@@ -62,7 +62,7 @@ Below is an example of a basic template that is nearly fully functional. It is j
missing valid AWS access keys. Otherwise, it would work properly with
`packer build`.
-
+```javascript
{
"builders": [
{
@@ -84,4 +84,4 @@ missing valid AWS access keys. Otherwise, it would work properly with
}
]
}
-
+```
diff --git a/website/source/docs/templates/post-processors.html.markdown b/website/source/docs/templates/post-processors.html.markdown
index ccc9edbb7..8a8adec89 100644
--- a/website/source/docs/templates/post-processors.html.markdown
+++ b/website/source/docs/templates/post-processors.html.markdown
@@ -19,13 +19,13 @@ however, must be referenced from the documentation for that specific post-proces
Within a template, a section of post-processor definitions looks like this:
-
+```javascript
{
"post-processors": [
- ... one or more post-processor definitions here ...
+ // ... one or more post-processor definitions here
]
}
-
+```
For each post-processor definition, Packer will take the result of each of the
defined builders and send it through the post-processors. This means that if you
@@ -46,11 +46,11 @@ 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.
-
+```javascript
{
"post-processors": ["compress"]
}
-
+```
A **detailed definition** is a JSON object. It is very similar to a builder
or provisioner definition. It contains a `type` field to denote the type of
@@ -58,7 +58,7 @@ the post-processor, but may also contain additional configuration for the
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.
-
+```javascript
{
"post-processors": [
{
@@ -67,7 +67,7 @@ is needed beyond simply the type for the post-processor. An example is shown bel
}
]
}
-
+```
A **sequence definition** is a JSON array comprised of other **simple** or
**detailed** definitions. The post-processors defined in the array are run
@@ -77,7 +77,7 @@ sequence definition. Sequence definitions are used to chain together multiple
post-processors. An example is shown below, where the artifact of a build is
compressed then uploaded, but the compressed result is not kept.
-
+```javascript
{
"post-processors": [
[
@@ -86,7 +86,7 @@ compressed then uploaded, but the compressed result is not kept.
]
]
}
-
+```
As you may be able to imagine, the **simple** and **detailed** definitions
are simply shortcuts for a **sequence** definition of only one element.
@@ -102,7 +102,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:
-
+```javascript
{
"post-processors": [
{
@@ -111,21 +111,19 @@ You can tell Packer to keep these artifacts by setting the
}
]
}
-
+```
This setting will only keep the input artifact to _that specific_
post-processor. If you're specifying a sequence of post-processors, then
all intermediaries are discarded by default except for the input artifacts
to post-processors that explicitly state to keep the input artifact.
-
-Note: The intuitive reader may be wondering what happens
+-> **Note:** The intuitive reader may be wondering what happens
if multiple post-processors are specified (not in a sequence). Does Packer require the
configuration to keep the input artifact on all the post-processors?
The answer is no, of course not. Packer is smart enough to figure out
that at least one post-processor requested that the input be kept, so it will keep
it around.
-
## Run on Specific Builds
@@ -140,12 +138,12 @@ is effectively the same. `only` and `except` can only be specified on "detailed"
configurations. If you have a sequence of post-processors to run, `only`
and `except` will only affect that single post-processor in the sequence.
-
+```javascript
{
"type": "vagrant",
"only": ["virtualbox-iso"]
}
-
+```
The values within `only` or `except` are _build names_, not builder
types. If you recall, build names by default are just their builder type,
diff --git a/website/source/docs/templates/provisioners.html.markdown b/website/source/docs/templates/provisioners.html.markdown
index c26d3e163..7da902c54 100644
--- a/website/source/docs/templates/provisioners.html.markdown
+++ b/website/source/docs/templates/provisioners.html.markdown
@@ -21,13 +21,13 @@ must be referenced from the documentation for that specific provisioner.
Within a template, a section of provisioner definitions looks like this:
-
+```javascript
{
"provisioners": [
- ... one or more provisioner definitions here ...
+ // ... one or more provisioner definitions here
]
}
-
+```
For each of the definitions, Packer will run the provisioner for each
of the configured builds. The provisioners will be run in the order
@@ -47,12 +47,12 @@ being created.
An example provisioner definition is shown below, configuring the shell
provisioner to run a local script within the machines:
-
+```javascript
{
"type": "shell",
"script": "script.sh"
}
-
+```
## Run on Specific Builds
@@ -65,13 +65,13 @@ builds.
An example of `only` being used is shown below, but the usage of `except`
is effectively the same:
-
+```javascript
{
"type": "shell",
"script": "script.sh",
"only": ["virtualbox-iso"]
}
-
+```
The values within `only` or `except` are _build names_, not builder
types. If you recall, build names by default are just their builder type,
@@ -95,7 +95,7 @@ identical. However, they may initially need to be run differently.
This example is shown below:
-
+```javascript
{
"type": "shell",
"script": "script.sh",
@@ -106,7 +106,7 @@ This example is shown below:
}
}
}
-
+```
As you can see, the `override` key is used. The value of this key is another
JSON object where the key is the name of a [builder definition](/docs/templates/builders.html).
@@ -126,13 +126,13 @@ configuration `pause_before` that is the amount of time to pause before
running that provisioner. By default, there is no pause. An example
is shown below:
-
+```javascript
{
"type": "shell",
"script": "script.sh",
"pause_before": "10s"
}
-
+```
For the above provisioner, Packer will wait 10 seconds before uploading
and executing the shell script.
diff --git a/website/source/docs/templates/user-variables.html.markdown b/website/source/docs/templates/user-variables.html.markdown
index c5415c4d8..e17d831d7 100644
--- a/website/source/docs/templates/user-variables.html.markdown
+++ b/website/source/docs/templates/user-variables.html.markdown
@@ -27,7 +27,7 @@ The `variables` section is a simple key/value mapping of the variable
name to a default value. A default value can be the empty string. An
example is shown below:
-
+```javascript
{
"variables": {
"aws_access_key": "",
@@ -38,10 +38,10 @@ example is shown below:
"type": "amazon-ebs",
"access_key": "{{user `aws_access_key`}}",
"secret_key": "{{user `aws_secret_key`}}",
- ...
+ // ...
}]
}
-
+```
In the above example, the template defines two variables: `aws_access_key` and
`aws_secret_key`. They default to empty values.
@@ -65,28 +65,26 @@ variables. The `env` function is available _only_ within the default value
of a user variable, allowing you to default a user variable to an
environmental variable. An example is shown below:
-
+```javascript
{
"variables": {
"my_secret": "{{env `MY_SECRET`}}",
},
- ...
+ // ...
}
-
+```
This will default "my\_secret" to be the value of the "MY\_SECRET"
environmental variable (or the empty string if it does not exist).
-
-Why can't I use environmental variables elsewhere?
+-> **Why can't I use environmental variables elsewhere?**
User variables are the single source of configurable input to a template.
-We felt that having environmental variables used anywhere in a
+We felt that having environmental variables used _anywhere_ in a
template would confuse the user about the possible inputs to a template.
By allowing environmental variables only within default values for user
variables, user variables remain as the single source of input to a template
-that a user can easily discover using packer inspect.
-
+that a user can easily discover using `packer inspect`.
## Setting Variables
@@ -103,7 +101,7 @@ above, we could build our template using the command below. The command
is split across multiple lines for readability, but can of course be a single
line.
-```
+```text
$ packer build \
-var 'aws_access_key=foo' \
-var 'aws_secret_key=bar' \
@@ -124,18 +122,18 @@ Variables can also be set from an external JSON file. The `-var-file`
flag reads a file containing a basic key/value mapping of variables to
values and sets those variables. The JSON file is simple:
-
+```javascript
{
"aws_access_key": "foo",
"aws_secret_key": "bar"
}
-
+```
It is a single JSON object where the keys are variables and the values are
the variable values. Assuming this file is in `variables.json`, we can
build our template using the following command:
-```
+```text
$ packer build -var-file=variables.json template.json
```
diff --git a/website/source/docs/templates/veewee-to-packer.html.markdown b/website/source/docs/templates/veewee-to-packer.html.markdown
index 1fbb43edf..2899372ac 100644
--- a/website/source/docs/templates/veewee-to-packer.html.markdown
+++ b/website/source/docs/templates/veewee-to-packer.html.markdown
@@ -17,7 +17,7 @@ of templates that can be readily used with Packer by simply converting them.
Since Veewee itself is a Ruby project, so too is the veewee-to-packer
application so that it can read the Veewee configurations. Install it using RubyGems:
-```
+```text
$ gem install veewee-to-packer
...
```
@@ -27,7 +27,7 @@ at the `definition.rb` file of any template. The converter will output
any warnings or messages about the conversion. The example below converts
a CentOS template:
-```
+```text
$ veewee-to-packer templates/CentOS-6.4/definition.rb
Success! Your Veewee definition was converted to a Packer
template! The template can be found in the `template.json` file
diff --git a/website/source/downloads.html.erb b/website/source/downloads.html.erb
index 52c7cccff..aba1a31f7 100644
--- a/website/source/downloads.html.erb
+++ b/website/source/downloads.html.erb
@@ -12,7 +12,7 @@ page_title: "Downloads"
-
+
Below are all available downloads for the latest version of Packer
(<%= latest_version %>). Please download the proper package for your
@@ -23,7 +23,7 @@ page_title: "Downloads"
<% product_versions.each do |os, versions| %>
-
+
<%= system_icon(os) %>
<%= os %>
@@ -39,7 +39,7 @@ page_title: "Downloads"
<% end %>
-
+
diff --git a/website/source/index.html.erb b/website/source/index.html.erb
index 3d4f3522e..9138f24ad 100644
--- a/website/source/index.html.erb
+++ b/website/source/index.html.erb
@@ -3,7 +3,7 @@
-
+
Packer is a tool for creating identical machine images for multiple platforms from a single source configuration.
@@ -26,11 +26,11 @@
-
- <%= image_tag 'screenshots/vmware_and_virtualbox.png' %>
+
+ <%= image_tag 'screenshots/vmware_and_virtualbox.png', class: 'img-responsive' %>
-
+
Modern, Automated
Packer is easy to use and automates the creation of any type
@@ -49,7 +49,7 @@
-
+
Works Great With
Out of the box Packer comes with support to build images for
@@ -60,8 +60,8 @@
-
- <%= image_tag 'screenshots/works_with.png' %>
+
+ <%= image_tag 'screenshots/works_with.png', class: 'img-responsive' %>
diff --git a/website/source/intro/getting-started/build-image.html.markdown b/website/source/intro/getting-started/build-image.html.markdown
index 158733bb9..70c13db6e 100644
--- a/website/source/intro/getting-started/build-image.html.markdown
+++ b/website/source/intro/getting-started/build-image.html.markdown
@@ -19,12 +19,9 @@ qualifies under the AWS [free-tier](http://aws.amazon.com/free/), meaning
it will be free. If you already have an AWS account, you may be charged some
amount of money, but it shouldn't be more than a few cents.
-
-
Note that if you're not using an account that qualifies under
-the AWS
free-tier, you may be
-charged to run these examples. The charge should only be a few cents, but
-we're not responsible if it ends up being more.
-
+-> **Note:** If you're not using an account that qualifies under the AWS
+free-tier, you may be charged to run these examples. The charge should only be
+a few cents, but we're not responsible if it ends up being more.
Packer can build images for [many platforms](/intro/platforms.html) other than
AWS, but AWS requires no additional software installed on your computer and
@@ -44,7 +41,7 @@ as machine generated templates to easily be made.
We'll start by creating the entire template, then we'll go over each section
briefly. Create a file `example.json` and fill it with the following contents:
-
+```javascript
{
"variables": {
"aws_access_key": "",
@@ -61,7 +58,7 @@ briefly. Create a file `example.json` and fill it with the following contents:
"ami_name": "packer-example {{timestamp}}"
}]
}
-
+```
When building, you'll pass in the `aws_access_key` and `aws_secret_key` as
a [user variable](/docs/templates/user-variables.html), keeping your secret
@@ -91,7 +88,7 @@ as well as the configuration values to verify they look valid. The output should
look similar to below, because the template should be valid. If there are
any errors, this command will tell you.
-```
+```text
$ packer validate example.json
Template validated successfully.
```
@@ -111,7 +108,7 @@ This is done by calling `packer build` with the template file. The output
should look similar to below. Note that this process typically takes a
few minutes.
-```
+```text
$ packer build \
-var 'aws_access_key=YOUR ACCESS KEY' \
-var 'aws_secret_key=YOUR SECRET KEY' \
@@ -149,12 +146,10 @@ we only have a single artifact: the AMI in us-east-1 that was created.
This AMI is ready to use. If you wanted you can go and launch this AMI
right now and it would work great.
-
-Note: Your AMI ID will surely be different than the
+-> **Note:** Your AMI ID will surely be different than the
one above. If you try to launch the one in the example output above, you
will get an error. If you want to try to launch your AMI, get the ID from
the Packer output.
-
## Managing the Image
diff --git a/website/source/intro/getting-started/parallel-builds.html.markdown b/website/source/intro/getting-started/parallel-builds.html.markdown
index e51311214..4145aa178 100644
--- a/website/source/intro/getting-started/parallel-builds.html.markdown
+++ b/website/source/intro/getting-started/parallel-builds.html.markdown
@@ -44,11 +44,8 @@ to sign up. Because the "droplets" (servers) are charged hourly, you
_will_ be charged $0.01 for every image you create with Packer. If
you're not okay with this, just follow along.
-
-Note! I want to repeat, in case you didn't see above:
-You will be charged $0.01 by DigitalOcean per image created with Packer
-because of the time the "droplet" is running.
-
+!> **Warning!** You _will_ be charged $0.01 by DigitalOcean per image
+created with Packer because of the time the "droplet" is running.
Once you sign up for an account, grab your client ID and API key from
the [DigitalOcean API access page](https://www.digitalocean.com/api_access).
@@ -60,24 +57,24 @@ We now have to modify the template to add DigitalOcean to it. Modify the
template we've been using and add the following JSON object to the `builders`
array.
-
+```javascript
{
"type": "digitalocean",
"api_key": "{{user `do_api_key`}}",
"client_id": "{{user `do_client_id`}}"
}
-
+```
You'll also need to modify the `variables` section of the template
to include the access keys for DigitalOcean.
-
+```javascript
"variables": {
- ...
"do_api_key": "",
"do_client_id": ""
+ // ...
}
-
+```
The entire template should now [look like this](https://gist.github.com/pearkes/cc5f8505eee5403a43a6).
@@ -88,12 +85,11 @@ you can do that as well.
Validate the template with `packer validate`. This is always a good practice.
-
-
If you're looking for more DigitalOcean configuration options,
-you can find them on the
DigitalOcean
-Builder page in the documentation. The documentation is more of a reference
-manual that contains a listing of all the available configuration options.
-
+-> **Note:** If you're looking for more **DigitalOcean configuration options**,
+you can find them on the
+[DigitalOcean Builder page](/docs/builders/digitalocean.html) in the
+documentation. The documentation is more of a reference manual that contains a
+listing of all the available configuration options.
## Build
@@ -102,7 +98,7 @@ all of it, but a portion of it is reproduced below. Note that the ordering
and wording of the lines may be slightly different, but the effect is the
same.
-```
+```text
$ packer build \
-var 'aws_access_key=YOUR ACCESS KEY' \
-var 'aws_secret_key=YOUR SECRET KEY' \
diff --git a/website/source/intro/getting-started/provision.html.markdown b/website/source/intro/getting-started/provision.html.markdown
index 6ae1dcca1..29698775d 100644
--- a/website/source/intro/getting-started/provision.html.markdown
+++ b/website/source/intro/getting-started/provision.html.markdown
@@ -35,10 +35,10 @@ shell provisioner that comes with Packer to install Redis. Modify the
explain the various parts of the new configuration following the code
block below.
-
+```javascript
{
- "variables": [...],
- "builders": [...],
+ "variables": ["..."],
+ "builders": ["..."],
"provisioners": [{
"type": "shell",
@@ -49,14 +49,12 @@ block below.
]
}]
}
-
+```
-
-Note: The sleep 30 in the example above is
+-> **Note:** The `sleep 30` in the example above is
very important. Because Packer is able to detect and SSH into the instance
as soon as SSH is available, Ubuntu actually doesn't get proper amounts
of time to initialize. The sleep makes sure that the OS properly initializes.
-
Hopefully it is obvious, but the `builders` section shouldn't actually
contain "...", it should be the contents setup in the previous page
diff --git a/website/source/intro/getting-started/setup.html.markdown b/website/source/intro/getting-started/setup.html.markdown
index 276f1d9c8..1c98a74a0 100644
--- a/website/source/intro/getting-started/setup.html.markdown
+++ b/website/source/intro/getting-started/setup.html.markdown
@@ -39,13 +39,13 @@ contains instructions for setting the PATH on Windows.
After installing Packer, verify the installation worked by opening
a new command prompt or console, and checking that `packer` is available:
-```
+```text
$ packer
usage: packer [--version] [--help]
[]
Available commands are:
build build image(s) from template
- fix fixes templates from old versions of packer
+ fix fixes templates from old versions of packer
inspect see components of a template
validate check that a template is valid
```
@@ -66,7 +66,7 @@ are alternatives available.
If you're using OS X and [Homebrew](http://brew.sh), you can install Packer by
adding the `binary` tap:
-```
+```text
$ brew tap homebrew/binary
$ brew install packer
```
diff --git a/website/source/intro/getting-started/vagrant.html.markdown b/website/source/intro/getting-started/vagrant.html.markdown
index dcca867aa..c34d35ef9 100644
--- a/website/source/intro/getting-started/vagrant.html.markdown
+++ b/website/source/intro/getting-started/vagrant.html.markdown
@@ -33,15 +33,13 @@ Post-processors are added in the `post-processors` section of a template, which
we haven't created yet. Modify your `example.json` template and add the section.
Your template should look like the following:
-
+```javascript
{
- "builders": [...],
-
- "provisioners": [...],
-
+ "builders": ["..."],
+ "provisioners": ["..."],
"post-processors": ["vagrant"]
}
-
+```
In this case, we're enabling a single post-processor named "vagrant". This
post-processor is built-in to Packer and will create Vagrant boxes. You
@@ -58,7 +56,7 @@ Since Packer can't currently make a Vagrant box for DigitalOcean anyways,
I recommend passing the `-only=amazon-ebs` flag to `packer build` so it only
builds the AMI. The command should look like the following:
-```
+```text
$ packer build -only=amazon-ebs example.json
```
diff --git a/website/source/intro/platforms.html.markdown b/website/source/intro/platforms.html.markdown
index ce39c5937..830093926 100644
--- a/website/source/intro/platforms.html.markdown
+++ b/website/source/intro/platforms.html.markdown
@@ -16,13 +16,11 @@ types that Packer supports creating.
If you were looking to see what platforms Packer is able to run on, see
the page on [installing Packer](/intro/getting-started/setup.html).
-
-
Note: We're always looking to officially support more
+-> **Note:** We're always looking to officially support more
target platforms. If you're interested in adding support for another
platform, please help by opening an issue or pull request within
-
GitHub so we can discuss
+[GitHub](https://github.com/mitchellh/packer) so we can discuss
how to make it happen.
-