Use formatting helpers and labeled code blocks

2026-10-13 01:32:02 -04:00 · 2014-10-22 17:41:53 -04:00
parent c6926491b4
commit 0800ebfe7a
58 changed files with 374 additions and 456 deletions
@@ -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.

-<a class="term" id="term-artifact"></a>
-**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.

-<a class="term" id="term-build"></a>
-**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."

-<a class="term" id="term-builder"></a>
-**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.

-<a class="term" id="term-command"></a>
-**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.

-<a class="term" id="term-post-processor"></a>
-**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.

-<a class="term" id="term-provisioner"></a>
-**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.

-<a class="term" id="term-template"></a>
-**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.
@@ -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.

-<div class="alert alert-block alert-warn">
-<p><strong>This is an advanced builder.</strong> If you're just getting
+~> **This is an advanced builder** If you're just getting
 started with Packer, we recommend starting with the
-<a href="/docs/builders/amazon-ebs.html">amazon-ebs builder</a>, which is
-much easier to use.</p>
-</div>
+[amazon-ebs builder](/docs/builders/amazon-ebs.html), which is
+much easier to use.

 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.
@@ -136,7 +134,7 @@ each category, the available configuration keys are alphabetized.

 Here is a basic example. It is completely valid except for the access keys:

-<pre class="prettyprint">
+```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}}"
 }
-</pre>
+```

 ## 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:

-<pre class="prettyprint">
+```javascript
 {
  "chroot_mounts": [
    ["proc", "proc", "/proc"],
    ["bind", "/dev", "/dev"]
  ]
 }
-</pre>
+```

 `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:

-<pre class="prettyprint">
+```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"
  ]
 }
-</pre>
+```
@@ -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:

-<pre class="prettyprint">
+```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}}"
 }
-</pre>
+```

-<div class="alert alert-block alert-info">
-<strong>Note:</strong> 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.
-</div>

 ## 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.

-<pre class="prettyprint">
+```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"
+    }
  ]
 }
-</pre>
+```

 ## Tag Example

 Here is an example using the optional AMI tags. This will add the tags
 "OS_Version" and "Release" to the finished AMI.

-<pre class="prettyprint">
+```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"
  }
 }
-</pre>
+```
@@ -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.

-<div class="alert alert-block alert-info">
-<strong>Note:</strong> This builder requires that the
-<a href="http://aws.amazon.com/developertools/368">Amazon EC2 AMI Tools</a>
+-> **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.
-</div>

 ## Configuration Reference

@@ -212,7 +210,7 @@ each category, the available configuration keys are alphabetized.

 Here is a basic example. It is completely valid except for the access keys:

-<pre class="prettyprint">
+```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}}"
 }
-</pre>
+```

-<div class="alert alert-block alert-info">
-<strong>Note:</strong> 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.
-</div>

 ## 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.

-<div class="alert alert-block">
-  <strong>Warning!</strong> 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
-<code>--no-filter</code> option of ec2-bundle-vol).
-</div>
+~> **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}} \
@@ -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.

-<div class="alert alert-block alert-info">
-<strong>Don't know which builder to use?</strong> If in doubt, use the
-<a href="/docs/builders/amazon-ebs.html">amazon-ebs builder</a>. 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.
-</div>

 ## Using an IAM Instance Profile

@@ -38,7 +36,7 @@ Packer will use credentials provided by the instance's IAM profile, if it has on

 The following policy document provides the minimal set permissions necessary for Packer to work:

-<pre class="prettyprint">
+```javascript
 {
  "Statement": [{
      "Effect": "Allow",
@@ -69,4 +67,4 @@ The following policy document provides the minimal set permissions necessary for
      "Resource" : "*"
  }]
 }
-</pre>
+```
@@ -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:

-<pre class="prettyprint">
+```javascript
 {
  "type": "digitalocean",
  "client_id": "YOUR CLIENT ID",
  "api_key": "YOUR API KEY"
 }
-</pre>
+```

 ## Finding Image, Region, and Size IDs

@@ -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.

-<pre class="prettyprint">
+```javascript
 {
  "type": "docker",
  "image": "ubuntu",
  "export_path": "image.tar"
 }
-</pre>
+```

 ## 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.

-<pre class="prettyprint">
+```javascript
 {
  "type": "docker",
  "image": "ubuntu",
  "commit": true
 }
-</pre>
+```


 ## 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:

-<pre class="prettyprint">
+```javascript
 {
-    "post-processors": [
+  "post-processors": [
 		[
 			{
 				"type": "docker-import",
@@ -126,12 +126,14 @@ the created image:
 		]
 	]
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
+```javascript
 {
-    "post-processors": [
+  "post-processors": [
 		[
 			{
 				"type": "docker-tag",
@@ -155,7 +157,7 @@ shown below which tags and pushes the image:
 		]
 	]
 }
-</pre>
+```

 ## Dockerfiles

@@ -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.

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 ## 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)
-<!---
-@todo document me
-->

 * `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)
-<!---
-@todo document me
-->

 ## Gotchas

@@ -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.

-<pre class="prettyprint">
+```javascript
 {
  "type":     "null",
  "host":     "127.0.0.1",
  "ssh_username": "foo",
  "ssh_password": "bar"
 }
-</pre>
+```

 ## Configuration Reference

@@ -69,9 +69,6 @@ each category, the available configuration keys are alphabetized.
  to this instance.

 * `openstack_provider` (string)
-<!---
-@todo document me
-->

 * `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)
-<!---
-@todo document me
-->
+
 * `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.

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 ## Basic Example: Private OpenStack cloud

 This example builds an Ubuntu 14.04 image on a private OpenStack cloud,
 powered by Metacloud.

-<pre class="prettyprint">
+```javascript
 {
  "type": "openstack",
  "ssh_username": "root",
@@ -149,7 +144,7 @@ powered by Metacloud.
  "source_image": "91d9c168-d1e5-49ca-a775-3bfdbb6c97f1",
  "flavor": "2"
 }
-</pre>
+```

 In this case, the connection information for connecting to OpenStack
 doesn't appear in the template. That is because I source a standard
@@ -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:

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
+```javascript
 [
  "&lt;esc&gt;&lt;esc&gt;&lt;enter&gt;&lt;wait&gt;",
  "/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 -- &lt;enter&gt;"
 ]
-</pre>
+```

 ## 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:

-<pre class="prettyprint">
+```javascript
 {
  "prlctl": [
    ["set", "{{.Name}}", "--memsize", "1024"],
    ["set", "{{.Name}}", "--cpus", "2"]
  ]
 }
-</pre>
+```

 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
@@ -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.

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
+```javascript
 {
  "prlctl": [
    ["set", "{{.Name}}", "--memsize", "1024"],
    ["set", "{{.Name}}", "--cpus", "2"]
  ]
 }
-</pre>
+```

 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
@@ -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.

-<pre class="prettyprint">
+```javascript
 {
  "builders":
  [
@@ -58,7 +58,7 @@ paths to files, URLS for ISOs and checksums.
    }
  ]
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
-  . . .
+```javascript
+  // ...
  "qemuargs": [
    [ "-m", "1024m" ],
    [ "--no-acpi", "" ],
@@ -194,14 +194,14 @@ each category, the available options are alphabetized and described.
    ],
    [ "-device", "virtio-net,netdev=mynet0" ]
  ]
-  . . .
-</pre>
+  // ...
+```

  would produce the following (not including other defaults supplied by the builder and not otherwise conflicting with the qemuargs):

-<pre class="prettyprint">
-    qemu-system-x86 -m 1024m --no-acpi -netdev user,id=mynet0,hostfwd=hostip:hostport-guestip:guestport -device virtio-net,netdev=mynet0"
-</pre>
+```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:

-<pre class="prettyprint">
+```javascript
 "boot_command":
 [
  "<tab><wait>",
  " ks=http://10.0.2.2:{{ .HTTPPort }}/centos6-ks.cfg<enter>"
 ]
-</pre>
+```
@@ -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:

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
+```javascript
 [
  "&lt;esc&gt;&lt;esc&gt;&lt;enter&gt;&lt;wait&gt;",
  "/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 -- &lt;enter&gt;"
 ]
-</pre>
+```

 ## 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:

-<pre class="prettyprint">
+```javascript
 {
  "vboxmanage": [
    ["modifyvm", "{{.Name}}", "--memory", "1024"],
    ["modifyvm", "{{.Name}}", "--cpus", "2"]
  ]
 }
-</pre>
+```

 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
@@ -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.

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 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:

-<pre class="prettyprint">
+```javascript
 {
  "vboxmanage": [
    ["modifyvm", "{{.Name}}", "--memory", "1024"],
    ["modifyvm", "{{.Name}}", "--cpus", "2"]
  ]
 }
-</pre>
+```

 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
@@ -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:

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 ## 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:

-<pre class="prettyprint">
+```javascript
 [
  "&lt;esc&gt;&lt;esc&gt;&lt;enter&gt;&lt;wait&gt;",
  "/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 -- &lt;enter&gt;"
 ]
-</pre>
+```

 ## 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.

-<div class="alert alert-block alert-warn">
-<p>
-<strong>This is an advanced feature.</strong> 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.
-</p>
-</div>

 Within the template, a handful of variables are available so that your
 template can continue working with the rest of the Packer machinery. Using
@@ -343,13 +339,11 @@ In addition to using the desktop products of VMware locally to build
 virtual machines, Packer can use a remote VMware Hypervisor to build
 the virtual machine.

-<div class="alert alert-block alert-info">
-Note: Packer supports ESXi 5.1 and above.
-</div>
+-> **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
 ```

@@ -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:

-<pre class="prettyprint">
+```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"
 }
-</pre>
+```

 ## Configuration Reference

@@ -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.

-<div class="alert alert-block alert-info">
-<strong>Even when Packer fix doesn't do anything</strong> 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.
-</div>

 The full list of fixes that the fix command performs is visible in the
 help output, which can be seen via `packer fix -h`.
@@ -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:

@@ -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...
 ```

@@ -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.

@@ -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).

-<div class="alert alert-block">
-  <strong>Warning!</strong> This is an advanced topic. If you're new to Packer,
-  we recommend getting a bit more comfortable before you dive into writing
-  plugins.
-</div>
+~> **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.

-<pre class="prettyprint">
+```go
 type Builder interface {
 	Prepare(...interface{}) error
 	Run(ui Ui, hook Hook, cache Cache) (Artifact, error)
 	Cancel()
 }
-</pre>
+```

 ### 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:

-<pre class="prettyprint">
+```go
 hook.Run(packer.HookProvision, ui, comm, nil)
-</pre>
+```

 At this point, Packer will run the provisioners and no additional work
 is necessary.

-<div class="alert alert-info alert-block">
-<strong>Note:</strong> 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.
-</div>

 ## Caching Files

@@ -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.

-<div class="alert alert-block">
-  <strong>Warning!</strong> This is an advanced topic. If you're new to Packer,
-  we recommend getting a bit more comfortable before you dive into writing
-  plugins.
-</div>
+~> **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.

-<pre class="prettyprint">
+```go
 type Command interface {
 	Help() string
 	Run(env Environment, args []string) int
 	Synopsis() string
 }
-</pre>
+```

 ### 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.
@@ -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.

-<div class="alert alert-block">
-  <strong>Warning!</strong> This is an advanced topic. If you're new to Packer,
-  we recommend getting a bit more comfortable before you dive into writing
-  plugins.
-</div>
+~> **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:

-<pre class="prettyprint">
+```go
 import (
  "github.com/mitchellh/packer/plugin"
 )
@@ -79,7 +76,7 @@ type Builder struct{}
 func main() {
 	plugin.ServeBuilder(new(Builder))
 }
-</pre>
+```

 **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.

-<div class="alert alert-warn alert-block">
-<strong>Lock your dependencies.</strong> 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.
-</div>

 ## 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:

-<pre class="prettyprint">
+```javascript
 {
  "builders": {
    "custom-cloud": "/an/absolute/path/to/packer-builder-custom-cloud"
  }
 }
-</pre>
+```

 This would configure Packer to have the "custom-cloud" plugin, and execute
 the binary that I am building during development. This is extremely useful
@@ -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:

@@ -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.

-<div class="alert alert-block">
-  <strong>Warning!</strong> This is an advanced topic. If you're new to Packer,
-  we recommend getting a bit more comfortable before you dive into writing
-  plugins.
-</div>
+~> **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.

-
-<pre class="prettyprint">
+```go
 type PostProcessor interface {
 	Configure(interface{}) error
 	PostProcess(Ui, Artifact) (a Artifact, keep bool, err error)
 }
-</pre>
+```

 ### The "Configure" Method

@@ -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.

-<div class="alert alert-block">
-  <strong>Warning!</strong> This is an advanced topic. If you're new to Packer,
-  we recommend getting a bit more comfortable before you dive into writing
-  plugins.
-</div>
-
+~> **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.

-
-<pre class="prettyprint">
+```go
 type Provisioner interface {
 	Prepare(...interface{}) error
 	Provision(Ui, Communicator) error
 }
-</pre>
+```

 ### 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:

-<pre class="prettyprint">
+```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())
-</pre>
+```
@@ -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] <command> [<args>]

 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
 ```
@@ -21,9 +21,9 @@ The configuration for this post-processor is extremely simple.

 An example is shown below, showing only the post-processor configuration:

-<pre class="prettyprint">
+```javascript
 {
  "type": "compress",
  "output": "foo.tar.gz"
 }
-</pre>
+```
@@ -28,13 +28,13 @@ a repository is required.

 An example is shown below, showing only the post-processor configuration:

-<pre class="prettyprint">
+```javascript
 {
  "type": "docker-import",
  "repository": "mitchellh/packer",
  "tag": "0.7"
 }
-</pre>
+```

 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`.
--- a/Show More
+++ b/Show More