Commit d57c0516 authored by Chris Bednarski's avatar Chris Bednarski

Reformat everything

parent 13ac8896
---
layout: "community"
page_title: "Community"
description: |-
Packer is a new project with a growing community. Despite this, there are dedicated users willing to help through various mediums.
---
description: |
Packer is a new project with a growing community. Despite this, there are
dedicated users willing to help through various mediums.
layout: community
page_title: Community
...
# Community
Packer is a new project with a growing community. Despite this, there are
dedicated users willing to help through various mediums.
**IRC:** `#packer-tool` on Freenode.
**IRC:** `#packer-tool` on Freenode.
**Mailing List:** [Packer Google Group](http://groups.google.com/group/packer-tool)
**Mailing List:** [Packer Google
Group](http://groups.google.com/group/packer-tool)
**Bug Tracker:** [Issue tracker on GitHub](https://github.com/mitchellh/packer/issues).
Please only use this for reporting bugs. Do not ask for general help here. Use IRC
or the mailing list for that.
**Bug Tracker:** [Issue tracker on
GitHub](https://github.com/mitchellh/packer/issues). Please only use this for
reporting bugs. Do not ask for general help here. Use IRC or the mailing list
for that.
## People
......@@ -25,62 +28,70 @@ to Packer in some core way. Over time, faces may appear and disappear from this
list as contributors come and go.
<div class="people">
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/54079122b67de9677c1f93933ce8b63a.png?s=125">
<div class="bio">
<h3>Mitchell Hashimoto (<a href="https://github.com/mitchellh">@mitchellh</a>)</h3>
<p>
Mitchell Hashimoto is the creator of Packer. He developed the
core of Packer as well as the Amazon, VirtualBox, and VMware
builders. In addition to Packer, Mitchell is the creator of
<a href="http://www.vagrantup.com">Vagrant</a>. He is self
described as "automation obsessed."
</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/2acc31dd6370a54b18f6755cd0710ce6.png?s=125">
<div class="bio">
<h3>Jack Pearkes (<a href="https://github.com/pearkes">@pearkes</a>)</h3>
<p>
<a href="http://jack.ly/">Jack Pearkes</a> created and maintains the DigitalOcean builder
for Packer. Outside of Packer, Jack is an avid open source
contributor and software consultant.</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/2f7fc9cb7558e3ea48f5a86fa90a78da.png?s=125">
<div class="bio">
<h3>Mark Peek (<a href="https://github.com/markpeek">@markpeek</a>)</h3>
<p>
In addition to Packer, Mark Peek helps maintain
various open source projects such as
<a href="https://github.com/cloudtools">cloudtools</a> and
<a href="https://github.com/ironport">IronPort Python libraries</a>.
Mark is also a <a href="https://FreeBSD.org">FreeBSD committer</a>.</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/1fca64df3d7db1e2f258a8956d2b0aff.png?s=125">
<div class="bio">
<h3>Ross Smith II (<a href="https://github.com/rasa" target="_blank">@rasa</a>)</h3>
<p>
<a href="http://smithii.com/" target="_blank">Ross Smith</a> maintains our VMware builder on Windows, and provides other valuable assistance.
Ross is an open source enthusiast, published author, and freelance consultant.</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/c9f6bf7b5b865012be5eded656ebed7d.png?s=125">
<div class="bio">
<h3>Rickard von Essen<br/>(<a href="https://github.com/rickard-von-essen" target="_blank">@rickard-von-essen</a>)</h3>
<p>
Rickard von Essen maintains our Parallels Desktop builder. Rickard is an polyglot programmer and consults on Continuous Delivery.</p>
</div>
</div>
<div class="clearfix"></div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/54079122b67de9677c1f93933ce8b63a.png?s=125">
<div class="bio">
<h3>Mitchell Hashimoto (<a href="https://github.com/mitchellh">@mitchellh</a>)</h3>
<p>
Mitchell Hashimoto is the creator of Packer. He developed the
core of Packer as well as the Amazon, VirtualBox, and VMware
builders. In addition to Packer, Mitchell is the creator of
<a href="http://www.vagrantup.com">Vagrant</a>. He is self
described as "automation obsessed."
</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/2acc31dd6370a54b18f6755cd0710ce6.png?s=125">
<div class="bio">
<h3>Jack Pearkes (<a href="https://github.com/pearkes">@pearkes</a>)</h3>
<p>
<a href="http://jack.ly/">Jack Pearkes</a> created and maintains the DigitalOcean builder
for Packer. Outside of Packer, Jack is an avid open source
contributor and software consultant.</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/2f7fc9cb7558e3ea48f5a86fa90a78da.png?s=125">
<div class="bio">
<h3>Mark Peek (<a href="https://github.com/markpeek">@markpeek</a>)</h3>
<p>
In addition to Packer, Mark Peek helps maintain
various open source projects such as
<a href="https://github.com/cloudtools">cloudtools</a> and
<a href="https://github.com/ironport">IronPort Python libraries</a>.
Mark is also a <a href="https://FreeBSD.org">FreeBSD committer</a>.</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/1fca64df3d7db1e2f258a8956d2b0aff.png?s=125">
<div class="bio">
<h3>Ross Smith II (<a href="https://github.com/rasa" target="_blank">@rasa</a>)</h3>
<p>
<a href="http://smithii.com/" target="_blank">Ross Smith</a> maintains our
VMware builder on Windows, and provides other valuable assistance. Ross is an
open source enthusiast, published author, and freelance consultant.
</p>
</div>
</div>
<div class="person">
<img class="pull-left" src="http://www.gravatar.com/avatar/c9f6bf7b5b865012be5eded656ebed7d.png?s=125">
<div class="bio">
<h3>Rickard von Essen<br/>(<a href="https://github.com/rickard-von-essen" target="_blank">@rickard-von-essen</a>)</h3>
<p>
Rickard von Essen maintains our Parallels Desktop builder. Rickard is an
polyglot programmer and consults on Continuous Delivery.
</p>
</div>
</div>
<div class="clearfix"></div>
</div>
---
layout: "docs"
page_title: "Packer Terminology"
description: |-
There are a handful of terms used throughout the Packer documentation where the meaning may not be immediately obvious if you haven't used Packer before. 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.
---
description: |
There are a handful of terms used throughout the Packer documentation where the
meaning may not be immediately obvious if you haven't used Packer before.
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.
layout: docs
page_title: Packer Terminology
...
# Packer Terminology
There are a handful of terms used throughout the Packer documentation where
the meaning may not be immediately obvious if you haven't used Packer before.
There are a handful of terms used throughout the Packer documentation where the
meaning may not be immediately obvious if you haven't used Packer before.
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, 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 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
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
Packer in the form of plugins.
- `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
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
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.
required to understand and use Packer. The terminology is in alphabetical order
for easy referencing.
- `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 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 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 Packer in
the form of plugins.
- `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 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 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.
---
layout: "docs"
page_title: "Amazon AMI Builder"
description: |-
Packer is able to create Amazon AMIs. To achieve this, Packer comes with multiple builders depending on the strategy you want to use to build the AMI.
---
description: |
Packer is able to create Amazon AMIs. To achieve this, Packer comes with
multiple builders depending on the strategy you want to use to build the AMI.
layout: docs
page_title: Amazon AMI Builder
...
# Amazon AMI Builder
Packer is able to create Amazon AMIs. To achieve this, Packer comes with
multiple builders depending on the strategy you want to use to build the
AMI. Packer supports the following builders at the moment:
multiple builders depending on the strategy you want to use to build the AMI.
Packer supports the following builders at the moment:
* [amazon-ebs](/docs/builders/amazon-ebs.html) - Create EBS-backed AMIs
by launching a source AMI and re-packaging it into a new AMI after
provisioning. If in doubt, use this builder, which is the easiest to get
started with.
- [amazon-ebs](/docs/builders/amazon-ebs.html) - Create EBS-backed AMIs by
launching a source AMI and re-packaging it into a new AMI after provisioning.
If in doubt, use this builder, which is the easiest to get started with.
* [amazon-instance](/docs/builders/amazon-instance.html) - Create
instance-store AMIs by launching and provisioning a source instance, then
rebundling it and uploading it to S3.
- [amazon-instance](/docs/builders/amazon-instance.html) - Create instance-store
AMIs by launching and provisioning a source instance, then rebundling it and
uploading it to S3.
* [amazon-chroot](/docs/builders/amazon-chroot.html) - Create EBS-backed AMIs
- [amazon-chroot](/docs/builders/amazon-chroot.html) - Create EBS-backed AMIs
from an existing EC2 instance by mounting the root device and using a
[Chroot](http://en.wikipedia.org/wiki/Chroot) environment to provision
that device. This is an **advanced builder and should not be used by
newcomers**. However, it is also the fastest way to build an EBS-backed
AMI since no new EC2 instance needs to be launched.
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](/docs/builders/amazon-ebs.html). It is
much easier to use and Amazon generally recommends EBS-backed images nowadays.
-&gt; **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
If AWS keys are not specified in the template, a [credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files) file or through environment variables
Packer will use credentials provided by the instance's IAM profile, if it has one.
If AWS keys are not specified in the template, a
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or through environment variables Packer will use credentials provided by
the instance's IAM profile, if it has one.
The following policy document provides the minimal set permissions necessary for Packer to work:
The following policy document provides the minimal set permissions necessary for
Packer to work:
```javascript
``` {.javascript}
{
"Statement": [{
"Effect": "Allow",
......
---
layout: "docs"
page_title: "Custom Builder"
description: |-
Packer is extensible, allowing you to write new builders without having to modify the core source code of Packer itself. Documentation for creating new builders is covered in the custom builders page of the Packer plugin section.
---
description: |
Packer is extensible, allowing you to write new builders without having to
modify the core source code of Packer itself. Documentation for creating new
builders is covered in the custom builders page of the Packer plugin section.
layout: docs
page_title: Custom Builder
...
# Custom Builder
Packer is extensible, allowing you to write new builders without having to
modify the core source code of Packer itself. Documentation for creating
new builders is covered in the [custom builders](/docs/extend/builder.html)
page of the Packer plugin section.
modify the core source code of Packer itself. Documentation for creating new
builders is covered in the [custom builders](/docs/extend/builder.html) page of
the Packer plugin section.
---
layout: "docs"
page_title: "DigitalOcean Builder"
description: |-
The `digitalocean` Packer builder is able to create new images for use with DigitalOcean. The builder takes a source image, runs any provisioning necessary on the image after launching it, then snapshots it into a reusable image. This reusable image can then be used as the foundation of new servers that are launched within DigitalOcean.
---
description: |
The `digitalocean` Packer builder is able to create new images for use with
DigitalOcean. The builder takes a source image, runs any provisioning necessary
on the image after launching it, then snapshots it into a reusable image. This
reusable image can then be used as the foundation of new servers that are
launched within DigitalOcean.
layout: docs
page_title: DigitalOcean Builder
...
# DigitalOcean Builder
Type: `digitalocean`
The `digitalocean` Packer builder is able to create new images for use with
[DigitalOcean](http://www.digitalocean.com). The builder takes a source
image, runs any provisioning necessary on the image after launching it,
then snapshots it into a reusable image. This reusable image can then be
used as the foundation of new servers that are launched within DigitalOcean.
[DigitalOcean](http://www.digitalocean.com). The builder takes a source image,
runs any provisioning necessary on the image after launching it, then snapshots
it into a reusable image. This reusable image can then be used as the foundation
of new servers that are launched within DigitalOcean.
The builder does _not_ manage images. Once it creates an image, it is up to
you to use it or delete it.
The builder does *not* manage images. Once it creates an image, it is up to you
to use it or delete it.
## Configuration Reference
......@@ -25,50 +29,53 @@ segmented below into two categories: required and optional parameters. Within
each category, the available configuration keys are alphabetized.
In addition to the options listed here, a
[communicator](/docs/templates/communicator.html)
can be configured for this builder.
[communicator](/docs/templates/communicator.html) can be configured for this
builder.
### Required:
* `api_token` (string) - The client TOKEN to use to access your account.
It can also be specified via environment variable `DIGITALOCEAN_API_TOKEN`, if set.
- `api_token` (string) - The client TOKEN to use to access your account. It can
also be specified via environment variable `DIGITALOCEAN_API_TOKEN`, if set.
* `image` (string) - The name (or slug) of the base image to use. This is the
image that will be used to launch a new droplet and provision it.
See https://developers.digitalocean.com/documentation/v2/#list-all-images for details on how to get a list of the the accepted image names/slugs.
- `image` (string) - The name (or slug) of the base image to use. This is the
image that will be used to launch a new droplet and provision it. See
https://developers.digitalocean.com/documentation/v2/\#list-all-images for
details on how to get a list of the the accepted image names/slugs.
* `region` (string) - The name (or slug) of the region to launch the droplet in.
Consequently, this is the region where the snapshot will be available.
See https://developers.digitalocean.com/documentation/v2/#list-all-regions for the accepted region names/slugs.
- `region` (string) - The name (or slug) of the region to launch the droplet in.
Consequently, this is the region where the snapshot will be available. See
https://developers.digitalocean.com/documentation/v2/\#list-all-regions for
the accepted region names/slugs.
* `size` (string) - The name (or slug) of the droplet size to use.
See https://developers.digitalocean.com/documentation/v2/#list-all-sizes for the accepted size names/slugs.
- `size` (string) - The name (or slug) of the droplet size to use. See
https://developers.digitalocean.com/documentation/v2/\#list-all-sizes for the
accepted size names/slugs.
### Optional:
* `droplet_name` (string) - The name assigned to the droplet. DigitalOcean
sets the hostname of the machine to this value.
- `droplet_name` (string) - The name assigned to the droplet. DigitalOcean sets
the hostname of the machine to this value.
* `private_networking` (boolean) - Set to `true` to enable private networking
- `private_networking` (boolean) - Set to `true` to enable private networking
for the droplet being created. This defaults to `false`, or not enabled.
* `snapshot_name` (string) - The name of the resulting snapshot that will
appear in your account. This must be unique.
To help make this unique, use a function like `timestamp` (see
[configuration templates](/docs/templates/configuration-templates.html) for more info)
- `snapshot_name` (string) - The name of the resulting snapshot that will appear
in your account. This must be unique. To help make this unique, use a function
like `timestamp` (see [configuration
templates](/docs/templates/configuration-templates.html) for more info)
* `state_timeout` (string) - The time to wait, as a duration string,
for a droplet to enter a desired state (such as "active") before
timing out. The default state timeout is "6m".
- `state_timeout` (string) - The time to wait, as a duration string, for a
droplet to enter a desired state (such as "active") before timing out. The
default state timeout is "6m".
* `user_data` (string) - User data to launch with the Droplet.
- `user_data` (string) - User data to launch with the Droplet.
## Basic Example
Here is a basic example. It is completely valid as soon as you enter your
own access tokens:
Here is a basic example. It is completely valid as soon as you enter your own
access tokens:
```javascript
``` {.javascript}
{
"type": "digitalocean",
"api_token": "YOUR API KEY",
......
---
layout: "docs"
page_title: "Null Builder"
description: |-
The `null` Packer builder is not really a builder, it just sets up an SSH connection and runs the provisioners. It can be used to debug provisioners without incurring high wait times. It does not create any kind of image or artifact.
---
description: |
The `null` Packer builder is not really a builder, it just sets up an SSH
connection and runs the provisioners. It can be used to debug provisioners
without incurring high wait times. It does not create any kind of image or
artifact.
layout: docs
page_title: Null Builder
...
# Null Builder
Type: `null`
The `null` Packer builder is not really a builder, it just sets up an SSH connection
and runs the provisioners. It can be used to debug provisioners without
incurring high wait times. It does not create any kind of image or artifact.
The `null` Packer builder is not really a builder, it just sets up an SSH
connection and runs the provisioners. It can be used to debug provisioners
without incurring high wait times. It does not create any kind of image or
artifact.
## Basic Example
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.
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
``` {.javascript}
{
"type": "null",
"ssh_host": "127.0.0.1",
......@@ -31,4 +35,3 @@ no provisioners are defined, but it will connect to the specified host via ssh.
The null builder has no configuration parameters other than the
[communicator](/docs/templates/communicator.html) settings.
---
layout: "docs"
page_title: "OpenStack Builder"
description: |-
The `openstack` Packer builder is able to create new images for use with OpenStack. The builder takes a source image, runs any provisioning necessary on the image after launching it, then creates a new reusable image. This reusable image can then be used as the foundation of new servers that are launched within OpenStack. The builder will create temporary keypairs that provide temporary access to the server while the image is being created. This simplifies configuration quite a bit.
---
description: |
The `openstack` Packer builder is able to create new images for use with
OpenStack. The builder takes a source image, runs any provisioning necessary on
the image after launching it, then creates a new reusable image. This reusable
image can then be used as the foundation of new servers that are launched within
OpenStack. The builder will create temporary keypairs that provide temporary
access to the server while the image is being created. This simplifies
configuration quite a bit.
layout: docs
page_title: OpenStack Builder
...
# OpenStack Builder
Type: `openstack`
The `openstack` Packer builder is able to create new images for use with
[OpenStack](http://www.openstack.org). The builder takes a source
image, runs any provisioning necessary on the image after launching it,
then creates a new reusable image. This reusable image can then be
used as the foundation of new servers that are launched within OpenStack.
The builder will create temporary keypairs that provide temporary access to
the server while the image is being created. This simplifies configuration
quite a bit.
[OpenStack](http://www.openstack.org). The builder takes a source image, runs
any provisioning necessary on the image after launching it, then creates a new
reusable image. This reusable image can then be used as the foundation of new
servers that are launched within OpenStack. The builder will create temporary
keypairs that provide temporary access to the server while the image is being
created. This simplifies configuration quite a bit.
The builder does _not_ manage images. Once it creates an image, it is up to
you to use it or delete it.
The builder does *not* manage images. Once it creates an image, it is up to you
to use it or delete it.
## Configuration Reference
......@@ -28,81 +33,79 @@ segmented below into two categories: required and optional parameters. Within
each category, the available configuration keys are alphabetized.
In addition to the options listed here, a
[communicator](/docs/templates/communicator.html)
can be configured for this builder.
[communicator](/docs/templates/communicator.html) can be configured for this
builder.
### Required:
* `flavor` (string) - The ID, name, or full URL for the desired flavor for the
- `flavor` (string) - The ID, name, or full URL for the desired flavor for the
server to be created.
* `image_name` (string) - The name of the resulting image.
- `image_name` (string) - The name of the resulting image.
* `source_image` (string) - The ID or full URL to the base image to use.
This is the image that will be used to launch a new server and provision it.
Unless you specify completely custom SSH settings, the source image must
have `cloud-init` installed so that the keypair gets assigned properly.
- `source_image` (string) - The ID or full URL to the base image to use. This is
the image that will be used to launch a new server and provision it. Unless
you specify completely custom SSH settings, the source image must have
`cloud-init` installed so that the keypair gets assigned properly.
* `username` (string) - The username used to connect to the OpenStack service.
If not specified, Packer will use the environment variable
`OS_USERNAME`, if set.
- `username` (string) - The username used to connect to the OpenStack service.
If not specified, Packer will use the environment variable `OS_USERNAME`,
if set.
* `password` (string) - The password used to connect to the OpenStack service.
If not specified, Packer will use the environment variables
`OS_PASSWORD`, if set.
- `password` (string) - The password used to connect to the OpenStack service.
If not specified, Packer will use the environment variables `OS_PASSWORD`,
if set.
### Optional:
* `api_key` (string) - The API key used to access OpenStack. Some OpenStack
- `api_key` (string) - The API key used to access OpenStack. Some OpenStack
installations require this.
* `availability_zone` (string) - The availability zone to launch the
server in. If this isn't specified, the default enforced by your OpenStack
cluster will be used. This may be required for some OpenStack clusters.
- `availability_zone` (string) - The availability zone to launch the server in.
If this isn't specified, the default enforced by your OpenStack cluster will
be used. This may be required for some OpenStack clusters.
* `floating_ip` (string) - A specific floating IP to assign to this instance.
- `floating_ip` (string) - A specific floating IP to assign to this instance.
`use_floating_ip` must also be set to true for this to have an affect.
* `floating_ip_pool` (string) - The name of the floating IP pool to use
to allocate a floating IP. `use_floating_ip` must also be set to true
for this to have an affect.
- `floating_ip_pool` (string) - The name of the floating IP pool to use to
allocate a floating IP. `use_floating_ip` must also be set to true for this to
have an affect.
* `insecure` (boolean) - Whether or not the connection to OpenStack can be done
- `insecure` (boolean) - Whether or not the connection to OpenStack can be done
over an insecure connection. By default this is false.
* `networks` (array of strings) - A list of networks by UUID to attach
to this instance.
- `networks` (array of strings) - A list of networks by UUID to attach to
this instance.
* `tenant_id` or `tenant_name` (string) - The tenant ID or name to boot the
instance into. Some OpenStack installations require this.
If not specified, Packer will use the environment variable
`OS_TENANT_NAME`, if set.
- `tenant_id` or `tenant_name` (string) - The tenant ID or name to boot the
instance into. Some OpenStack installations require this. If not specified,
Packer will use the environment variable `OS_TENANT_NAME`, if set.
* `security_groups` (array of strings) - A list of security groups by name
to add to this instance.
- `security_groups` (array of strings) - A list of security groups by name to
add to this instance.
* `region` (string) - The name of the region, such as "DFW", in which
to launch the server to create the AMI.
If not specified, Packer will use the environment variable
`OS_REGION_NAME`, if set.
- `region` (string) - The name of the region, such as "DFW", in which to launch
the server to create the AMI. If not specified, Packer will use the
environment variable `OS_REGION_NAME`, if set.
* `ssh_interface` (string) - The type of interface to connect via SSH. Values
useful for Rackspace are "public" or "private", and the default behavior is
to connect via whichever is returned first from the OpenStack API.
- `ssh_interface` (string) - The type of interface to connect via SSH. Values
useful for Rackspace are "public" or "private", and the default behavior is to
connect via whichever is returned first from the OpenStack API.
* `use_floating_ip` (boolean) - Whether or not to use a floating IP for
- `use_floating_ip` (boolean) - Whether or not to use a floating IP for
the instance. Defaults to false.
* `rackconnect_wait` (boolean) - For rackspace, whether or not to wait for
- `rackconnect_wait` (boolean) - For rackspace, whether or not to wait for
Rackconnect to assign the machine an IP address before connecting via SSH.
Defaults to false.
## Basic Example: Rackspace public cloud
Here is a basic example. This is a working example to build a
Ubuntu 12.04 LTS (Precise Pangolin) on Rackspace OpenStack cloud offering.
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
``` {.javascript}
{
"type": "openstack",
"username": "foo",
......@@ -117,10 +120,10 @@ Ubuntu 12.04 LTS (Precise Pangolin) on Rackspace OpenStack cloud offering.
## Basic Example: Private OpenStack cloud
This example builds an Ubuntu 14.04 image on a private OpenStack cloud,
powered by Metacloud.
This example builds an Ubuntu 14.04 image on a private OpenStack cloud, powered
by Metacloud.
```javascript
``` {.javascript}
{
"type": "openstack",
"ssh_username": "root",
......@@ -130,12 +133,12 @@ powered by Metacloud.
}
```
In this case, the connection information for connecting to OpenStack
doesn't appear in the template. That is because I source a standard
OpenStack script with environment variables set before I run this. This
script is setting environment variables like:
In this case, the connection information for connecting to OpenStack doesn't
appear in the template. That is because I source a standard OpenStack script
with environment variables set before I run this. This script is setting
environment variables like:
* `OS_AUTH_URL`
* `OS_TENANT_ID`
* `OS_USERNAME`
* `OS_PASSWORD`
- `OS_AUTH_URL`
- `OS_TENANT_ID`
- `OS_USERNAME`
- `OS_PASSWORD`
---
layout: "docs"
page_title: "Parallels Builder"
description: |-
The Parallels Packer builder is able to create Parallels Desktop for Mac virtual machines and export them in the PVM format.
---
description: |
The Parallels Packer builder is able to create Parallels Desktop for Mac virtual
machines and export them in the PVM format.
layout: docs
page_title: Parallels Builder
...
# Parallels Builder
The Parallels Packer builder is able to create [Parallels Desktop for Mac](http://www.parallels.com/products/desktop/) virtual machines and export them in the PVM format.
Packer actually comes with multiple builders able to create Parallels
machines, depending on the strategy you want to use to build the image.
Packer supports the following Parallels builders:
The Parallels Packer builder is able to create [Parallels Desktop for
Mac](http://www.parallels.com/products/desktop/) virtual machines and export
them in the PVM format.
* [parallels-iso](/docs/builders/parallels-iso.html) - Starts from
an ISO file, creates a brand new Parallels VM, installs an OS,
provisions software within the OS, then exports that machine to create
an image. This is best for people who want to start from scratch.
Packer actually comes with multiple builders able to create Parallels machines,
depending on the strategy you want to use to build the image. Packer supports
the following Parallels builders:
* [parallels-pvm](/docs/builders/parallels-pvm.html) - This builder
imports an existing PVM file, runs provisioners on top of that VM,
and exports that machine to create an image. This is best if you have
an existing Parallels VM export you want to use as the source. As an
additional benefit, you can feed the artifact of this builder back into
itself to iterate on a machine.
- [parallels-iso](/docs/builders/parallels-iso.html) - Starts from an ISO file,
creates a brand new Parallels VM, installs an OS, provisions software within
the OS, then exports that machine to create an image. This is best for people
who want to start from scratch.
- [parallels-pvm](/docs/builders/parallels-pvm.html) - This builder imports an
existing PVM file, runs provisioners on top of that VM, and exports that
machine to create an image. This is best if you have an existing Parallels VM
export you want to use as the source. As an additional benefit, you can feed
the artifact of this builder back into itself to iterate on a machine.
## Requirements
In addition to [Parallels Desktop for Mac](http://www.parallels.com/products/desktop/) this requires the
[Parallels Virtualization SDK](http://www.parallels.com/downloads/desktop/).
In addition to [Parallels Desktop for
Mac](http://www.parallels.com/products/desktop/) this requires the [Parallels
Virtualization SDK](http://www.parallels.com/downloads/desktop/).
The SDK can be installed by downloading and following the instructions in the dmg.
The SDK can be installed by downloading and following the instructions in the
dmg.
---
layout: "docs"
page_title: "VirtualBox Builder"
description: |-
The VirtualBox Packer builder is able to create VirtualBox virtual machines and export them in the OVA or OVF format.
---
description: |
The VirtualBox Packer builder is able to create VirtualBox virtual machines and
export them in the OVA or OVF format.
layout: docs
page_title: VirtualBox Builder
...
# VirtualBox Builder
The VirtualBox Packer builder is able to create [VirtualBox](http://www.virtualbox.org)
virtual machines and export them in the OVA or OVF format.
The VirtualBox Packer builder is able to create
[VirtualBox](http://www.virtualbox.org) virtual machines and export them in the
OVA or OVF format.
Packer actually comes with multiple builders able to create VirtualBox
machines, depending on the strategy you want to use to build the image.
Packer supports the following VirtualBox builders:
Packer actually comes with multiple builders able to create VirtualBox machines,
depending on the strategy you want to use to build the image. Packer supports
the following VirtualBox builders:
* [virtualbox-iso](/docs/builders/virtualbox-iso.html) - Starts from
an ISO file, creates a brand new VirtualBox VM, installs an OS,
provisions software within the OS, then exports that machine to create
an image. This is best for people who want to start from scratch.
- [virtualbox-iso](/docs/builders/virtualbox-iso.html) - Starts from an ISO
file, creates a brand new VirtualBox VM, installs an OS, provisions software
within the OS, then exports that machine to create an image. This is best for
people who want to start from scratch.
* [virtualbox-ovf](/docs/builders/virtualbox-ovf.html) - This builder
imports an existing OVF/OVA file, runs provisioners on top of that VM,
and exports that machine to create an image. This is best if you have
an existing VirtualBox VM export you want to use as the source. As an
additional benefit, you can feed the artifact of this builder back into
itself to iterate on a machine.
- [virtualbox-ovf](/docs/builders/virtualbox-ovf.html) - This builder imports an
existing OVF/OVA file, runs provisioners on top of that VM, and exports that
machine to create an image. This is best if you have an existing VirtualBox VM
export you want to use as the source. As an additional benefit, you can feed
the artifact of this builder back into itself to iterate on a machine.
---
layout: "docs"
page_title: "VMware Builder"
description: |-
The VMware Packer builder is able to create VMware virtual machines for use with any VMware product.
---
description: |
The VMware Packer builder is able to create VMware virtual machines for use with
any VMware product.
layout: docs
page_title: VMware Builder
...
# VMware Builder
The VMware Packer builder is able to create VMware virtual machines for use
with any VMware product.
The VMware Packer builder is able to create VMware virtual machines for use with
any VMware product.
Packer actually comes with multiple builders able to create VMware
machines, depending on the strategy you want to use to build the image.
Packer supports the following VMware builders:
Packer actually comes with multiple builders able to create VMware machines,
depending on the strategy you want to use to build the image. Packer supports
the following VMware builders:
* [vmware-iso](/docs/builders/vmware-iso.html) - Starts from
an ISO file, creates a brand new VMware VM, installs an OS,
provisions software within the OS, then exports that machine to create
an image. This is best for people who want to start from scratch.
- [vmware-iso](/docs/builders/vmware-iso.html) - Starts from an ISO file,
creates a brand new VMware VM, installs an OS, provisions software within the
OS, then exports that machine to create an image. This is best for people who
want to start from scratch.
* [vmware-vmx](/docs/builders/vmware-vmx.html) - This builder
imports an existing VMware machine (from a VMX file), runs provisioners
on top of that VM, and exports that machine to create an image.
This is best if you have an existing VMware VM you want to use as the
source. As an additional benefit, you can feed the artifact of this
builder back into Packer to iterate on a machine.
- [vmware-vmx](/docs/builders/vmware-vmx.html) - This builder imports an
existing VMware machine (from a VMX file), runs provisioners on top of that
VM, and exports that machine to create an image. This is best if you have an
existing VMware VM you want to use as the source. As an additional benefit,
you can feed the artifact of this builder back into Packer to iterate on
a machine.
---
layout: "docs"
page_title: "Build - Command-Line"
description: |-
The `packer build` Packer command takes a template and runs all the builds within it in order to generate a set of artifacts. The various builds specified within a template are executed in parallel, unless otherwise specified. And the artifacts that are created will be outputted at the end of the build.
---
description: |
The `packer build` Packer command takes a template and runs all the builds
within it in order to generate a set of artifacts. The various builds specified
within a template are executed in parallel, unless otherwise specified. And the
artifacts that are created will be outputted at the end of the build.
layout: docs
page_title: 'Build - Command-Line'
...
# Command-Line: Build
The `packer build` Packer command takes a template and runs all the builds within
it in order to generate a set of artifacts. The various builds specified within
a template are executed in parallel, unless otherwise specified. And the
The `packer build` Packer command takes a template and runs all the builds
within it in order to generate a set of artifacts. The various builds specified
within a template are executed in parallel, unless otherwise specified. And the
artifacts that are created will be outputted at the end of the build.
## Options
* `-color=false` - Disables colorized output. Enabled by default.
- `-color=false` - Disables colorized output. Enabled by default.
* `-debug` - Disables parallelization and enables debug mode. Debug mode flags
- `-debug` - Disables parallelization and enables debug mode. Debug mode flags
the builders that they should output debugging information. The exact behavior
of debug mode is left to the builder. In general, builders usually will stop
between each step, waiting for keyboard input before continuing. This will allow
the user to inspect state and so on.
between each step, waiting for keyboard input before continuing. This will
allow the user to inspect state and so on.
* `-except=foo,bar,baz` - Builds all the builds except those with the given
- `-except=foo,bar,baz` - Builds all the builds except those with the given
comma-separated names. Build names by default are the names of their builders,
unless a specific `name` attribute is specified within the configuration.
* `-force` - Forces a builder to run when artifacts from a previous build prevent
a build from running. The exact behavior of a forced build is left to the builder.
In general, a builder supporting the forced build will remove the artifacts from
the previous build. This will allow the user to repeat a build without having to
manually clean these artifacts beforehand.
- `-force` - Forces a builder to run when artifacts from a previous build
prevent a build from running. The exact behavior of a forced build is left to
the builder. In general, a builder supporting the forced build will remove the
artifacts from the previous build. This will allow the user to repeat a build
without having to manually clean these artifacts beforehand.
* `-only=foo,bar,baz` - Only build the builds with the given comma-separated
names. Build names by default are the names of their builders, unless a
specific `name` attribute is specified within the configuration.
- `-only=foo,bar,baz` - Only build the builds with the given
comma-separated names. Build names by default are the names of their builders,
unless a specific `name` attribute is specified within the configuration.
---
layout: "docs"
page_title: "Packer Command-Line"
description: |-
Packer is controlled using a command-line interface. All interaction with Packer is done via the `packer` tool. Like many other command-line tools, the `packer` tool takes a subcommand to execute, and that subcommand may have additional options as well. Subcommands are executed with `packer SUBCOMMAND`, where "SUBCOMMAND" is obviously the actual command you wish to execute.
---
description: |
Packer is controlled using a command-line interface. All interaction with Packer
is done via the `packer` tool. Like many other command-line tools, the `packer`
tool takes a subcommand to execute, and that subcommand may have additional
options as well. Subcommands are executed with `packer SUBCOMMAND`, where
"SUBCOMMAND" is obviously the actual command you wish to execute.
layout: docs
page_title: 'Packer Command-Line'
...
# Packer Command-Line
Packer is controlled using a command-line interface. All interaction with
Packer is done via the `packer` tool. Like many other command-line tools,
the `packer` tool takes a subcommand to execute, and that subcommand may
have additional options as well. Subcommands are executed with
`packer SUBCOMMAND`, where "SUBCOMMAND" is obviously the actual command you wish
to execute.
Packer is controlled using a command-line interface. All interaction with Packer
is done via the `packer` tool. Like many other command-line tools, the `packer`
tool takes a subcommand to execute, and that subcommand may have additional
options as well. Subcommands are executed with `packer SUBCOMMAND`, where
"SUBCOMMAND" is obviously the actual command you wish to execute.
If you run `packer` by itself, help will be displayed showing all available
subcommands and a brief synopsis of what they do. In addition to this, you can
run any `packer` command with the `-h` flag to output more detailed help for
a specific subcommand.
run any `packer` command with the `-h` flag to output more detailed help for a
specific subcommand.
In addition to the documentation available on the command-line, each command
is documented on this website. You can find the documentation for a specific
In addition to the documentation available on the command-line, each command is
documented on this website. You can find the documentation for a specific
subcommand using the navigation to the left.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
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