From 0800ebfe7a17dfdbcc8f3b58686f5893ae83c580 Mon Sep 17 00:00:00 2001 From: Seth Vargo Date: Mon, 20 Oct 2014 13:55:16 -0400 Subject: [PATCH] Use formatting helpers and labeled code blocks --- .../docs/basics/terminology.html.markdown | 45 ++++------ .../docs/builders/amazon-chroot.html.markdown | 24 +++--- .../docs/builders/amazon-ebs.html.markdown | 32 ++++--- .../builders/amazon-instance.html.markdown | 29 +++---- .../source/docs/builders/amazon.html.markdown | 10 +-- .../docs/builders/digitalocean.html.markdown | 4 +- .../source/docs/builders/docker.html.markdown | 24 +++--- .../docs/builders/googlecompute.markdown | 10 +-- .../source/docs/builders/null.html.markdown | 4 +- .../docs/builders/openstack.html.markdown | 15 ++-- .../docs/builders/parallels-iso.html.markdown | 12 +-- .../docs/builders/parallels-pvm.html.markdown | 8 +- .../source/docs/builders/qemu.html.markdown | 34 ++++---- .../builders/virtualbox-iso.html.markdown | 12 +-- .../builders/virtualbox-ovf.html.markdown | 8 +- .../docs/builders/vmware-iso.html.markdown | 20 ++--- .../docs/builders/vmware-vmx.html.markdown | 4 +- .../docs/command-line/fix.html.markdown | 4 +- .../docs/command-line/inspect.html.markdown | 2 +- .../machine-readable.html.markdown | 4 +- .../docs/command-line/validate.html.markdown | 2 +- .../source/docs/extend/builder.html.markdown | 19 ++-- .../source/docs/extend/command.html.markdown | 13 ++- .../extend/developing-plugins.html.markdown | 21 ++--- .../source/docs/extend/plugins.html.markdown | 6 +- .../docs/extend/post-processor.html.markdown | 12 +-- .../docs/extend/provisioner.html.markdown | 17 ++-- .../source/docs/installation.html.markdown | 6 +- .../post-processors/compress.html.markdown | 4 +- .../docker-import.html.markdown | 4 +- .../post-processors/docker-push.html.markdown | 4 +- .../post-processors/docker-save.html.markdown | 4 +- .../post-processors/docker-tag.html.markdown | 4 +- .../vagrant-cloud.html.markdown | 5 +- .../post-processors/vagrant.html.markdown | 19 ++-- .../provisioners/ansible-local.html.markdown | 13 +-- .../provisioners/chef-client.html.markdown | 10 +-- .../docs/provisioners/chef-solo.html.markdown | 10 +-- .../docs/provisioners/file.html.markdown | 4 +- .../puppet-masterless.html.markdown | 15 ++-- .../provisioners/puppet-server.html.markdown | 12 ++- .../salt-masterless.html.markdown | 8 +- .../docs/provisioners/shell.html.markdown | 22 ++--- .../docs/templates/builders.html.markdown | 10 +-- .../configuration-templates.html.markdown | 86 ++++++++++--------- .../docs/templates/introduction.html.markdown | 4 +- .../templates/post-processors.html.markdown | 30 +++---- .../docs/templates/provisioners.html.markdown | 22 ++--- .../templates/user-variables.html.markdown | 28 +++--- .../templates/veewee-to-packer.html.markdown | 4 +- website/source/downloads.html.erb | 6 +- website/source/index.html.erb | 14 +-- .../getting-started/build-image.html.markdown | 21 ++--- .../parallel-builds.html.markdown | 30 +++---- .../getting-started/provision.html.markdown | 12 ++- .../intro/getting-started/setup.html.markdown | 6 +- .../getting-started/vagrant.html.markdown | 12 ++- website/source/intro/platforms.html.markdown | 6 +- 58 files changed, 374 insertions(+), 456 deletions(-) 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.

-
+[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: -
+```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. -
## 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: -
+```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. -
## 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: -
+```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. -

-
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. -
-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. -
## Basic Example The example below is fully functional and expects the configured manifest file to exist relative to your working directory: -
+```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. -
## Basic Example The example below is fully functional and expects a Puppet server to be accessible from your network.: -
+```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 WeekMonthDateHourMinuteSecondYearTimezone
Numeric-010203 (15)040506-0700
TextualMonday (Mon)January (Jan)-----MST
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Day of WeekMonthDateHourMinuteSecondYearTimezone
Numeric-010203 (15)040506-0700
TextualMonday (Mon)January (Jan)-----MST
+
_The values in parentheses are the abbreviated, or 24-hour clock values_ Here are some example formated time, using the above format options: - 
+```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. -
Packer supports creating images for the following platforms or targets. The format of the resulting image and any high-level information about the