Skip to content

P
packer
Commit 0800ebfe authored by Seth Vargo's avatar Seth Vargo
Browse files
Options

Use formatting helpers and labeled code blocks

parent c6926491
Hide whitespace changes
Inline Side-by-side
Showing with 376 additions and 458 deletions
website/source/docs/basics/terminology.html.markdown
View file @ 0800ebfe
......@@ -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.
<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."
<a class="term" id="term-builder"></a>
**Builders** are components of Packer that are able to create a 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."
- `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.
website/source/docs/builders/amazon-chroot.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/builders/amazon-ebs.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/builders/amazon-instance.html.markdown
View file @ 0800ebfe
......@@ -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}} \
......
website/source/docs/builders/amazon.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/builders/digitalocean.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/docker.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/googlecompute.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/null.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/openstack.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/parallels-iso.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/parallels-pvm.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/qemu.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/builders/virtualbox-iso.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/virtualbox-ovf.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/builders/vmware-iso.html.markdown
View file @ 0800ebfe
......@@ -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
```
......
website/source/docs/builders/vmware-vmx.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/command-line/fix.html.markdown
View file @ 0800ebfe
......@@ -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`.
website/source/docs/command-line/inspect.html.markdown
View file @ 0800ebfe
......@@ -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:
......
website/source/docs/command-line/machine-readable.html.markdown
View file @ 0800ebfe
......@@ -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...
```
......
website/source/docs/command-line/validate.html.markdown
View file @ 0800ebfe
......@@ -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.
......
website/source/docs/extend/builder.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/extend/command.html.markdown
View file @ 0800ebfe
......@@ -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.
......
website/source/docs/extend/developing-plugins.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/extend/plugins.html.markdown
View file @ 0800ebfe
......@@ -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:
......
website/source/docs/extend/post-processor.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/docs/extend/provisioner.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/installation.html.markdown
View file @ 0800ebfe
......@@ -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
```
website/source/docs/post-processors/compress.html.markdown
View file @ 0800ebfe
......@@ -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>
```
website/source/docs/post-processors/docker-import.html.markdown
View file @ 0800ebfe
......@@ -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`.
......
website/source/docs/post-processors/docker-push.html.markdown
View file @ 0800ebfe
......@@ -26,11 +26,9 @@ This post-processor has only optional configuration:
* `login_server` (string) - The server address to login to.
<div class="alert alert-info alert-block">
<strong>Note:</strong> 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).
</div>
## Example
......
website/source/docs/post-processors/docker-save.html.markdown
View file @ 0800ebfe
......@@ -27,9 +27,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": "docker-save",
"path": "foo.tar"
}
</pre>
```
website/source/docs/post-processors/docker-tag.html.markdown
View file @ 0800ebfe
......@@ -32,13 +32,13 @@ a repository is required.
An example is shown below, showing only the post-processor configuration:
<pre class="prettyprint">
```javascript
{
"type": "docker-tag",
"repository": "mitchellh/packer",
"tag": "0.7"
}
</pre>
```
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`.
......
website/source/docs/post-processors/vagrant-cloud.html.markdown
View file @ 0800ebfe
......@@ -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.
}]
]
}
```
website/source/docs/post-processors/vagrant.html.markdown
View file @ 0800ebfe
......@@ -33,11 +33,9 @@ providers.
* VirtualBox
* VMware
<div class="alert alert-block alert-info">
<strong>Support for additional providers</strong> 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.
</div>
## 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
}
}
}
```
......
website/source/docs/provisioners/ansible-local.html.markdown
View file @ 0800ebfe
......@@ -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.
<pre class="prettyprint">
```javascript
{
"type": "ansible-local",
"playbook_file": "local.yml"
"type": "ansible-local",
"playbook_file": "local.yml"
}
</pre>
```
## Configuration Reference
......@@ -48,7 +48,8 @@ Optional:
the `extra_arguments` option.
An example inventory file may look like:
<pre class="prettyprint">
```text
[chi-dbservers]
db-01 ansible_connection=local
db-02 ansible_connection=local
......@@ -66,7 +67,7 @@ Optional:
[appservers:children]
chi-appservers
</pre>
```
* `playbook_dir` (string) - a path to the complete ansible directory
structure on your local system to be copied to the remote machine
......
website/source/docs/provisioners/chef-client.html.markdown
View file @ 0800ebfe
......@@ -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.
<pre class="prettyprint">
```javascript
{
"type": "chef-client",
"server_url": "https://mychefserver.com/"
}
</pre>
```
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
```
......
website/source/docs/provisioners/chef-solo.html.markdown
View file @ 0800ebfe
......@@ -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.
<pre class="prettyprint">
```javascript
{
"type": "chef-solo",
"cookbook_paths": ["cookbooks"]
}
</pre>
```
## 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
```
......
website/source/docs/provisioners/file.html.markdown
View file @ 0800ebfe
......@@ -16,13 +16,13 @@ The file provisioner can upload both single files and complete directories.
## Basic Example
<pre class="prettyprint">
```javascript
{
"type": "file",
"source": "app.tar.gz",
"destination": "/tmp/app.tar.gz"
}
</pre>
```
## Configuration Reference
......
website/source/docs/provisioners/puppet-masterless.html.markdown
View file @ 0800ebfe
......@@ -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.
<div class="alert alert-info alert-block">
<strong>Note that Puppet will <em>not</em> be installed automatically
by this provisioner.</strong> 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
<a href="/docs/provisioners/shell.html">shell provisioner</a> before the
[shell provisioner[(/docs/provisioners/shell.html) before the
Puppet provisioner to do this.
</div>
## Basic Example
The example below is fully functional and expects the configured manifest
file to exist relative to your working directory:
<pre class="prettyprint">
```javascript
{
"type": "puppet-masterless",
"manifest_file": "site.pp"
}
</pre>
```
## 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.
website/source/docs/provisioners/puppet-server.html.markdown
View file @ 0800ebfe
......@@ -10,20 +10,18 @@ Type: `puppet-server`
The `puppet-server` provisioner provisions Packer machines with Puppet
by connecting to a Puppet master.
<div class="alert alert-info alert-block">
<strong>Note that Puppet will <em>not</em> be installed automatically
by this provisioner.</strong> 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
<a href="/docs/provisioners/shell.html">shell provisioner</a> before the
[shell provisioner](/docs/provisioners/shell.html) before the
Puppet provisioner to do this.
</div>
## Basic Example
The example below is fully functional and expects a Puppet server to be accessible
from your network.:
<pre class="prettyprint">
```javascript
{
"type": "puppet-server",
"options": "--test --pluginsync",
......@@ -31,7 +29,7 @@ from your network.:
"server_role": "webserver"
}
}
</pre>
```
## Configuration Reference
......
website/source/docs/provisioners/salt-masterless.html.markdown
View file @ 0800ebfe
......@@ -14,12 +14,12 @@ The `salt-masterless` provisioner provisions machines built by Packer using
The example below is fully functional.
<pre class="prettyprint">
```javascript
{
"type": "salt-masterless",
"local_state_tree": "/Users/me/salt"
"type": "salt-masterless",
"local_state_tree": "/Users/me/salt"
}
</pre>
```
## Configuration Reference
......
website/source/docs/provisioners/shell.html.markdown
View file @ 0800ebfe
......@@ -15,12 +15,12 @@ on a machine.
The example below is fully functional.
<pre class="prettyprint">
```javascript
{
"type": "shell",
"inline": ["echo foo"]
}
</pre>
```
## 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.
<pre class="prettyprint">
{
"type": "shell",
"inline": [ "sleep 10" ]
}
</pre>
```javascript
{
"type": "shell",
"inline": [ "sleep 10" ]
}
```
website/source/docs/templates/builders.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre class="prettyprint">
```javascript
{
"builders": [
... one or more builder definitions here ...
// ... one or more builder definitions here
]
}
</pre>
```
## 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:
<pre class="prettyprint">
```javascript
{
"type": "amazon-ebs",
"access_key": "...",
"secret_key": "..."
}
</pre>
```
## Named Builds
......
website/source/docs/templates/configuration-templates.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre>
```liquid
.encoding = "UTF-8"
displayName = "{{ .Name }}"
guestOS = "{{ .GuestOS }}"
</pre>
```
In this case, the "Name" and "GuestOS" variables will be replaced, potentially
resulting in a VMX that looks like this:
<pre>
```liquid
.encoding = "UTF-8"
displayName = "packer"
guestOS = "otherlinux"
</pre>
```
## 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:
<table border="1" cellpadding="5" width="100%">
<tr bgcolor="lightgray">
<td></td>
<td align="center"><strong>Day of Week</strong></td>
<td align="center"><strong>Month</strong></td>
<td align="center"><strong>Date</strong></td>
<td align="center"><strong>Hour</strong></td>
<td align="center"><strong>Minute</strong></td>
<td align="center"><strong>Second</strong></td>
<td align="center"><strong>Year</strong></td>
<td align="center"><strong>Timezone</strong></td>
</tr>
<tr>
<td><strong>Numeric</strong></td>
<td align="center">-</td>
<td align="center">01</td>
<td align="center">02</td>
<td align="center">03 (15)</td>
<td align="center">04</td>
<td align="center">05</td>
<td align="center">06</td>
<td align="center">-0700</td>
</tr>
<tr>
<td><strong>Textual</strong></td>
<td align="center">Monday (Mon)</td>
<td align="center">January (Jan)</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">MST</td>
</tr>
</table>
<div class="table-responsive">
<table class="table table-bordered table-condensed">
<thead>
<tr>
<th></th>
<th align="center">Day of Week</th>
<th align="center">Month</th>
<th align="center">Date</th>
<th align="center">Hour</th>
<th align="center">Minute</th>
<th align="center">Second</th>
<th align="center">Year</th>
<th align="center">Timezone</th>
</tr>
</thead>
<tr>
<th>Numeric</th>
<td align="center">-</td>
<td align="center">01</td>
<td align="center">02</td>
<td align="center">03 (15)</td>
<td align="center">04</td>
<td align="center">05</td>
<td align="center">06</td>
<td align="center">-0700</td>
</tr>
<tr>
<th>Textual</th>
<td align="center">Monday (Mon)</td>
<td align="center">January (Jan)</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">-</td>
<td align="center">MST</td>
</tr>
</table>
</div>
_The values in parentheses are the abbreviated, or 24-hour clock values_
Here are some example formated time, using the above format options:
<pre>
```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
</pre>
```
## Amazon Specific Functions
......
website/source/docs/templates/introduction.html.markdown
View file @ 0800ebfe
......@@ -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`.
<pre class="prettyprint">
```javascript
{
"builders": [
{
......@@ -84,4 +84,4 @@ missing valid AWS access keys. Otherwise, it would work properly with
}
]
}
</pre>
```
website/source/docs/templates/post-processors.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre class="prettyprint">
```javascript
{
"post-processors": [
... one or more post-processor definitions here ...
// ... one or more post-processor definitions here
]
}
</pre>
```
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.
<pre class="prettyprint">
```javascript
{
"post-processors": ["compress"]
}
</pre>
```
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.
<pre class="prettyprint">
```javascript
{
"post-processors": [
{
......@@ -67,7 +67,7 @@ is needed beyond simply the type for the post-processor. An example is shown bel
}
]
}
</pre>
```
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.
<pre class="prettyprint">
```javascript
{
"post-processors": [
[
......@@ -86,7 +86,7 @@ compressed then uploaded, but the compressed result is not kept.
]
]
}
</pre>
```
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:
<pre class="prettyprint">
```javascript
{
"post-processors": [
{
......@@ -111,21 +111,19 @@ You can tell Packer to keep these artifacts by setting the
}
]
}
</pre>
```
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.
<div class="alert alert-info alert-block">
<strong>Note:</strong> 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.
</div>
## 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.
<pre class="prettyprint">
```javascript
{
"type": "vagrant",
"only": ["virtualbox-iso"]
}
</pre>
```
The values within `only` or `except` are _build names_, not builder
types. If you recall, build names by default are just their builder type,
......
website/source/docs/templates/provisioners.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre class="prettyprint">
```javascript
{
"provisioners": [
... one or more provisioner definitions here ...
// ... one or more provisioner definitions here
]
}
</pre>
```
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:
<pre class="prettyprint">
```javascript
{
"type": "shell",
"script": "script.sh"
}
</pre>
```
## 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:
<pre class="prettyprint">
```javascript
{
"type": "shell",
"script": "script.sh",
"only": ["virtualbox-iso"]
}
</pre>
```
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:
<pre class="prettyprint">
```javascript
{
"type": "shell",
"script": "script.sh",
......@@ -106,7 +106,7 @@ This example is shown below:
}
}
}
</pre>
```
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:
<pre class="prettyprint">
```javascript
{
"type": "shell",
"script": "script.sh",
"pause_before": "10s"
}
</pre>
```
For the above provisioner, Packer will wait 10 seconds before uploading
and executing the shell script.
website/source/docs/templates/user-variables.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre class="prettyprint">
```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`}}",
...
// ...
}]
}
</pre>
```
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:
<pre class="prettyprint">
```javascript
{
"variables": {
"my_secret": "{{env `MY_SECRET`}}",
},
...
// ...
}
</pre>
```
This will default "my\_secret" to be the value of the "MY\_SECRET"
environmental variable (or the empty string if it does not exist).
<div class="alert alert-info">
<strong>Why can't I use environmental variables elsewhere?</strong>
-> **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 <em>anywhere</em> 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 <code>packer inspect</code>.
</div>
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:
<pre class="prettyprint">
```javascript
{
"aws_access_key": "foo",
"aws_secret_key": "bar"
}
</pre>
```
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
```
......
website/source/docs/templates/veewee-to-packer.html.markdown
View file @ 0800ebfe
......@@ -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
......
website/source/downloads.html.erb
View file @ 0800ebfe
......@@ -12,7 +12,7 @@ page_title: "Downloads"
<section class="downloads">
<div class="container">
<div class="description row">
<div class="span8 offset2">
<div class="col-md-8 col-md-offset-2">
<p>
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"
</div>
<% product_versions.each do |os, versions| %>
<div class="row">
<div class="span8 offset2 download">
<div class="col-md-8 col-md-offset-2 download">
<div class="icon pull-left"><%= system_icon(os) %></div>
<div class="details">
<h2 class="os-name"><%= os %></h2>
......@@ -39,7 +39,7 @@ page_title: "Downloads"
<% end %>
<div class="row">
<div class="span8 offset2 poweredby">
<div class="col-md-8 col-md-offset-2 poweredby">
<a href='http://www.bintray.com'>
<img src='http://www.bintray.com/docs/images/poweredByBintray_ColorTransparent.png'>
</a>
......
website/source/index.html.erb
View file @ 0800ebfe
......@@ -3,7 +3,7 @@
<header class="dark-background">
<div class="container hero">
<div class="row">
<div class="span6 offset1">
<div class="col-md-4 col-md-offset-1">
<h2>
<span class="text-green">Packer</span> is a tool for creating identical machine images for multiple platforms from a single source configuration.
</h2>
......@@ -26,11 +26,11 @@
<section class="marketting padded-lg">
<div class="container">
<div class="row">
<div class="span6">
<%= image_tag 'screenshots/vmware_and_virtualbox.png' %>
<div class="col-md-6">
<%= image_tag 'screenshots/vmware_and_virtualbox.png', class: 'img-responsive' %>
</div>
<div class="span6">
<div class="col-md-6">
<h2 class="text-green text-center">Modern, Automated</h2>
<p>
Packer is easy to use and automates the creation of any type
......@@ -49,7 +49,7 @@
<section class="marketting padded-lg">
<div class="container">
<div class="row">
<div class="span6">
<div class="col-md-6">
<h2 class="text-green text-center">Works Great With</h2>
<p>
Out of the box Packer comes with support to build images for
......@@ -60,8 +60,8 @@
</p>
</div>
<div class="span6">
<%= image_tag 'screenshots/works_with.png' %>
<div class="col-md-6">
<%= image_tag 'screenshots/works_with.png', class: 'img-responsive' %>
</div>
</div>
</div>
......
website/source/intro/getting-started/build-image.html.markdown
View file @ 0800ebfe
......@@ -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.
<div class="alert alert-block alert-warn">
<strong>Note</strong> that if you're not using an account that qualifies under
the AWS <a href="http://aws.amazon.com/free/">free-tier</a>, 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.
</div>
-> **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:
<pre class="prettyprint">
```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}}"
}]
}
</pre>
```
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.
<div class="alert alert-block alert-info">
<strong>Note:</strong> 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.
</div>
## Managing the Image
......
website/source/intro/getting-started/parallel-builds.html.markdown
View file @ 0800ebfe
......@@ -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.
<div class="alert alert-block alert-warn">
<strong>Note!</strong> I want to repeat, in case you didn't see above:
You <em>will</em> be charged $0.01 by DigitalOcean per image created with Packer
because of the time the "droplet" is running.
</div>
!> **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.
<pre class="prettyprint">
```javascript
{
"type": "digitalocean",
"api_key": "{{user `do_api_key`}}",
"client_id": "{{user `do_client_id`}}"
}
</pre>
```
You'll also need to modify the `variables` section of the template
to include the access keys for DigitalOcean.
<pre class="prettyprint">
```javascript
"variables": {
...
"do_api_key": "",
"do_client_id": ""
// ...
}
</pre>
```
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.
<div class="alert alert-block alert-info">
<strong>If you're looking for more DigitalOcean configuration options</strong>,
you can find them on the <a href="/docs/builders/digitalocean.html">DigitalOcean
Builder page</a> in the documentation. The documentation is more of a reference
manual that contains a listing of all the available configuration options.
</div>
-> **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' \
......
website/source/intro/getting-started/provision.html.markdown
View file @ 0800ebfe
......@@ -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.
<pre class="prettyprint">
```javascript
{
"variables": [...],
"builders": [...],
"variables": ["..."],
"builders": ["..."],
"provisioners": [{
"type": "shell",
......@@ -49,14 +49,12 @@ block below.
]
}]
}
</pre>
```
<div class="alert alert-block alert-info">
<strong>Note:</strong> The <code>sleep 30</code> 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.
</div>
Hopefully it is obvious, but the `builders` section shouldn't actually
contain "...", it should be the contents setup in the previous page
......
website/source/intro/getting-started/setup.html.markdown
View file @ 0800ebfe
......@@ -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] <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
```
......@@ -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
```
website/source/intro/getting-started/vagrant.html.markdown
View file @ 0800ebfe
......@@ -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:
<pre class="prettyprint">
```javascript
{
"builders": [...],
"provisioners": [...],
"builders": ["..."],
"provisioners": ["..."],
"post-processors": ["vagrant"]
}
</pre>
```
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
```
......
website/source/intro/platforms.html.markdown
View file @ 0800ebfe
......@@ -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).
<div class="alert alert-info alert-block">
<strong>Note:</strong> 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
<a href="https://github.com/mitchellh/packer">GitHub</a> so we can discuss
[GitHub](https://github.com/mitchellh/packer) so we can discuss
how to make it happen.
</div>
Packer supports creating images for the following platforms or targets.
The format of the resulting image and any high-level information about the
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7