Skip to content

P
packer
Commit d8e8f98b authored by Chris Bednarski's avatar Chris Bednarski
Browse files
Options

Change to 4 spaces

parent 555a8ba7
Hide whitespace changes
Inline Side-by-side
Showing with 2463 additions and 2384 deletions
website/Makefile
View file @ d8e8f98b
......@@ -13,5 +13,5 @@ format:
bundle exec htmlbeautifier -t 2 source/*.erb
bundle exec htmlbeautifier -t 2 source/layouts/*.erb
@pandoc -v > /dev/null || echo "pandoc must be installed in order to format markdown content"
pandoc -v > /dev/null && find . -iname "*.html.markdown" | xargs -I{} bash -c "pandoc -r markdown -w markdown --tab-stop=2 --atx-headers -s --columns=80 {} > {}.new"\; || true
pandoc -v > /dev/null && find . -iname "*.html.markdown" | xargs -I{} bash -c "pandoc -r markdown -w markdown --tab-stop=4 --atx-headers -s --columns=80 {} > {}.new"\; || true
pandoc -v > /dev/null && find . -iname "*.html.markdown" | xargs -I{} bash -c "mv {}.new {}"\; || true
website/source/community/index.html.markdown
View file @ d8e8f98b
......@@ -29,7 +29,8 @@ list as contributors come and go.
<div class="people">
<div class="person">
<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>
......@@ -41,9 +42,11 @@ list as contributors come and go.
described as "automation obsessed."
</p>
</div>
</div>
<div class="person">
</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>
......@@ -52,9 +55,11 @@ list as contributors come and go.
for Packer. Outside of Packer, Jack is an avid open source
contributor and software consultant.</p>
</div>
</div>
<div class="person">
</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>
......@@ -65,9 +70,11 @@ list as contributors come and go.
<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">
</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>
......@@ -78,9 +85,11 @@ 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">
</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>
......@@ -90,8 +99,11 @@ 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>
<div class="clearfix">
</div>
</div>
website/source/docs/basics/terminology.html.markdown
View file @ d8e8f98b
......@@ -17,41 +17,41 @@ 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.
- `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.
website/source/docs/builders/amazon-chroot.html.markdown
View file @ d8e8f98b
......@@ -60,98 +60,100 @@ builder.
### Required:
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set. If the environmental variables
aren't set and Packer is running on an EC2 instance, Packer will check the
instance metadata for IAM role keys.
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set. If the environmental variables
aren't set and Packer is running on an EC2 instance, Packer will check the
instance metadata for IAM role keys.
- `source_ami` (string) - The source AMI whose root volume will be copied and
provisioned on the currently running instance. This must be an EBS-backed AMI
with a root volume snapshot that you have access to.
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set. If the environmental variables
aren't set and Packer is running on an EC2 instance, Packer will check the
instance metadata for IAM role keys.
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set. If the environmental variables
aren't set and Packer is running on an EC2 instance, Packer will check the
instance metadata for IAM role keys.
- `source_ami` (string) - The source AMI whose root volume will be copied and
provisioned on the currently running instance. This must be an EBS-backed
AMI with a root volume snapshot that you have access to.
### Optional:
- `ami_description` (string) - The description to set for the resulting AMI(s).
By default this description is empty.
- `ami_description` (string) - The description to set for the
resulting AMI(s). By default this description is empty.
- `ami_groups` (array of strings) - A list of groups that have access to launch
the resulting AMI(s). By default no groups have permission to launch the AMI.
`all` will make the AMI publicly accessible.
- `ami_groups` (array of strings) - A list of groups that have access to
launch the resulting AMI(s). By default no groups have permission to launch
the AMI. `all` will make the AMI publicly accessible.
- `ami_product_codes` (array of strings) - A list of product codes to associate
with the AMI. By default no product codes are associated with the AMI.
- `ami_product_codes` (array of strings) - A list of product codes to
associate with the AMI. By default no product codes are associated with
the AMI.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to. Tags
and attributes are copied along with the AMI. AMI copying takes time depending
on the size of the AMI, but will generally take many minutes.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to.
Tags and attributes are copied along with the AMI. AMI copying takes time
depending on the size of the AMI, but will generally take many minutes.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `ami_virtualization_type` (string) - The type of virtualization for the AMI
you are building. This option is required to register HVM images. Can be
"paravirtual" (default) or "hvm".
- `ami_virtualization_type` (string) - The type of virtualization for the AMI
you are building. This option is required to register HVM images. Can be
"paravirtual" (default) or "hvm".
- `chroot_mounts` (array of array of strings) - This is a list of additional
devices to mount into the chroot environment. This configuration parameter
requires some additional documentation which is in the "Chroot Mounts"
section below. Please read that section for more information on how to
use this.
- `chroot_mounts` (array of array of strings) - This is a list of additional
devices to mount into the chroot environment. This configuration parameter
requires some additional documentation which is in the "Chroot Mounts"
section below. Please read that section for more information on how to
use this.
- `command_wrapper` (string) - How to run shell commands. This defaults
to "{{.Command}}". This may be useful to set if you want to set environmental
variables or perhaps run it with `sudo` or so on. This is a configuration
template where the `.Command` variable is replaced with the command to be run.
- `command_wrapper` (string) - How to run shell commands. This defaults
to "{{.Command}}". This may be useful to set if you want to set
environmental variables or perhaps run it with `sudo` or so on. This is a
configuration template where the `.Command` variable is replaced with the
command to be run.
- `copy_files` (array of strings) - Paths to files on the running EC2 instance
that will be copied into the chroot environment prior to provisioning. This is
useful, for example, to copy `/etc/resolv.conf` so that DNS lookups work.
- `copy_files` (array of strings) - Paths to files on the running EC2 instance
that will be copied into the chroot environment prior to provisioning. This
is useful, for example, to copy `/etc/resolv.conf` so that DNS lookups work.
- `device_path` (string) - The path to the device where the root volume of the
source AMI will be attached. This defaults to "" (empty string), which forces
Packer to find an open device automatically.
- `device_path` (string) - The path to the device where the root volume of the
source AMI will be attached. This defaults to "" (empty string), which
forces Packer to find an open device automatically.
- `enhanced_networking` (boolean) - Enable enhanced networking (SriovNetSupport)
on HVM-compatible AMIs. If true, add `ec2:ModifyInstanceAttribute` to your AWS
IAM policy.
- `enhanced_networking` (boolean) - Enable enhanced
networking (SriovNetSupport) on HVM-compatible AMIs. If true, add
`ec2:ModifyInstanceAttribute` to your AWS IAM policy.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `mount_path` (string) - The path where the volume will be mounted. This is
where the chroot environment will be. This defaults to
`packer-amazon-chroot-volumes/{{.Device}}`. This is a configuration template
where the `.Device` variable is replaced with the name of the device where the
volume is attached.
- `mount_path` (string) - The path where the volume will be mounted. This is
where the chroot environment will be. This defaults to
`packer-amazon-chroot-volumes/{{.Device}}`. This is a configuration template
where the `.Device` variable is replaced with the name of the device where
the volume is attached.
- `mount_options` (array of strings) - Options to supply the `mount` command
when mounting devices. Each option will be prefixed with `-o` and supplied to
the `mount` command ran by Packer. Because this command is ran in a shell,
user discrestion is advised. See [this manual page for the mount
command](http://linuxcommand.org/man_pages/mount8.html) for valid file system
specific options
- `mount_options` (array of strings) - Options to supply the `mount` command
when mounting devices. Each option will be prefixed with `-o` and supplied
to the `mount` command ran by Packer. Because this command is ran in a
shell, user discrestion is advised. See [this manual page for the mount
command](http://linuxcommand.org/man_pages/mount8.html) for valid file
system specific options
- `root_volume_size` (integer) - The size of the root volume for the chroot
environment, and the resulting AMI
- `root_volume_size` (integer) - The size of the root volume for the chroot
environment, and the resulting AMI
- `tags` (object of key/value strings) - Tags applied to the AMI.
- `tags` (object of key/value strings) - Tags applied to the AMI.
## Basic Example
......@@ -173,11 +175,11 @@ The `chroot_mounts` configuration can be used to mount additional devices within
the chroot. By default, the following additional mounts are added into the
chroot by Packer:
- `/proc` (proc)
- `/sys` (sysfs)
- `/dev` (bind to real `/dev`)
- `/dev/pts` (devpts)
- `/proc/sys/fs/binfmt_misc` (binfmt\_misc)
- `/proc` (proc)
- `/sys` (sysfs)
- `/dev` (bind to real `/dev`)
- `/dev/pts` (devpts)
- `/proc/sys/fs/binfmt_misc` (binfmt\_misc)
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
......@@ -195,12 +197,12 @@ However, if you want to change or add the mount points, you may using the
`chroot_mounts` is a list of a 3-tuples of strings. The three components of the
3-tuple, in order, are:
- The filesystem type. If this is "bind", then Packer will properly bind the
filesystem to another mount point.
- The filesystem type. If this is "bind", then Packer will properly bind the
filesystem to another mount point.
- The source device.
- The source device.
- The mount directory.
- The mount directory.
## Parallelism
......
website/source/docs/builders/amazon-ebs.html.markdown
View file @ d8e8f98b
......@@ -40,162 +40,164 @@ builder.
### Required:
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set.
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set.
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `instance_type` (string) - The EC2 instance type to use while building the
AMI, such as "m1.small".
- `instance_type` (string) - The EC2 instance type to use while building the
AMI, such as "m1.small".
- `region` (string) - The name of the region, such as "us-east-1", in which to
launch the EC2 instance to create the AMI.
- `region` (string) - The name of the region, such as "us-east-1", in which to
launch the EC2 instance to create the AMI.
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set.
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set.
- `source_ami` (string) - The initial AMI used as a base for the newly
created machine.
- `source_ami` (string) - The initial AMI used as a base for the newly
created machine.
- `ssh_username` (string) - The username to use in order to communicate over SSH
to the running machine.
- `ssh_username` (string) - The username to use in order to communicate over
SSH to the running machine.
### Optional:
- `ami_block_device_mappings` (array of block device mappings) - Add the block
device mappings to the AMI. The block device mappings allow for keys:
- `ami_block_device_mappings` (array of block device mappings) - Add the block
device mappings to the AMI. The block device mappings allow for keys:
- `device_name` (string) - The device name exposed to the instance (for
- `device_name` (string) - The device name exposed to the instance (for
example, "/dev/sdh" or "xvdh")
- `virtual_name` (string) - The virtual device name. See the documentation on
- `virtual_name` (string) - The virtual device name. See the documentation on
[Block Device
Mapping](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_BlockDeviceMapping.html)
for more information
- `snapshot_id` (string) - The ID of the snapshot
- `volume_type` (string) - The volume type. gp2 for General Purpose (SSD)
- `snapshot_id` (string) - The ID of the snapshot
- `volume_type` (string) - The volume type. gp2 for General Purpose (SSD)
volumes, io1 for Provisioned IOPS (SSD) volumes, and standard for Magnetic
volumes
- `volume_size` (integer) - The size of the volume, in GiB. Required if not
- `volume_size` (integer) - The size of the volume, in GiB. Required if not
specifying a `snapshot_id`
- `delete_on_termination` (boolean) - Indicates whether the EBS volume is
- `delete_on_termination` (boolean) - Indicates whether the EBS volume is
deleted on instance termination
- `encrypted` (boolean) - Indicates whether to encrypt the volume or not
- `no_device` (boolean) - Suppresses the specified device included in the
- `encrypted` (boolean) - Indicates whether to encrypt the volume or not
- `no_device` (boolean) - Suppresses the specified device included in the
block device mapping of the AMI
- `iops` (integer) - The number of I/O operations per second (IOPS) that the
- `iops` (integer) - The number of I/O operations per second (IOPS) that the
volume supports. See the documentation on
[IOPs](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_EbsBlockDevice.html)
for more information
- `ami_description` (string) - The description to set for the resulting AMI(s).
By default this description is empty.
- `ami_description` (string) - The description to set for the
resulting AMI(s). By default this description is empty.
- `ami_groups` (array of strings) - A list of groups that have access to launch
the resulting AMI(s). By default no groups have permission to launch the AMI.
`all` will make the AMI publicly accessible. AWS currently doesn't accept any
value other than "all".
- `ami_groups` (array of strings) - A list of groups that have access to
launch the resulting AMI(s). By default no groups have permission to launch
the AMI. `all` will make the AMI publicly accessible. AWS currently doesn't
accept any value other than "all".
- `ami_product_codes` (array of strings) - A list of product codes to associate
with the AMI. By default no product codes are associated with the AMI.
- `ami_product_codes` (array of strings) - A list of product codes to
associate with the AMI. By default no product codes are associated with
the AMI.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to. Tags
and attributes are copied along with the AMI. AMI copying takes time depending
on the size of the AMI, but will generally take many minutes.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to.
Tags and attributes are copied along with the AMI. AMI copying takes time
depending on the size of the AMI, but will generally take many minutes.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `associate_public_ip_address` (boolean) - If using a non-default VPC, public
IP addresses are not provided by default. If this is toggled, your new
instance will get a Public IP.
- `associate_public_ip_address` (boolean) - If using a non-default VPC, public
IP addresses are not provided by default. If this is toggled, your new
instance will get a Public IP.
- `availability_zone` (string) - Destination availability zone to launch
instance in. Leave this empty to allow Amazon to auto-assign.
- `availability_zone` (string) - Destination availability zone to launch
instance in. Leave this empty to allow Amazon to auto-assign.
- `enhanced_networking` (boolean) - Enable enhanced networking (SriovNetSupport)
on HVM-compatible AMIs. If true, add `ec2:ModifyInstanceAttribute` to your AWS
IAM policy.
- `enhanced_networking` (boolean) - Enable enhanced
networking (SriovNetSupport) on HVM-compatible AMIs. If true, add
`ec2:ModifyInstanceAttribute` to your AWS IAM policy.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `iam_instance_profile` (string) - The name of an [IAM instance
profile](http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html)
to launch the EC2 instance with.
- `iam_instance_profile` (string) - The name of an [IAM instance
profile](http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html)
to launch the EC2 instance with.
- `launch_block_device_mappings` (array of block device mappings) - Add the
block device mappings to the launch instance. The block device mappings are
the same as `ami_block_device_mappings` above.
- `launch_block_device_mappings` (array of block device mappings) - Add the
block device mappings to the launch instance. The block device mappings are
the same as `ami_block_device_mappings` above.
- `run_tags` (object of key/value strings) - Tags to apply to the instance that
is *launched* to create the AMI. These tags are *not* applied to the resulting
AMI unless they're duplicated in `tags`.
- `run_tags` (object of key/value strings) - Tags to apply to the instance
that is *launched* to create the AMI. These tags are *not* applied to the
resulting AMI unless they're duplicated in `tags`.
- `security_group_id` (string) - The ID (*not* the name) of the security group
to assign to the instance. By default this is not set and Packer will
automatically create a new temporary security group to allow SSH access. Note
that if this is specified, you must be sure the security group allows access
to the `ssh_port` given below.
- `security_group_id` (string) - The ID (*not* the name) of the security group
to assign to the instance. By default this is not set and Packer will
automatically create a new temporary security group to allow SSH access.
Note that if this is specified, you must be sure the security group allows
access to the `ssh_port` given below.
- `security_group_ids` (array of strings) - A list of security groups as
described above. Note that if this is specified, you must omit the
`security_group_id`.
- `security_group_ids` (array of strings) - A list of security groups as
described above. Note that if this is specified, you must omit the
`security_group_id`.
- `spot_price` (string) - The maximum hourly price to pay for a spot instance to
create the AMI. Spot instances are a type of instance that EC2 starts when the
current spot price is less than the maximum price you specify. Spot price will
be updated based on available spot instance capacity and current spot
instance requests. It may save you some costs. You can set this to "auto" for
Packer to automatically discover the best spot price.
- `spot_price` (string) - The maximum hourly price to pay for a spot instance
to create the AMI. Spot instances are a type of instance that EC2 starts
when the current spot price is less than the maximum price you specify. Spot
price will be updated based on available spot instance capacity and current
spot instance requests. It may save you some costs. You can set this to
"auto" for Packer to automatically discover the best spot price.
- `spot_price_auto_product` (string) - Required if `spot_price` is set
to "auto". This tells Packer what sort of AMI you're launching to find the
best spot price. This must be one of: `Linux/UNIX`, `SUSE Linux`, `Windows`,
`Linux/UNIX (Amazon VPC)`, `SUSE Linux (Amazon VPC)`, `Windows (Amazon VPC)`
- `spot_price_auto_product` (string) - Required if `spot_price` is set
to "auto". This tells Packer what sort of AMI you're launching to find the
best spot price. This must be one of: `Linux/UNIX`, `SUSE Linux`, `Windows`,
`Linux/UNIX (Amazon VPC)`, `SUSE Linux (Amazon VPC)`, `Windows (Amazon VPC)`
- `ssh_keypair_name` (string) - If specified, this is the key that will be used
for SSH with the machine. By default, this is blank, and Packer will generate
a temporary keypair. `ssh_private_key_file` must be specified with this.
- `ssh_keypair_name` (string) - If specified, this is the key that will be
used for SSH with the machine. By default, this is blank, and Packer will
generate a temporary keypair. `ssh_private_key_file` must be specified
with this.
- `ssh_private_ip` (boolean) - If true, then SSH will always use the private IP
if available.
- `ssh_private_ip` (boolean) - If true, then SSH will always use the private
IP if available.
- `subnet_id` (string) - If using VPC, the ID of the subnet, such as
"subnet-12345def", where Packer will launch the EC2 instance. This field is
required if you are using an non-default VPC.
- `subnet_id` (string) - If using VPC, the ID of the subnet, such as
"subnet-12345def", where Packer will launch the EC2 instance. This field is
required if you are using an non-default VPC.
- `tags` (object of key/value strings) - Tags applied to the AMI and
relevant snapshots.
- `tags` (object of key/value strings) - Tags applied to the AMI and
relevant snapshots.
- `temporary_key_pair_name` (string) - The name of the temporary keypair
to generate. By default, Packer generates a name with a UUID.
- `temporary_key_pair_name` (string) - The name of the temporary keypair
to generate. By default, Packer generates a name with a UUID.
- `token` (string) - The access token to use. This is different from the access
key and secret key. If you're not sure what this is, then you probably don't
need it. This will also be read from the `AWS_SECURITY_TOKEN`
environmental variable.
- `token` (string) - The access token to use. This is different from the
access key and secret key. If you're not sure what this is, then you
probably don't need it. This will also be read from the `AWS_SECURITY_TOKEN`
environmental variable.
- `user_data` (string) - User data to apply when launching the instance. Note
that you need to be careful about escaping characters due to the templates
being JSON. It is often more convenient to use `user_data_file`, instead.
- `user_data` (string) - User data to apply when launching the instance. Note
that you need to be careful about escaping characters due to the templates
being JSON. It is often more convenient to use `user_data_file`, instead.
- `user_data_file` (string) - Path to a file that will be used for the user data
when launching the instance.
- `user_data_file` (string) - Path to a file that will be used for the user
data when launching the instance.
- `vpc_id` (string) - If launching into a VPC subnet, Packer needs the VPC ID in
order to create a temporary security group within the VPC.
- `vpc_id` (string) - If launching into a VPC subnet, Packer needs the VPC ID
in order to create a temporary security group within the VPC.
- `windows_password_timeout` (string) - The timeout for waiting for a Windows
password for Windows instances. Defaults to 20 minutes. Example value: "10m"
- `windows_password_timeout` (string) - The timeout for waiting for a Windows
password for Windows instances. Defaults to 20 minutes. Example value: "10m"
## Basic Example
......
website/source/docs/builders/amazon-instance.html.markdown
View file @ d8e8f98b
......@@ -45,196 +45,199 @@ builder.
### Required:
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set.
- `access_key` (string) - The access key used to communicate with AWS. If not
specified, Packer will use the key from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_ACCESS_KEY_ID` or
`AWS_ACCESS_KEY` (in that order), if set.
- `account_id` (string) - Your AWS account ID. This is required for bundling
the AMI. This is *not the same* as the access key. You can find your account
ID in the security credentials page of your AWS account.
- `account_id` (string) - Your AWS account ID. This is required for bundling
the AMI. This is *not the same* as the access key. You can find your account
ID in the security credentials page of your AWS account.
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `ami_name` (string) - The name of the resulting AMI that will appear when
managing AMIs in the AWS console or via APIs. 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)
- `instance_type` (string) - The EC2 instance type to use while building the
AMI, such as "m1.small".
- `instance_type` (string) - The EC2 instance type to use while building the
AMI, such as "m1.small".
- `region` (string) - The name of the region, such as "us-east-1", in which to
launch the EC2 instance to create the AMI.
- `region` (string) - The name of the region, such as "us-east-1", in which to
launch the EC2 instance to create the AMI.
- `s3_bucket` (string) - The name of the S3 bucket to upload the AMI. This
bucket will be created if it doesn't exist.
- `s3_bucket` (string) - The name of the S3 bucket to upload the AMI. This
bucket will be created if it doesn't exist.
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set.
- `secret_key` (string) - The secret key used to communicate with AWS. If not
specified, Packer will use the secret from any
[credentials](http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
file or fall back to environment variables `AWS_SECRET_ACCESS_KEY` or
`AWS_SECRET_KEY` (in that order), if set.
- `source_ami` (string) - The initial AMI used as a base for the newly
created machine.
- `source_ami` (string) - The initial AMI used as a base for the newly
created machine.
- `ssh_username` (string) - The username to use in order to communicate over SSH
to the running machine.
- `ssh_username` (string) - The username to use in order to communicate over
SSH to the running machine.
- `x509_cert_path` (string) - The local path to a valid X509 certificate for
your AWS account. This is used for bundling the AMI. This X509 certificate
must be registered with your account from the security credentials page in the
AWS console.
- `x509_cert_path` (string) - The local path to a valid X509 certificate for
your AWS account. This is used for bundling the AMI. This X509 certificate
must be registered with your account from the security credentials page in
the AWS console.
- `x509_key_path` (string) - The local path to the private key for the X509
certificate specified by `x509_cert_path`. This is used for bundling the AMI.
- `x509_key_path` (string) - The local path to the private key for the X509
certificate specified by `x509_cert_path`. This is used for bundling
the AMI.
### Optional:
- `ami_block_device_mappings` (array of block device mappings) - Add the block
device mappings to the AMI. The block device mappings allow for keys:
- `ami_block_device_mappings` (array of block device mappings) - Add the block
device mappings to the AMI. The block device mappings allow for keys:
- `device_name` (string) - The device name exposed to the instance (for
- `device_name` (string) - The device name exposed to the instance (for
example, "/dev/sdh" or "xvdh")
- `virtual_name` (string) - The virtual device name. See the documentation on
- `virtual_name` (string) - The virtual device name. See the documentation on
[Block Device
Mapping](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_BlockDeviceMapping.html)
for more information
- `snapshot_id` (string) - The ID of the snapshot
- `volume_type` (string) - The volume type. gp2 for General Purpose (SSD)
- `snapshot_id` (string) - The ID of the snapshot
- `volume_type` (string) - The volume type. gp2 for General Purpose (SSD)
volumes, io1 for Provisioned IOPS (SSD) volumes, and standard for Magnetic
volumes
- `volume_size` (integer) - The size of the volume, in GiB. Required if not
- `volume_size` (integer) - The size of the volume, in GiB. Required if not
specifying a `snapshot_id`
- `delete_on_termination` (boolean) - Indicates whether the EBS volume is
- `delete_on_termination` (boolean) - Indicates whether the EBS volume is
deleted on instance termination
- `encrypted` (boolean) - Indicates whether to encrypt the volume or not
- `no_device` (boolean) - Suppresses the specified device included in the
- `encrypted` (boolean) - Indicates whether to encrypt the volume or not
- `no_device` (boolean) - Suppresses the specified device included in the
block device mapping of the AMI
- `iops` (integer) - The number of I/O operations per second (IOPS) that the
- `iops` (integer) - The number of I/O operations per second (IOPS) that the
volume supports. See the documentation on
[IOPs](http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_EbsBlockDevice.html)
for more information
- `ami_description` (string) - The description to set for the resulting AMI(s).
By default this description is empty.
- `ami_description` (string) - The description to set for the
resulting AMI(s). By default this description is empty.
- `ami_groups` (array of strings) - A list of groups that have access to launch
the resulting AMI(s). By default no groups have permission to launch the AMI.
`all` will make the AMI publicly accessible. AWS currently doesn't accept any
value other than "all".
- `ami_groups` (array of strings) - A list of groups that have access to
launch the resulting AMI(s). By default no groups have permission to launch
the AMI. `all` will make the AMI publicly accessible. AWS currently doesn't
accept any value other than "all".
- `ami_product_codes` (array of strings) - A list of product codes to
associate with the AMI. By default no product codes are associated with
the AMI.
- `ami_product_codes` (array of strings) - A list of product codes to associate
with the AMI. By default no product codes are associated with the AMI.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to.
Tags and attributes are copied along with the AMI. AMI copying takes time
depending on the size of the AMI, but will generally take many minutes.
- `ami_regions` (array of strings) - A list of regions to copy the AMI to. Tags
and attributes are copied along with the AMI. AMI copying takes time depending
on the size of the AMI, but will generally take many minutes.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `ami_users` (array of strings) - A list of account IDs that have access to
launch the resulting AMI(s). By default no additional users other than the
user creating the AMI has permissions to launch it.
- `ami_virtualization_type` (string) - The type of virtualization for the AMI
you are building. This option is required to register HVM images. Can be
"paravirtual" (default) or "hvm".
- `ami_virtualization_type` (string) - The type of virtualization for the AMI
you are building. This option is required to register HVM images. Can be
"paravirtual" (default) or "hvm".
- `associate_public_ip_address` (boolean) - If using a non-default VPC, public
IP addresses are not provided by default. If this is toggled, your new
instance will get a Public IP.
- `associate_public_ip_address` (boolean) - If using a non-default VPC, public
IP addresses are not provided by default. If this is toggled, your new
instance will get a Public IP.
- `availability_zone` (string) - Destination availability zone to launch
instance in. Leave this empty to allow Amazon to auto-assign.
- `availability_zone` (string) - Destination availability zone to launch
instance in. Leave this empty to allow Amazon to auto-assign.
- `bundle_destination` (string) - The directory on the running instance where
the bundled AMI will be saved prior to uploading. By default this is "/tmp".
This directory must exist and be writable.
- `bundle_destination` (string) - The directory on the running instance where
the bundled AMI will be saved prior to uploading. By default this is "/tmp".
This directory must exist and be writable.
- `bundle_prefix` (string) - The prefix for files created from bundling the
root volume. By default this is "image-{{timestamp}}". The `timestamp`
variable should be used to make sure this is unique, otherwise it can
collide with other created AMIs by Packer in your account.
- `bundle_prefix` (string) - The prefix for files created from bundling the
root volume. By default this is "image-{{timestamp}}". The `timestamp`
variable should be used to make sure this is unique, otherwise it can collide
with other created AMIs by Packer in your account.
- `bundle_upload_command` (string) - The command to use to upload the
bundled volume. See the "custom bundle commands" section below for
more information.
- `bundle_upload_command` (string) - The command to use to upload the
bundled volume. See the "custom bundle commands" section below for
more information.
- `bundle_vol_command` (string) - The command to use to bundle the volume. See
the "custom bundle commands" section below for more information.
- `bundle_vol_command` (string) - The command to use to bundle the volume. See
the "custom bundle commands" section below for more information.
- `enhanced_networking` (boolean) - Enable enhanced
networking (SriovNetSupport) on HVM-compatible AMIs. If true, add
`ec2:ModifyInstanceAttribute` to your AWS IAM policy.
- `enhanced_networking` (boolean) - Enable enhanced networking (SriovNetSupport)
on HVM-compatible AMIs. If true, add `ec2:ModifyInstanceAttribute` to your AWS
IAM policy.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `force_deregister` (boolean) - Force Packer to first deregister an existing
AMI if one with the same name already exists. Default `false`.
- `iam_instance_profile` (string) - The name of an [IAM instance
profile](http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html)
to launch the EC2 instance with.
- `iam_instance_profile` (string) - The name of an [IAM instance
profile](http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html)
to launch the EC2 instance with.
- `launch_block_device_mappings` (array of block device mappings) - Add the
block device mappings to the launch instance. The block device mappings are
the same as `ami_block_device_mappings` above.
- `launch_block_device_mappings` (array of block device mappings) - Add the
block device mappings to the launch instance. The block device mappings are
the same as `ami_block_device_mappings` above.
- `run_tags` (object of key/value strings) - Tags to apply to the instance
that is *launched* to create the AMI. These tags are *not* applied to the
resulting AMI unless they're duplicated in `tags`.
- `run_tags` (object of key/value strings) - Tags to apply to the instance that
is *launched* to create the AMI. These tags are *not* applied to the resulting
AMI unless they're duplicated in `tags`.
- `security_group_id` (string) - The ID (*not* the name) of the security group
to assign to the instance. By default this is not set and Packer will
automatically create a new temporary security group to allow SSH access.
Note that if this is specified, you must be sure the security group allows
access to the `ssh_port` given below.
- `security_group_id` (string) - The ID (*not* the name) of the security group
to assign to the instance. By default this is not set and Packer will
automatically create a new temporary security group to allow SSH access. Note
that if this is specified, you must be sure the security group allows access
to the `ssh_port` given below.
- `security_group_ids` (array of strings) - A list of security groups as
described above. Note that if this is specified, you must omit the
`security_group_id`.
- `security_group_ids` (array of strings) - A list of security groups as
described above. Note that if this is specified, you must omit the
`security_group_id`.
- `spot_price` (string) - The maximum hourly price to launch a spot instance
to create the AMI. It is a type of instances that EC2 starts when the
maximum price that you specify exceeds the current spot price. Spot price
will be updated based on available spot instance capacity and current spot
Instance requests. It may save you some costs. You can set this to "auto"
for Packer to automatically discover the best spot price.
- `spot_price` (string) - The maximum hourly price to launch a spot instance to
create the AMI. It is a type of instances that EC2 starts when the maximum
price that you specify exceeds the current spot price. Spot price will be
updated based on available spot instance capacity and current spot
Instance requests. It may save you some costs. You can set this to "auto" for
Packer to automatically discover the best spot price.
- `spot_price_auto_product` (string) - Required if `spot_price` is set
to "auto". This tells Packer what sort of AMI you're launching to find the
best spot price. This must be one of: `Linux/UNIX`, `SUSE Linux`, `Windows`,
`Linux/UNIX (Amazon VPC)`, `SUSE Linux (Amazon VPC)`, `Windows (Amazon VPC)`
- `spot_price_auto_product` (string) - Required if `spot_price` is set
to "auto". This tells Packer what sort of AMI you're launching to find the
best spot price. This must be one of: `Linux/UNIX`, `SUSE Linux`, `Windows`,
`Linux/UNIX (Amazon VPC)`, `SUSE Linux (Amazon VPC)`, `Windows (Amazon VPC)`
- `ssh_keypair_name` (string) - If specified, this is the key that will be
used for SSH with the machine. By default, this is blank, and Packer will
generate a temporary keypair. `ssh_private_key_file` must be specified
with this.
- `ssh_keypair_name` (string) - If specified, this is the key that will be used
for SSH with the machine. By default, this is blank, and Packer will generate
a temporary keypair. `ssh_private_key_file` must be specified with this.
- `ssh_private_ip` (boolean) - If true, then SSH will always use the private
IP if available.
- `ssh_private_ip` (boolean) - If true, then SSH will always use the private IP
if available.
- `subnet_id` (string) - If using VPC, the ID of the subnet, such as
"subnet-12345def", where Packer will launch the EC2 instance. This field is
required if you are using an non-default VPC.
- `subnet_id` (string) - If using VPC, the ID of the subnet, such as
"subnet-12345def", where Packer will launch the EC2 instance. This field is
required if you are using an non-default VPC.
- `tags` (object of key/value strings) - Tags applied to the AMI.
- `tags` (object of key/value strings) - Tags applied to the AMI.
- `temporary_key_pair_name` (string) - The name of the temporary keypair
to generate. By default, Packer generates a name with a UUID.
- `temporary_key_pair_name` (string) - The name of the temporary keypair
to generate. By default, Packer generates a name with a UUID.
- `user_data` (string) - User data to apply when launching the instance. Note
that you need to be careful about escaping characters due to the templates
being JSON. It is often more convenient to use `user_data_file`, instead.
- `user_data` (string) - User data to apply when launching the instance. Note
that you need to be careful about escaping characters due to the templates
being JSON. It is often more convenient to use `user_data_file`, instead.
- `user_data_file` (string) - Path to a file that will be used for the user
data when launching the instance.
- `user_data_file` (string) - Path to a file that will be used for the user data
when launching the instance.
- `vpc_id` (string) - If launching into a VPC subnet, Packer needs the VPC ID
in order to create a temporary security group within the VPC.
- `vpc_id` (string) - If launching into a VPC subnet, Packer needs the VPC ID in
order to create a temporary security group within the VPC.
- `x509_upload_path` (string) - The path on the remote machine where the X509
certificate will be uploaded. This path must already exist and be writable.
X509 certificates are uploaded after provisioning is run, so it is perfectly
okay to create this directory as part of the provisioning process.
- `x509_upload_path` (string) - The path on the remote machine where the X509
certificate will be uploaded. This path must already exist and be writable.
X509 certificates are uploaded after provisioning is run, so it is perfectly
okay to create this directory as part of the provisioning process.
- `windows_password_timeout` (string) - The timeout for waiting for a Windows
password for Windows instances. Defaults to 20 minutes. Example value: "10m"
- `windows_password_timeout` (string) - The timeout for waiting for a Windows
password for Windows instances. Defaults to 20 minutes. Example value: "10m"
## Basic Example
......
website/source/docs/builders/amazon.html.markdown
View file @ d8e8f98b
......@@ -12,20 +12,21 @@ 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:
- [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
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.
- [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.
-&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
......
website/source/docs/builders/digitalocean.html.markdown
View file @ d8e8f98b
......@@ -34,41 +34,43 @@ 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
for the droplet being created. This defaults to `false`, or not enabled.
- `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
......
website/source/docs/builders/docker.html.markdown
View file @ d8e8f98b
......@@ -68,42 +68,42 @@ builder.
### Required:
- `commit` (boolean) - If true, the container will be committed to an image
rather than exported. This cannot be set if `export_path` is set.
- `commit` (boolean) - If true, the container will be committed to an image
rather than exported. This cannot be set if `export_path` is set.
- `export_path` (string) - The path where the final container will be exported
as a tar file. This cannot be set if `commit` is set to true.
- `export_path` (string) - The path where the final container will be exported
as a tar file. This cannot be set if `commit` is set to true.
- `image` (string) - The base image for the Docker container that will
be started. This image will be pulled from the Docker registry if it doesn't
already exist.
- `image` (string) - The base image for the Docker container that will
be started. This image will be pulled from the Docker registry if it doesn't
already exist.
### Optional:
- `login` (boolean) - Defaults to false. If true, the builder will login in
order to pull the image. The builder only logs in for the duration of
the pull. It always logs out afterwards.
- `login` (boolean) - Defaults to false. If true, the builder will login in
order to pull the image. The builder only logs in for the duration of
the pull. It always logs out afterwards.
- `login_email` (string) - The email to use to authenticate to login.
- `login_email` (string) - The email to use to authenticate to login.
- `login_username` (string) - The username to use to authenticate to login.
- `login_username` (string) - The username to use to authenticate to login.
- `login_password` (string) - The password to use to authenticate to login.
- `login_password` (string) - The password to use to authenticate to login.
- `login_server` (string) - The server address to login to.
- `login_server` (string) - The server address to login to.
- `pull` (boolean) - If true, the configured image will be pulled using
`docker pull` prior to use. Otherwise, it is assumed the image already exists
and can be used. This defaults to true if not set.
- `pull` (boolean) - If true, the configured image will be pulled using
`docker pull` prior to use. Otherwise, it is assumed the image already
exists and can be used. This defaults to true if not set.
- `run_command` (array of strings) - An array of arguments to pass to
`docker run` in order to run the container. By default this is set to
`["-d", "-i", "-t", "{{.Image}}", "/bin/bash"]`. As you can see, you have a
couple template variables to customize, as well.
- `run_command` (array of strings) - An array of arguments to pass to
`docker run` in order to run the container. By default this is set to
`["-d", "-i", "-t", "{{.Image}}", "/bin/bash"]`. As you can see, you have a
couple template variables to customize, as well.
- `volumes` (map of strings to strings) - A mapping of additional volumes to
mount into this container. The key of the object is the host path, the value
is the container path.
- `volumes` (map of strings to strings) - A mapping of additional volumes to
mount into this container. The key of the object is the host path, the value
is the container path.
## Using the Artifact: Export
......@@ -226,11 +226,11 @@ Dockerfiles have some additional features that Packer doesn't support which are
able to be worked around. Many of these features will be automated by Packer in
the future:
- Dockerfiles will snapshot the container at each step, allowing you to go back
to any step in the history of building. Packer doesn't do this yet, but
inter-step snapshotting is on the way.
- Dockerfiles will snapshot the container at each step, allowing you to go
back to any step in the history of building. Packer doesn't do this yet, but
inter-step snapshotting is on the way.
- Dockerfiles can contain information such as exposed ports, shared volumes, and
other metadata. Packer builds a raw Docker container image that has none of
this metadata. You can pass in much of this metadata at runtime with
`docker run`.
- Dockerfiles can contain information such as exposed ports, shared volumes,
and other metadata. Packer builds a raw Docker container image that has none
of this metadata. You can pass in much of this metadata at runtime with
`docker run`.
website/source/docs/builders/openstack.html.markdown
View file @ d8e8f98b
......@@ -38,67 +38,67 @@ builder.
### Required:
- `flavor` (string) - The ID, name, or full URL for the desired flavor for the
server to be created.
- `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
installations require this.
- `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.
`use_floating_ip` must also be set to true for this to have an affect.
- `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
over an insecure connection. By default this is false.
- `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
the instance. Defaults to false.
- `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 to assign the machine an IP address before connecting via SSH.
Defaults to false.
- `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
......@@ -138,7 +138,7 @@ 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`
website/source/docs/builders/parallels-iso.html.markdown
View file @ d8e8f98b
......@@ -56,146 +56,149 @@ builder.
### Required:
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO files
are so large, this is required and Packer will verify it prior to booting a
virtual machine with the ISO attached. The type of the checksum is specified
with `iso_checksum_type`, documented below.
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO
files are so large, this is required and Packer will verify it prior to
booting a virtual machine with the ISO attached. The type of the checksum is
specified with `iso_checksum_type`, documented below.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_url` (string) - A URL to the ISO containing the installation image. This
URL can be either an HTTP URL or a file URL (or path to a file). If this is an
HTTP URL, Packer will download it and cache it between runs.
- `iso_url` (string) - A URL to the ISO containing the installation image.
This URL can be either an HTTP URL or a file URL (or path to a file). If
this is an HTTP URL, Packer will download it and cache it between runs.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
- `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
install into the VM. Valid values are "win", "lin", "mac", "os2" and "other".
This can be omitted only if `parallels_tools_mode` is "disable".
- `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
install into the VM. Valid values are "win", "lin", "mac", "os2"
and "other". This can be omitted only if `parallels_tools_mode`
is "disable".
### Optional:
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create for
the VM. By default, this is 40000 (about 40 GB).
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `guest_os_type` (string) - The guest OS type being installed. By default this
is "other", but you can get *dramatic* performance improvements by setting
this to the proper value. To view all available values for this run
`prlctl create x --distribution list`. Setting the correct value hints to
Parallels Desktop how to optimize the virtual hardware to work best with that
operating system.
- `hard_drive_interface` (string) - The type of controller that the hard drives
are attached to, defaults to "sata". Valid options are "sata", "ide",
and "scsi".
- `host_interfaces` (array of strings) - A list of which interfaces on the host
should be searched for a IP address. The first IP address found on one of
these will be used as `{{ .HTTPIP }}` in the `boot_command`. Defaults to
\["en0", "en1", "en2", "en3", "en4", "en5", "en6", "en7", "en8", "en9",
"ppp0", "ppp1", "ppp2"\].
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download. Packer
will try these in order. If anything goes wrong attempting to download or
while downloading a single URL, it will move on to the next. All URLs must
point to the same file (same checksum). By default this is empty and `iso_url`
is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `parallels_tools_guest_path` (string) - The path in the virtual machine to
upload Parallels Tools. This only takes effect if `parallels_tools_mode`
is "upload". This is a [configuration
template](/docs/templates/configuration-templates.html) that has a single
valid variable: `Flavor`, which will be the value of `parallels_tools_flavor`.
By default this is "prl-tools-{{.Flavor}}.iso" which should upload into the
login directory of the user.
- `parallels_tools_mode` (string) - The method by which Parallels Tools are made
available to the guest for installation. Valid options are "upload", "attach",
or "disable". If the mode is "attach" the Parallels Tools ISO will be attached
as a CD device to the virtual machine. If the mode is "upload" the Parallels
Tools ISO will be uploaded to the path specified by
`parallels_tools_guest_path`. The default value is "upload".
- `prlctl` (array of array of strings) - Custom `prlctl` commands to execute in
order to further customize the virtual machine being created. The value of
this is an array of commands to execute. The commands are executed in the
order defined in the template. For each command, the command is defined itself
as an array of strings, where each string represents a single argument on the
command-line to `prlctl` (but excluding `prlctl` itself). Each arg is treated
as a [configuration template](/docs/templates/configuration-templates.html),
where the `Name` variable is replaced with the VM name. More details on how to
use `prlctl` are below.
- `prlctl_post` (array of array of strings) - Identical to `prlctl`, except that
it is run after the virtual machine is shutdown, and before the virtual
machine is exported.
- `prlctl_version_file` (string) - The path within the virtual machine to upload
a file that contains the `prlctl` version that was used to create the machine.
This information can be useful for provisioning. By default this is
".prlctl\_version", which will generally upload it into the home directory.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `vm_name` (string) - This is the name of the PVM directory for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create
for the VM. By default, this is 40000 (about 40 GB).
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `guest_os_type` (string) - The guest OS type being installed. By default
this is "other", but you can get *dramatic* performance improvements by
setting this to the proper value. To view all available values for this run
`prlctl create x --distribution list`. Setting the correct value hints to
Parallels Desktop how to optimize the virtual hardware to work best with
that operating system.
- `hard_drive_interface` (string) - The type of controller that the hard
drives are attached to, defaults to "sata". Valid options are "sata", "ide",
and "scsi".
- `host_interfaces` (array of strings) - A list of which interfaces on the
host should be searched for a IP address. The first IP address found on one
of these will be used as `{{ .HTTPIP }}` in the `boot_command`. Defaults to
\["en0", "en1", "en2", "en3", "en4", "en5", "en6", "en7", "en8", "en9",
"ppp0", "ppp1", "ppp2"\].
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download.
Packer will try these in order. If anything goes wrong attempting to
download or while downloading a single URL, it will move on to the next. All
URLs must point to the same file (same checksum). By default this is empty
and `iso_url` is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `parallels_tools_guest_path` (string) - The path in the virtual machine to
upload Parallels Tools. This only takes effect if `parallels_tools_mode`
is "upload". This is a [configuration
template](/docs/templates/configuration-templates.html) that has a single
valid variable: `Flavor`, which will be the value of
`parallels_tools_flavor`. By default this is "prl-tools-{{.Flavor}}.iso"
which should upload into the login directory of the user.
- `parallels_tools_mode` (string) - The method by which Parallels Tools are
made available to the guest for installation. Valid options are "upload",
"attach", or "disable". If the mode is "attach" the Parallels Tools ISO will
be attached as a CD device to the virtual machine. If the mode is "upload"
the Parallels Tools ISO will be uploaded to the path specified by
`parallels_tools_guest_path`. The default value is "upload".
- `prlctl` (array of array of strings) - Custom `prlctl` commands to execute
in order to further customize the virtual machine being created. The value
of this is an array of commands to execute. The commands are executed in the
order defined in the template. For each command, the command is defined
itself as an array of strings, where each string represents a single
argument on the command-line to `prlctl` (but excluding `prlctl` itself).
Each arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use `prlctl`
are below.
- `prlctl_post` (array of array of strings) - Identical to `prlctl`, except
that it is run after the virtual machine is shutdown, and before the virtual
machine is exported.
- `prlctl_version_file` (string) - The path within the virtual machine to
upload a file that contains the `prlctl` version that was used to create
the machine. This information can be useful for provisioning. By default
this is ".prlctl\_version", which will generally upload it into the
home directory.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `vm_name` (string) - This is the name of the PVM directory for the new
virtual machine, without the file extension. By default this is
"packer-BUILDNAME", where "BUILDNAME" is the name of the build.
## Boot Command
......@@ -214,40 +217,40 @@ simulating a human actually typing the keyboard. There are a set of special keys
available. If these are in your boot command, they will be replaced by the
proper key:
- `<bs>` - Backspace
- `<bs>` - Backspace
- `<del>` - Delete
- `<del>` - Delete
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<esc>` - Simulates pressing the escape key.
- `<esc>` - Simulates pressing the escape key.
- `<tab>` - Simulates pressing the tab key.
- `<tab>` - Simulates pressing the tab key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<spacebar>` - Simulates pressing the spacebar.
- `<spacebar>` - Simulates pressing the spacebar.
- `<insert>` - Simulates pressing the insert key.
- `<insert>` - Simulates pressing the insert key.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before sending
any additional keys. This is useful if you have to generally wait for the UI
to update before typing more.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before
sending any additional keys. This is useful if you have to generally wait
for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
available variables are:
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server that
is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
that is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
Example boot command. This is actually a working boot command used to start an
Ubuntu 12.04 installer:
......
website/source/docs/builders/parallels-pvm.html.markdown
View file @ d8e8f98b
......@@ -53,96 +53,99 @@ builder.
### Required:
- `source_path` (string) - The path to a PVM directory that acts as the source
of this build.
- `source_path` (string) - The path to a PVM directory that acts as the source
of this build.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
- `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
install into the VM. Valid values are "win", "lin", "mac", "os2" and "other".
This can be omitted only if `parallels_tools_mode` is "disable".
- `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
install into the VM. Valid values are "win", "lin", "mac", "os2"
and "other". This can be omitted only if `parallels_tools_mode`
is "disable".
### Optional:
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `floppy_files` (array of strings) - A list of files to put onto a floppy disk
that is attached when the VM is booted for the first time. This is most useful
for unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default no floppy will be attached. The files listed in
this configuration will all be put into the root directory of the floppy disk;
sub-directories are not supported.
- `reassign_mac` (boolean) - If this is "false" the MAC address of the first NIC
will reused when imported else a new MAC address will be generated
by Parallels. Defaults to "false".
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `parallels_tools_guest_path` (string) - The path in the VM to upload
Parallels Tools. This only takes effect if `parallels_tools_mode` is "upload".
This is a [configuration
template](/docs/templates/configuration-templates.html) that has a single
valid variable: `Flavor`, which will be the value of `parallels_tools_flavor`.
By default this is "prl-tools-{{.Flavor}}.iso" which should upload into the
login directory of the user.
- `parallels_tools_mode` (string) - The method by which Parallels Tools are made
available to the guest for installation. Valid options are "upload", "attach",
or "disable". If the mode is "attach" the Parallels Tools ISO will be attached
as a CD device to the virtual machine. If the mode is "upload" the Parallels
Tools ISO will be uploaded to the path specified by
`parallels_tools_guest_path`. The default value is "upload".
- `prlctl` (array of array of strings) - Custom `prlctl` commands to execute in
order to further customize the virtual machine being created. The value of
this is an array of commands to execute. The commands are executed in the
order defined in the template. For each command, the command is defined itself
as an array of strings, where each string represents a single argument on the
command-line to `prlctl` (but excluding `prlctl` itself). Each arg is treated
as a [configuration template](/docs/templates/configuration-templates.html),
where the `Name` variable is replaced with the VM name. More details on how to
use `prlctl` are below.
- `prlctl_post` (array of array of strings) - Identical to `prlctl`, except that
it is run after the virtual machine is shutdown, and before the virtual
machine is exported.
- `prlctl_version_file` (string) - The path within the virtual machine to upload
a file that contains the `prlctl` version that was used to create the machine.
This information can be useful for provisioning. By default this is
".prlctl\_version", which will generally upload it into the home directory.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `vm_name` (string) - This is the name of the virtual machine when it is
imported as well as the name of the PVM directory when the virtual machine
is exported. By default this is "packer-BUILDNAME", where "BUILDNAME" is the
name of the build.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `floppy_files` (array of strings) - A list of files to put onto a floppy
disk that is attached when the VM is booted for the first time. This is most
useful for unattended Windows installs, which look for an `Autounattend.xml`
file on removable media. By default no floppy will be attached. The files
listed in this configuration will all be put into the root directory of the
floppy disk; sub-directories are not supported.
- `reassign_mac` (boolean) - If this is "false" the MAC address of the first
NIC will reused when imported else a new MAC address will be generated
by Parallels. Defaults to "false".
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `parallels_tools_guest_path` (string) - The path in the VM to upload
Parallels Tools. This only takes effect if `parallels_tools_mode`
is "upload". This is a [configuration
template](/docs/templates/configuration-templates.html) that has a single
valid variable: `Flavor`, which will be the value of
`parallels_tools_flavor`. By default this is "prl-tools-{{.Flavor}}.iso"
which should upload into the login directory of the user.
- `parallels_tools_mode` (string) - The method by which Parallels Tools are
made available to the guest for installation. Valid options are "upload",
"attach", or "disable". If the mode is "attach" the Parallels Tools ISO will
be attached as a CD device to the virtual machine. If the mode is "upload"
the Parallels Tools ISO will be uploaded to the path specified by
`parallels_tools_guest_path`. The default value is "upload".
- `prlctl` (array of array of strings) - Custom `prlctl` commands to execute
in order to further customize the virtual machine being created. The value
of this is an array of commands to execute. The commands are executed in the
order defined in the template. For each command, the command is defined
itself as an array of strings, where each string represents a single
argument on the command-line to `prlctl` (but excluding `prlctl` itself).
Each arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use `prlctl`
are below.
- `prlctl_post` (array of array of strings) - Identical to `prlctl`, except
that it is run after the virtual machine is shutdown, and before the virtual
machine is exported.
- `prlctl_version_file` (string) - The path within the virtual machine to
upload a file that contains the `prlctl` version that was used to create
the machine. This information can be useful for provisioning. By default
this is ".prlctl\_version", which will generally upload it into the
home directory.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `vm_name` (string) - This is the name of the virtual machine when it is
imported as well as the name of the PVM directory when the virtual machine
is exported. By default this is "packer-BUILDNAME", where "BUILDNAME" is the
name of the build.
## Parallels Tools
......@@ -168,31 +171,31 @@ simulating a human actually typing the keyboard. There are a set of special keys
available. If these are in your boot command, they will be replaced by the
proper key:
- `<bs>` - Backspace
- `<bs>` - Backspace
- `<del>` - Delete
- `<del>` - Delete
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<esc>` - Simulates pressing the escape key.
- `<esc>` - Simulates pressing the escape key.
- `<tab>` - Simulates pressing the tab key.
- `<tab>` - Simulates pressing the tab key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<spacebar>` - Simulates pressing the spacebar.
- `<spacebar>` - Simulates pressing the spacebar.
- `<insert>` - Simulates pressing the insert key.
- `<insert>` - Simulates pressing the insert key.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before sending
any additional keys. This is useful if you have to generally wait for the UI
to update before typing more.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before
sending any additional keys. This is useful if you have to generally wait
for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
......
website/source/docs/builders/parallels.html.markdown
View file @ d8e8f98b
......@@ -16,16 +16,16 @@ 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-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.
- [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
......
website/source/docs/builders/qemu.html.markdown
View file @ d8e8f98b
......@@ -81,124 +81,124 @@ builder.
### Required:
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO files
are so large, this is required and Packer will verify it prior to booting a
virtual machine with the ISO attached. The type of the checksum is specified
with `iso_checksum_type`, documented below.
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO
files are so large, this is required and Packer will verify it prior to
booting a virtual machine with the ISO attached. The type of the checksum is
specified with `iso_checksum_type`, documented below.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "md5", "sha1", "sha256", or
"sha512" currently.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "md5", "sha1", "sha256", or
"sha512" currently.
- `iso_url` (string) - A URL to the ISO containing the installation image. This
URL can be either an HTTP URL or a file URL (or path to a file). If this is an
HTTP URL, Packer will download it and cache it between runs.
- `iso_url` (string) - A URL to the ISO containing the installation image.
This URL can be either an HTTP URL or a file URL (or path to a file). If
this is an HTTP URL, Packer will download it and cache it between runs.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
### Optional:
- `accelerator` (string) - The accelerator type to use when running the VM. This
may have a value of either "none", "kvm", "tcg", or "xen" and you must have
that support in on the machine on which you run the builder. By default "kvm"
is used.
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `disk_cache` (string) - The cache mode to use for disk. Allowed values include
any of "writethrough", "writeback", "none", "unsafe" or "directsync". By
default, this is set to "writeback".
- `disk_discard` (string) - The discard mode to use for disk. Allowed values
include any of "unmap" or "ignore". By default, this is set to "ignore".
- `disk_image` (boolean) - Packer defaults to building from an ISO file, this
parameter controls whether the ISO URL supplied is actually a bootable
QEMU image. When this value is set to true, the machine will clone the source,
resize it according to `disk_size` and boot the image.
- `disk_interface` (string) - The interface to use for the disk. Allowed values
include any of "ide," "scsi" or "virtio." Note also that any boot commands or
kickstart type scripts must have proper adjustments for resulting
device names. The Qemu builder uses "virtio" by default.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create for
the VM. By default, this is 40000 (about 40 GB).
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `format` (string) - Either "qcow2" or "raw", this specifies the output format
of the virtual machine image. This defaults to "qcow2".
- `headless` (boolean) - Packer defaults to building QEMU virtual machines by
launching a GUI that shows the console of the machine being built. When this
value is set to true, the machine will start without a console.
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download. Packer
will try these in order. If anything goes wrong attempting to download or
while downloading a single URL, it will move on to the next. All URLs must
point to the same file (same checksum). By default this is empty and `iso_url`
is used. Only one of `iso_url` or `iso_urls` can be specified.
- `machine_type` (string) - The type of machine emulation to use. Run your qemu
binary with the flags `-machine help` to list available types for your system.
This defaults to "pc".
- `net_device` (string) - The driver to use for the network interface. Allowed
values "ne2k\_pci," "i82551," "i82557b," "i82559er," "rtl8139," "e1000,"
"pcnet" or "virtio." The Qemu builder uses "virtio" by default.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `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 platforms. For example "qemu-kvm", or "qemu-system-i386" may be a better
choice for some systems.
- `qemuargs` (array of array of strings) - Allows complete control over the qemu
command line (though not, at this time, qemu-img). Each array of strings makes
up a command line switch that overrides matching default switch/value pairs.
Any value specified as an empty string is ignored. All values after the switch
are concatenated with no separator.
- `accelerator` (string) - The accelerator type to use when running the VM.
This may have a value of either "none", "kvm", "tcg", or "xen" and you must
have that support in on the machine on which you run the builder. By default
"kvm" is used.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `disk_cache` (string) - The cache mode to use for disk. Allowed values
include any of "writethrough", "writeback", "none", "unsafe"
or "directsync". By default, this is set to "writeback".
- `disk_discard` (string) - The discard mode to use for disk. Allowed values
include any of "unmap" or "ignore". By default, this is set to "ignore".
- `disk_image` (boolean) - Packer defaults to building from an ISO file, this
parameter controls whether the ISO URL supplied is actually a bootable
QEMU image. When this value is set to true, the machine will clone the
source, resize it according to `disk_size` and boot the image.
- `disk_interface` (string) - The interface to use for the disk. Allowed
values include any of "ide," "scsi" or "virtio." Note also that any boot
commands or kickstart type scripts must have proper adjustments for
resulting device names. The Qemu builder uses "virtio" by default.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create
for the VM. By default, this is 40000 (about 40 GB).
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `format` (string) - Either "qcow2" or "raw", this specifies the output
format of the virtual machine image. This defaults to "qcow2".
- `headless` (boolean) - Packer defaults to building QEMU virtual machines by
launching a GUI that shows the console of the machine being built. When this
value is set to true, the machine will start without a console.
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download.
Packer will try these in order. If anything goes wrong attempting to
download or while downloading a single URL, it will move on to the next. All
URLs must point to the same file (same checksum). By default this is empty
and `iso_url` is used. Only one of `iso_url` or `iso_urls` can be specified.
- `machine_type` (string) - The type of machine emulation to use. Run your
qemu binary with the flags `-machine help` to list available types for
your system. This defaults to "pc".
- `net_device` (string) - The driver to use for the network interface. Allowed
values "ne2k\_pci," "i82551," "i82557b," "i82559er," "rtl8139," "e1000,"
"pcnet" or "virtio." The Qemu builder uses "virtio" by default.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `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 platforms. For example "qemu-kvm", or "qemu-system-i386" may be a
better choice for some systems.
- `qemuargs` (array of array of strings) - Allows complete control over the
qemu command line (though not, at this time, qemu-img). Each array of
strings makes up a command line switch that overrides matching default
switch/value pairs. Any value specified as an empty string is ignored. All
values after the switch are concatenated with no separator.
\~&gt; **Warning:** The qemu command line allows extreme flexibility, so beware
of conflicting arguments causing failures of your run. For instance, using
......@@ -207,7 +207,7 @@ 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:
The following shows a sample usage:
``` {.javascript}
// ...
......@@ -225,34 +225,35 @@ command. The arguments are all printed for review.
// ...
```
would produce the following (not including other defaults supplied by the builder and not otherwise conflicting with the qemuargs):
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>
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded to
the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `vm_name` (string) - This is the name of the image (QCOW2 or IMG) file for the
new virtual machine, without the file extension. By default this is
"packer-BUILDNAME", where "BUILDNAME" is the name of the build.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port to
use for the VNC port on the host machine which is forwarded to the VNC port on
the guest machine. Because Packer often runs in parallel, Packer will choose a
randomly available port in this range to use as the host port.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded
to the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `vm_name` (string) - This is the name of the image (QCOW2 or IMG) file for
the new virtual machine, without the file extension. By default this is
"packer-BUILDNAME", where "BUILDNAME" is the name of the build.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port
to use for the VNC port on the host machine which is forwarded to the VNC
port on the guest machine. Because Packer often runs in parallel, Packer
will choose a randomly available port in this range to use as the host port.
## Boot Command
......@@ -270,40 +271,40 @@ machine, simulating a human actually typing the keyboard. There are a set of
special keys available. If these are in your boot command, they will be replaced
by the proper key:
- `<bs>` - Backspace
- `<bs>` - Backspace
- `<del>` - Delete
- `<del>` - Delete
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<esc>` - Simulates pressing the escape key.
- `<esc>` - Simulates pressing the escape key.
- `<tab>` - Simulates pressing the tab key.
- `<tab>` - Simulates pressing the tab key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<spacebar>` - Simulates pressing the spacebar.
- `<spacebar>` - Simulates pressing the spacebar.
- `<insert>` - Simulates pressing the insert key.
- `<insert>` - Simulates pressing the insert key.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before sending
any additional keys. This is useful if you have to generally wait for the UI
to update before typing more.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before
sending any additional keys. This is useful if you have to generally wait
for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
available variables are:
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server that
is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
that is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
Example boot command. This is actually a working boot command used to start an
CentOS 6.4 installer:
......
website/source/docs/builders/virtualbox-iso.html.markdown
View file @ d8e8f98b
......@@ -54,177 +54,179 @@ builder.
### Required:
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO files
are so large, this is required and Packer will verify it prior to booting a
virtual machine with the ISO attached. The type of the checksum is specified
with `iso_checksum_type`, documented below.
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO
files are so large, this is required and Packer will verify it prior to
booting a virtual machine with the ISO attached. The type of the checksum is
specified with `iso_checksum_type`, documented below.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_url` (string) - A URL to the ISO containing the installation image. This
URL can be either an HTTP URL or a file URL (or path to a file). If this is an
HTTP URL, Packer will download it and cache it between runs.
- `iso_url` (string) - A URL to the ISO containing the installation image.
This URL can be either an HTTP URL or a file URL (or path to a file). If
this is an HTTP URL, Packer will download it and cache it between runs.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
### Optional:
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create for
the VM. By default, this is 40000 (about 40 GB).
- `export_opts` (array of strings) - Additional options to pass to the
`VBoxManage export`. This can be useful for passing product information to
include in the resulting appliance file.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `format` (string) - Either "ovf" or "ova", this specifies the output format of
the exported virtual machine. This defaults to "ovf".
- `guest_additions_mode` (string) - The method by which guest additions are made
available to the guest for installation. Valid options are "upload", "attach",
or "disable". If the mode is "attach" the guest additions ISO will be attached
as a CD device to the virtual machine. If the mode is "upload" the guest
additions ISO will be uploaded to the path specified by
`guest_additions_path`. The default value is "upload". If "disable" is used,
guest additions won't be downloaded, either.
- `guest_additions_path` (string) - The path on the guest virtual machine where
the VirtualBox guest additions ISO will be uploaded. By default this is
"VBoxGuestAdditions.iso" which should upload into the login directory of
the user. This is a [configuration
template](/docs/templates/configuration-templates.html) where the `Version`
variable is replaced with the VirtualBox version.
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest additions
ISO that will be uploaded to the guest VM. By default the checksums will be
downloaded from the VirtualBox website, so this only needs to be set if you
want to be explicit about the checksum.
- `guest_additions_url` (string) - The URL to the guest additions ISO to upload.
This can also be a file URL if the ISO is at a local path. By default, the
VirtualBox builder will attempt to find the guest additions ISO on the local
file system. If it is not available locally, the builder will download the
proper guest additions ISO from the internet.
- `guest_os_type` (string) - The guest OS type being installed. By default this
is "other", but you can get *dramatic* performance improvements by setting
this to the proper value. To view all available values for this run
`VBoxManage list ostypes`. Setting the correct value hints to VirtualBox how
to optimize the virtual hardware to work best with that operating system.
- `hard_drive_interface` (string) - The type of controller that the primary hard
drive is attached to, defaults to "ide". When set to "sata", the drive is
attached to an AHCI SATA controller. When set to "scsi", the drive is attached
to an LsiLogic SCSI controller.
- `headless` (boolean) - Packer defaults to building VirtualBox virtual machines
by launching a GUI that shows the console of the machine being built. When
this value is set to true, the machine will start without a console.
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `iso_interface` (string) - The type of controller that the ISO is attached to,
defaults to "ide". When set to "sata", the drive is attached to an AHCI
SATA controller.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download. Packer
will try these in order. If anything goes wrong attempting to download or
while downloading a single URL, it will move on to the next. All URLs must
point to the same file (same checksum). By default this is empty and `iso_url`
is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine unless a shutdown
command takes place inside script so this may safely be omitted. If one or
more scripts require a reboot it is suggested to leave this blank since
reboots may fail and specify the final shutdown command in your last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded to
the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `ssh_skip_nat_mapping` (boolean) - Defaults to false. When enabled, Packer
does not setup forwarded port mapping for SSH requests and uses `ssh_port` on
the host to communicate to the virtual machine
- `vboxmanage` (array of array of strings) - Custom `VBoxManage` commands to
execute in order to further customize the virtual machine being created. The
value of this is an array of commands to execute. The commands are executed in
the order defined in the template. For each command, the command is defined
itself as an array of strings, where each string represents a single argument
on the command-line to `VBoxManage` (but excluding `VBoxManage` itself). Each
arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use `VBoxManage`
are below.
- `vboxmanage_post` (array of array of strings) - Identical to `vboxmanage`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `virtualbox_version_file` (string) - The path within the virtual machine to
upload a file that contains the VirtualBox version that was used to create
the machine. This information can be useful for provisioning. By default this
is ".vbox\_version", which will generally be upload it into the
home directory.
- `vm_name` (string) - This is the name of the OVF file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `disk_size` (integer) - The size, in megabytes, of the hard disk to create
for the VM. By default, this is 40000 (about 40 GB).
- `export_opts` (array of strings) - Additional options to pass to the
`VBoxManage export`. This can be useful for passing product information to
include in the resulting appliance file.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `format` (string) - Either "ovf" or "ova", this specifies the output format
of the exported virtual machine. This defaults to "ovf".
- `guest_additions_mode` (string) - The method by which guest additions are
made available to the guest for installation. Valid options are "upload",
"attach", or "disable". If the mode is "attach" the guest additions ISO will
be attached as a CD device to the virtual machine. If the mode is "upload"
the guest additions ISO will be uploaded to the path specified by
`guest_additions_path`. The default value is "upload". If "disable" is used,
guest additions won't be downloaded, either.
- `guest_additions_path` (string) - The path on the guest virtual machine
where the VirtualBox guest additions ISO will be uploaded. By default this
is "VBoxGuestAdditions.iso" which should upload into the login directory of
the user. This is a [configuration
template](/docs/templates/configuration-templates.html) where the `Version`
variable is replaced with the VirtualBox version.
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest
additions ISO that will be uploaded to the guest VM. By default the
checksums will be downloaded from the VirtualBox website, so this only needs
to be set if you want to be explicit about the checksum.
- `guest_additions_url` (string) - The URL to the guest additions ISO
to upload. This can also be a file URL if the ISO is at a local path. By
default, the VirtualBox builder will attempt to find the guest additions ISO
on the local file system. If it is not available locally, the builder will
download the proper guest additions ISO from the internet.
- `guest_os_type` (string) - The guest OS type being installed. By default
this is "other", but you can get *dramatic* performance improvements by
setting this to the proper value. To view all available values for this run
`VBoxManage list ostypes`. Setting the correct value hints to VirtualBox how
to optimize the virtual hardware to work best with that operating system.
- `hard_drive_interface` (string) - The type of controller that the primary
hard drive is attached to, defaults to "ide". When set to "sata", the drive
is attached to an AHCI SATA controller. When set to "scsi", the drive is
attached to an LsiLogic SCSI controller.
- `headless` (boolean) - Packer defaults to building VirtualBox virtual
machines by launching a GUI that shows the console of the machine
being built. When this value is set to true, the machine will start without
a console.
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `iso_interface` (string) - The type of controller that the ISO is attached
to, defaults to "ide". When set to "sata", the drive is attached to an AHCI
SATA controller.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download.
Packer will try these in order. If anything goes wrong attempting to
download or while downloading a single URL, it will move on to the next. All
URLs must point to the same file (same checksum). By default this is empty
and `iso_url` is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine unless a
shutdown command takes place inside script so this may safely be omitted. If
one or more scripts require a reboot it is suggested to leave this blank
since reboots may fail and specify the final shutdown command in your
last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded
to the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `ssh_skip_nat_mapping` (boolean) - Defaults to false. When enabled, Packer
does not setup forwarded port mapping for SSH requests and uses `ssh_port`
on the host to communicate to the virtual machine
- `vboxmanage` (array of array of strings) - Custom `VBoxManage` commands to
execute in order to further customize the virtual machine being created. The
value of this is an array of commands to execute. The commands are executed
in the order defined in the template. For each command, the command is
defined itself as an array of strings, where each string represents a single
argument on the command-line to `VBoxManage` (but excluding
`VBoxManage` itself). Each arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use
`VBoxManage` are below.
- `vboxmanage_post` (array of array of strings) - Identical to `vboxmanage`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `virtualbox_version_file` (string) - The path within the virtual machine to
upload a file that contains the VirtualBox version that was used to create
the machine. This information can be useful for provisioning. By default
this is ".vbox\_version", which will generally be upload it into the
home directory.
- `vm_name` (string) - This is the name of the OVF file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
## Boot Command
......@@ -242,40 +244,40 @@ machine, simulating a human actually typing the keyboard. There are a set of
special keys available. If these are in your boot command, they will be replaced
by the proper key:
- `<bs>` - Backspace
- `<bs>` - Backspace
- `<del>` - Delete
- `<del>` - Delete
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<esc>` - Simulates pressing the escape key.
- `<esc>` - Simulates pressing the escape key.
- `<tab>` - Simulates pressing the tab key.
- `<tab>` - Simulates pressing the tab key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<spacebar>` - Simulates pressing the spacebar.
- `<spacebar>` - Simulates pressing the spacebar.
- `<insert>` - Simulates pressing the insert key.
- `<insert>` - Simulates pressing the insert key.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before sending
any additional keys. This is useful if you have to generally wait for the UI
to update before typing more.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before
sending any additional keys. This is useful if you have to generally wait
for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
available variables are:
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server that
is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
that is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
Example boot command. This is actually a working boot command used to start an
Ubuntu 12.04 installer:
......
website/source/docs/builders/virtualbox-ovf.html.markdown
View file @ d8e8f98b
......@@ -19,11 +19,13 @@ image).
When exporting from VirtualBox make sure to choose OVF Version 2, since Version
1 is not compatible and will generate errors like this:
==> virtualbox-ovf: Progress state: VBOX_E_FILE_ERROR
==> virtualbox-ovf: VBoxManage: error: Appliance read failed
==> virtualbox-ovf: VBoxManage: error: Error reading "source.ova": element "Section" has no "type" attribute, line 21
==> virtualbox-ovf: VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component Appliance, interface IAppliance
==> virtualbox-ovf: VBoxManage: error: Context: "int handleImportAppliance(HandlerArg*)" at line 304 of file VBoxManageAppliance.cpp
==&gt; virtualbox-ovf: Progress state: VBOX\_E\_FILE\_ERROR ==&gt;
virtualbox-ovf: VBoxManage: error: Appliance read failed ==&gt; virtualbox-ovf:
VBoxManage: error: Error reading "source.ova": element "Section" has no "type"
attribute, line 21 ==&gt; virtualbox-ovf: VBoxManage: error: Details: code
VBOX\_E\_FILE\_ERROR (0x80bb0004), component Appliance, interface IAppliance
==&gt; virtualbox-ovf: VBoxManage: error: Context: "int
handleImportAppliance(HandlerArg\*)" at line 304 of file VBoxManageAppliance.cpp
The builder builds a virtual machine by importing an existing OVF or OVA file.
It then boots this image, runs provisioners on this new VM, and exports that VM
......@@ -61,149 +63,151 @@ builder.
### Required:
- `source_path` (string) - The path to an OVF or OVA file that acts as the
source of this build.
- `source_path` (string) - The path to an OVF or OVA file that acts as the
source of this build.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
### Optional:
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `export_opts` (array of strings) - Additional options to pass to the
`VBoxManage export`. This can be useful for passing product information to
include in the resulting appliance file.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `format` (string) - Either "ovf" or "ova", this specifies the output format of
the exported virtual machine. This defaults to "ovf".
- `guest_additions_mode` (string) - The method by which guest additions are made
available to the guest for installation. Valid options are "upload", "attach",
or "disable". If the mode is "attach" the guest additions ISO will be attached
as a CD device to the virtual machine. If the mode is "upload" the guest
additions ISO will be uploaded to the path specified by
`guest_additions_path`. The default value is "upload". If "disable" is used,
guest additions won't be downloaded, either.
- `guest_additions_path` (string) - The path on the guest virtual machine where
the VirtualBox guest additions ISO will be uploaded. By default this is
"VBoxGuestAdditions.iso" which should upload into the login directory of
the user. This is a [configuration
template](/docs/templates/configuration-templates.html) where the `Version`
variable is replaced with the VirtualBox version.
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest additions
ISO that will be uploaded to the guest VM. By default the checksums will be
downloaded from the VirtualBox website, so this only needs to be set if you
want to be explicit about the checksum.
- `guest_additions_url` (string) - The URL to the guest additions ISO to upload.
This can also be a file URL if the ISO is at a local path. By default the
VirtualBox builder will go and download the proper guest additions ISO from
the internet.
- `headless` (boolean) - Packer defaults to building VirtualBox virtual machines
by launching a GUI that shows the console of the machine being built. When
this value is set to true, the machine will start without a console.
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `import_flags` (array of strings) - Additional flags to pass to
`VBoxManage import`. This can be used to add additional command-line flags
such as `--eula-accept` to accept a EULA in the OVF.
- `import_opts` (string) - Additional options to pass to the
`VBoxManage import`. This can be useful for passing "keepallmacs" or
"keepnatmacs" options for existing ovf images.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine unless a shutdown
command takes place inside script so this may safely be omitted. If one or
more scripts require a reboot it is suggested to leave this blank since
reboots may fail and specify the final shutdown command in your last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded to
the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `ssh_skip_nat_mapping` (boolean) - Defaults to false. When enabled, Packer
does not setup forwarded port mapping for SSH requests and uses `ssh_port` on
the host to communicate to the virtual machine
- `vboxmanage` (array of array of strings) - Custom `VBoxManage` commands to
execute in order to further customize the virtual machine being created. The
value of this is an array of commands to execute. The commands are executed in
the order defined in the template. For each command, the command is defined
itself as an array of strings, where each string represents a single argument
on the command-line to `VBoxManage` (but excluding `VBoxManage` itself). Each
arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use `VBoxManage`
are below.
- `vboxmanage_post` (array of array of strings) - Identical to `vboxmanage`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `virtualbox_version_file` (string) - The path within the virtual machine to
upload a file that contains the VirtualBox version that was used to create
the machine. This information can be useful for provisioning. By default this
is ".vbox\_version", which will generally be upload it into the
home directory.
- `vm_name` (string) - This is the name of the virtual machine when it is
imported as well as the name of the OVF file when the virtual machine
is exported. By default this is "packer-BUILDNAME", where "BUILDNAME" is the
name of the build.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `export_opts` (array of strings) - Additional options to pass to the
`VBoxManage export`. This can be useful for passing product information to
include in the resulting appliance file.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `format` (string) - Either "ovf" or "ova", this specifies the output format
of the exported virtual machine. This defaults to "ovf".
- `guest_additions_mode` (string) - The method by which guest additions are
made available to the guest for installation. Valid options are "upload",
"attach", or "disable". If the mode is "attach" the guest additions ISO will
be attached as a CD device to the virtual machine. If the mode is "upload"
the guest additions ISO will be uploaded to the path specified by
`guest_additions_path`. The default value is "upload". If "disable" is used,
guest additions won't be downloaded, either.
- `guest_additions_path` (string) - The path on the guest virtual machine
where the VirtualBox guest additions ISO will be uploaded. By default this
is "VBoxGuestAdditions.iso" which should upload into the login directory of
the user. This is a [configuration
template](/docs/templates/configuration-templates.html) where the `Version`
variable is replaced with the VirtualBox version.
- `guest_additions_sha256` (string) - The SHA256 checksum of the guest
additions ISO that will be uploaded to the guest VM. By default the
checksums will be downloaded from the VirtualBox website, so this only needs
to be set if you want to be explicit about the checksum.
- `guest_additions_url` (string) - The URL to the guest additions ISO
to upload. This can also be a file URL if the ISO is at a local path. By
default the VirtualBox builder will go and download the proper guest
additions ISO from the internet.
- `headless` (boolean) - Packer defaults to building VirtualBox virtual
machines by launching a GUI that shows the console of the machine
being built. When this value is set to true, the machine will start without
a console.
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `import_flags` (array of strings) - Additional flags to pass to
`VBoxManage import`. This can be used to add additional command-line flags
such as `--eula-accept` to accept a EULA in the OVF.
- `import_opts` (string) - Additional options to pass to the
`VBoxManage import`. This can be useful for passing "keepallmacs" or
"keepnatmacs" options for existing ovf images.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine unless a
shutdown command takes place inside script so this may safely be omitted. If
one or more scripts require a reboot it is suggested to leave this blank
since reboots may fail and specify the final shutdown command in your
last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `ssh_host_port_min` and `ssh_host_port_max` (integer) - The minimum and
maximum port to use for the SSH port on the host machine which is forwarded
to the SSH port on the guest machine. Because Packer often runs in parallel,
Packer will choose a randomly available port in this range to use as the
host port.
- `ssh_skip_nat_mapping` (boolean) - Defaults to false. When enabled, Packer
does not setup forwarded port mapping for SSH requests and uses `ssh_port`
on the host to communicate to the virtual machine
- `vboxmanage` (array of array of strings) - Custom `VBoxManage` commands to
execute in order to further customize the virtual machine being created. The
value of this is an array of commands to execute. The commands are executed
in the order defined in the template. For each command, the command is
defined itself as an array of strings, where each string represents a single
argument on the command-line to `VBoxManage` (but excluding
`VBoxManage` itself). Each arg is treated as a [configuration
template](/docs/templates/configuration-templates.html), where the `Name`
variable is replaced with the VM name. More details on how to use
`VBoxManage` are below.
- `vboxmanage_post` (array of array of strings) - Identical to `vboxmanage`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `virtualbox_version_file` (string) - The path within the virtual machine to
upload a file that contains the VirtualBox version that was used to create
the machine. This information can be useful for provisioning. By default
this is ".vbox\_version", which will generally be upload it into the
home directory.
- `vm_name` (string) - This is the name of the virtual machine when it is
imported as well as the name of the OVF file when the virtual machine
is exported. By default this is "packer-BUILDNAME", where "BUILDNAME" is the
name of the build.
## Guest Additions
......
website/source/docs/builders/virtualbox.html.markdown
View file @ d8e8f98b
......@@ -16,13 +16,14 @@ 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.
website/source/docs/builders/vmware-iso.html.markdown
View file @ d8e8f98b
......@@ -57,195 +57,199 @@ builder.
### Required:
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO files
are so large, this is required and Packer will verify it prior to booting a
virtual machine with the ISO attached. The type of the checksum is specified
with `iso_checksum_type`, documented below.
- `iso_checksum` (string) - The checksum for the OS ISO file. Because ISO
files are so large, this is required and Packer will verify it prior to
booting a virtual machine with the ISO attached. The type of the checksum is
specified with `iso_checksum_type`, documented below.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_checksum_type` (string) - The type of the checksum specified in
`iso_checksum`. Valid values are "none", "md5", "sha1", "sha256", or
"sha512" currently. While "none" will skip checksumming, this is not
recommended since ISO files are generally large and corruption does happen
from time to time.
- `iso_url` (string) - A URL to the ISO containing the installation image. This
URL can be either an HTTP URL or a file URL (or path to a file). If this is an
HTTP URL, Packer will download it and cache it between runs.
- `iso_url` (string) - A URL to the ISO containing the installation image.
This URL can be either an HTTP URL or a file URL (or path to a file). If
this is an HTTP URL, Packer will download it and cache it between runs.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
### Optional:
- `disk_additional_size` (array of integers) - The size(s) of any additional
hard disks for the VM in megabytes. If this is not specified then the VM will
only contain a primary hard disk. The builder uses expandable, not fixed-size
virtual hard disks, so the actual file representing the disk will not use the
full size unless it is full.
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `disk_size` (integer) - The size of the hard disk for the VM in megabytes. The
builder uses expandable, not fixed-size virtual hard disks, so the actual file
representing the disk will not use the full size unless it is full. By default
this is set to 40,000 (about 40 GB).
- `disk_type_id` (string) - The type of VMware virtual disk to create. The
default is "1", which corresponds to a growable virtual disk split in
2GB files. This option is for advanced usage, modify only if you know what
you're doing. For more information, please consult the [Virtual Disk Manager
User's Guide](http://www.vmware.com/pdf/VirtualDiskManager.pdf) for desktop
VMware clients. For ESXi, refer to the proper ESXi documentation.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
"/Applications/VMware Fusion.app" but this setting allows you to
customize this.
- `guest_os_type` (string) - The guest OS type being installed. This will be set
in the VMware VMX. By default this is "other". By specifying a more specific
OS type, VMware may perform some optimizations or virtual hardware changes to
better support the operating system running in the virtual machine.
- `headless` (boolean) - Packer defaults to building VMware virtual machines by
launching a GUI that shows the console of the machine being built. When this
value is set to true, the machine will start without a console. For VMware
machines, Packer will output VNC connection information in case you need to
connect to the console to debug the build process.
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download. Packer
will try these in order. If anything goes wrong attempting to download or
while downloading a single URL, it will move on to the next. All URLs must
point to the same file (same checksum). By default this is empty and `iso_url`
is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `remote_cache_datastore` (string) - The path to the datastore where supporting
files will be stored during the build on the remote machine. By default this
is the same as the `remote_datastore` option. This only has an effect if
`remote_type` is enabled.
- `remote_cache_directory` (string) - The path where the ISO and/or floppy files
will be stored during the build on the remote machine. The path is relative to
the `remote_cache_datastore` on the remote machine. By default this
is "packer\_cache". This only has an effect if `remote_type` is enabled.
- `remote_datastore` (string) - The path to the datastore where the resulting VM
will be stored when it is built on the remote machine. By default this
is "datastore1". This only has an effect if `remote_type` is enabled.
- `remote_host` (string) - The host of the remote machine used for access. This
is only required if `remote_type` is enabled.
- `remote_password` (string) - The SSH password for the user used to access the
remote machine. By default this is empty. This only has an effect if
`remote_type` is enabled.
- `remote_type` (string) - The type of remote machine that will be used to build
this VM rather than a local desktop product. The only value accepted for this
currently is "esx5". If this is not set, a desktop product will be used. By
default, this is not set.
- `remote_username` (string) - The username for the SSH user that will access
the remote machine. This is required if `remote_type` is enabled.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `skip_compaction` (boolean) - VMware-created disks are defragmented and
compacted at the end of the build process using `vmware-vdiskmanager`. In
certain rare cases, this might actually end up making the resulting disks
slightly larger. If you find this to be the case, you can disable compaction
using this configuration value.
- `tools_upload_flavor` (string) - The flavor of the VMware Tools ISO to upload
into the VM. Valid values are "darwin", "linux", and "windows". By default,
this is empty, which means VMware tools won't be uploaded.
- `tools_upload_path` (string) - The path in the VM to upload the VMware tools.
This only takes effect if `tools_upload_flavor` is non-empty. This is a
[configuration template](/docs/templates/configuration-templates.html) that
has a single valid variable: `Flavor`, which will be the value of
`tools_upload_flavor`. By default the upload path is set to `{{.Flavor}}.iso`.
This setting is not used when `remote_type` is "esx5".
- `version` (string) - The [vmx hardware
version](http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746)
for the new virtual machine. Only the default value has been tested, any other
value is experimental. Default value is '9'.
- `vm_name` (string) - This is the name of the VMX file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `vmdk_name` (string) - The filename of the virtual disk that'll be created,
without the extension. This defaults to "packer".
- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter into
the virtual machine VMX file. This is for advanced users who want to set
properties such as memory, CPU, etc.
- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `vmx_template_path` (string) - Path to a [configuration
template](/docs/templates/configuration-templates.html) that defines the
contents of the virtual machine VMX file for VMware. This is for **advanced
users only** as this can render the virtual machine non-functional. See below
for more information. For basic VMX modifications, try `vmx_data` first.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port to
use for VNC access to the virtual machine. The builder uses VNC to type the
initial `boot_command`. Because Packer generally runs in parallel, Packer uses
a randomly chosen port in this range that appears available. By default this
is 5900 to 6000. The minimum and maximum ports are inclusive.
- `disk_additional_size` (array of integers) - The size(s) of any additional
hard disks for the VM in megabytes. If this is not specified then the VM
will only contain a primary hard disk. The builder uses expandable, not
fixed-size virtual hard disks, so the actual file representing the disk will
not use the full size unless it is full.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `disk_size` (integer) - The size of the hard disk for the VM in megabytes.
The builder uses expandable, not fixed-size virtual hard disks, so the
actual file representing the disk will not use the full size unless it
is full. By default this is set to 40,000 (about 40 GB).
- `disk_type_id` (string) - The type of VMware virtual disk to create. The
default is "1", which corresponds to a growable virtual disk split in
2GB files. This option is for advanced usage, modify only if you know what
you're doing. For more information, please consult the [Virtual Disk Manager
User's Guide](http://www.vmware.com/pdf/VirtualDiskManager.pdf) for desktop
VMware clients. For ESXi, refer to the proper ESXi documentation.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
"/Applications/VMware Fusion.app" but this setting allows you to
customize this.
- `guest_os_type` (string) - The guest OS type being installed. This will be
set in the VMware VMX. By default this is "other". By specifying a more
specific OS type, VMware may perform some optimizations or virtual hardware
changes to better support the operating system running in the
virtual machine.
- `headless` (boolean) - Packer defaults to building VMware virtual machines
by launching a GUI that shows the console of the machine being built. When
this value is set to true, the machine will start without a console. For
VMware machines, Packer will output VNC connection information in case you
need to connect to the console to debug the build process.
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `iso_urls` (array of strings) - Multiple URLs for the ISO to download.
Packer will try these in order. If anything goes wrong attempting to
download or while downloading a single URL, it will move on to the next. All
URLs must point to the same file (same checksum). By default this is empty
and `iso_url` is used. Only one of `iso_url` or `iso_urls` can be specified.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `remote_cache_datastore` (string) - The path to the datastore where
supporting files will be stored during the build on the remote machine. By
default this is the same as the `remote_datastore` option. This only has an
effect if `remote_type` is enabled.
- `remote_cache_directory` (string) - The path where the ISO and/or floppy
files will be stored during the build on the remote machine. The path is
relative to the `remote_cache_datastore` on the remote machine. By default
this is "packer\_cache". This only has an effect if `remote_type`
is enabled.
- `remote_datastore` (string) - The path to the datastore where the resulting
VM will be stored when it is built on the remote machine. By default this
is "datastore1". This only has an effect if `remote_type` is enabled.
- `remote_host` (string) - The host of the remote machine used for access.
This is only required if `remote_type` is enabled.
- `remote_password` (string) - The SSH password for the user used to access
the remote machine. By default this is empty. This only has an effect if
`remote_type` is enabled.
- `remote_type` (string) - The type of remote machine that will be used to
build this VM rather than a local desktop product. The only value accepted
for this currently is "esx5". If this is not set, a desktop product will
be used. By default, this is not set.
- `remote_username` (string) - The username for the SSH user that will access
the remote machine. This is required if `remote_type` is enabled.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `skip_compaction` (boolean) - VMware-created disks are defragmented and
compacted at the end of the build process using `vmware-vdiskmanager`. In
certain rare cases, this might actually end up making the resulting disks
slightly larger. If you find this to be the case, you can disable compaction
using this configuration value.
- `tools_upload_flavor` (string) - The flavor of the VMware Tools ISO to
upload into the VM. Valid values are "darwin", "linux", and "windows". By
default, this is empty, which means VMware tools won't be uploaded.
- `tools_upload_path` (string) - The path in the VM to upload the
VMware tools. This only takes effect if `tools_upload_flavor` is non-empty.
This is a [configuration
template](/docs/templates/configuration-templates.html) that has a single
valid variable: `Flavor`, which will be the value of `tools_upload_flavor`.
By default the upload path is set to `{{.Flavor}}.iso`. This setting is not
used when `remote_type` is "esx5".
- `version` (string) - The [vmx hardware
version](http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1003746)
for the new virtual machine. Only the default value has been tested, any
other value is experimental. Default value is '9'.
- `vm_name` (string) - This is the name of the VMX file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `vmdk_name` (string) - The filename of the virtual disk that'll be created,
without the extension. This defaults to "packer".
- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter
into the virtual machine VMX file. This is for advanced users who want to
set properties such as memory, CPU, etc.
- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `vmx_template_path` (string) - Path to a [configuration
template](/docs/templates/configuration-templates.html) that defines the
contents of the virtual machine VMX file for VMware. This is for **advanced
users only** as this can render the virtual machine non-functional. See
below for more information. For basic VMX modifications, try
`vmx_data` first.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port
to use for VNC access to the virtual machine. The builder uses VNC to type
the initial `boot_command`. Because Packer generally runs in parallel,
Packer uses a randomly chosen port in this range that appears available. By
default this is 5900 to 6000. The minimum and maximum ports are inclusive.
## Boot Command
......@@ -263,40 +267,40 @@ machine, simulating a human actually typing the keyboard. There are a set of
special keys available. If these are in your boot command, they will be replaced
by the proper key:
- `<bs>` - Backspace
- `<bs>` - Backspace
- `<del>` - Delete
- `<del>` - Delete
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<enter>` and `<return>` - Simulates an actual "enter" or "return" keypress.
- `<esc>` - Simulates pressing the escape key.
- `<esc>` - Simulates pressing the escape key.
- `<tab>` - Simulates pressing the tab key.
- `<tab>` - Simulates pressing the tab key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<f1>` - `<f12>` - Simulates pressing a function key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<up>` `<down>` `<left>` `<right>` - Simulates pressing an arrow key.
- `<spacebar>` - Simulates pressing the spacebar.
- `<spacebar>` - Simulates pressing the spacebar.
- `<insert>` - Simulates pressing the insert key.
- `<insert>` - Simulates pressing the insert key.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<home>` `<end>` - Simulates pressing the home and end keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<pageUp>` `<pageDown>` - Simulates pressing the page up and page down keys.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before sending
any additional keys. This is useful if you have to generally wait for the UI
to update before typing more.
- `<wait>` `<wait5>` `<wait10>` - Adds a 1, 5 or 10 second pause before
sending any additional keys. This is useful if you have to generally wait
for the UI to update before typing more.
In addition to the special keys, each command to type is treated as a
[configuration template](/docs/templates/configuration-templates.html). The
available variables are:
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server that
is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
- `HTTPIP` and `HTTPPort` - The IP and port, respectively of an HTTP server
that is started serving the directory specified by the `http_directory`
configuration parameter. If `http_directory` isn't specified, these will be
blank!
Example boot command. This is actually a working boot command used to start an
Ubuntu 12.04 installer:
......@@ -332,12 +336,12 @@ Within the template, a handful of variables are available so that your template
can continue working with the rest of the Packer machinery. Using these
variables isn't required, however.
- `Name` - The name of the virtual machine.
- `GuestOS` - The VMware-valid guest OS type.
- `DiskName` - The filename (without the suffix) of the main virtual disk.
- `ISOPath` - The path to the ISO to use for the OS installation.
- `Version` - The Hardware version VMWare will execute this vm under. Also known
as the `virtualhw.version`.
- `Name` - The name of the virtual machine.
- `GuestOS` - The VMware-valid guest OS type.
- `DiskName` - The filename (without the suffix) of the main virtual disk.
- `ISOPath` - The path to the ISO to use for the OS installation.
- `Version` - The Hardware version VMWare will execute this vm under. Also
known as the `virtualhw.version`.
## Building on a Remote vSphere Hypervisor
......@@ -367,23 +371,23 @@ connections.
To use a remote VMware vSphere Hypervisor to build your virtual machine, fill in
the required `remote_*` configurations:
- `remote_type` - This must be set to "esx5".
- `remote_type` - This must be set to "esx5".
- `remote_host` - The host of the remote machine.
- `remote_host` - The host of the remote machine.
Additionally, there are some optional configurations that you'll likely have to
modify as well:
- `remote_datastore` - The path to the datastore where the VM will be stored on
the ESXi machine.
- `remote_datastore` - The path to the datastore where the VM will be stored
on the ESXi machine.
- `remote_cache_datastore` - The path to the datastore where supporting files
will be stored during the build on the remote machine.
- `remote_cache_datastore` - The path to the datastore where supporting files
will be stored during the build on the remote machine.
- `remote_cache_directory` - The path where the ISO and/or floppy files will be
stored during the build on the remote machine. The path is relative to the
`remote_cache_datastore` on the remote machine.
- `remote_cache_directory` - The path where the ISO and/or floppy files will
be stored during the build on the remote machine. The path is relative to
the `remote_cache_datastore` on the remote machine.
- `remote_username` - The SSH username used to access the remote machine.
- `remote_username` - The SSH username used to access the remote machine.
- `remote_password` - The SSH password for access to the remote machine.
- `remote_password` - The SSH password for access to the remote machine.
website/source/docs/builders/vmware-vmx.html.markdown
View file @ d8e8f98b
......@@ -53,99 +53,100 @@ builder.
### Required:
- `source_path` (string) - Path to the source VMX file to clone.
- `source_path` (string) - Path to the source VMX file to clone.
- `ssh_username` (string) - The username to use to SSH into the machine once the
OS is installed.
- `ssh_username` (string) - The username to use to SSH into the machine once
the OS is installed.
### Optional:
- `boot_command` (array of strings) - This is an array of commands to type when
the virtual machine is first booted. The goal of these commands should be to
type just enough to initialize the operating system installer. Special keys
can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait five
seconds and one minute 30 seconds, respectively. If this isn't specified, the
default is 10 seconds.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?, and \[\])
are allowed. Directory names are also allowed, which will add all the files
found in the directory to the floppy.
- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
"/Applications/VMware Fusion.app" but this setting allows you to
customize this.
- `headless` (boolean) - Packer defaults to building VMware virtual machines by
launching a GUI that shows the console of the machine being built. When this
value is set to true, the machine will start without a console. For VMware
machines, Packer will output VNC connection information in case you need to
connect to the console to debug the build process.
- `http_directory` (string) - Path to a directory to serve using an HTTP server.
The files in this directory will be available over HTTP that will be
requestable from the virtual machine. This is useful for hosting kickstart
files and so on. By default this is "", which means no HTTP server will
be started. The address and port of the HTTP server will be available as
variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the `http_directory`.
Because Packer often runs in parallel, Packer will choose a randomly available
port in this range to run the HTTP server. If you want to force the HTTP
server to be on one port, make this minimum and maximum port the same. By
default the values are 8000 and 9000, respectively.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty string,
which tells Packer to just forcefully shut down the machine unless a shutdown
command takes place inside script so this may safely be omitted. If one or
more scripts require a reboot it is suggested to leave this blank since
reboots may fail and specify the final shutdown command in your last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `skip_compaction` (boolean) - VMware-created disks are defragmented and
compacted at the end of the build process using `vmware-vdiskmanager`. In
certain rare cases, this might actually end up making the resulting disks
slightly larger. If you find this to be the case, you can disable compaction
using this configuration value.
- `vm_name` (string) - This is the name of the VMX file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter into
the virtual machine VMX file. This is for advanced users who want to set
properties such as memory, CPU, etc.
- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port to
use for VNC access to the virtual machine. The builder uses VNC to type the
initial `boot_command`. Because Packer generally runs in parallel, Packer uses
a randomly chosen port in this range that appears available. By default this
is 5900 to 6000. The minimum and maximum ports are inclusive.
- `boot_command` (array of strings) - This is an array of commands to type
when the virtual machine is first booted. The goal of these commands should
be to type just enough to initialize the operating system installer. Special
keys can be typed as well, and are covered in the section below on the
boot command. If this is not specified, it is assumed the installer will
start itself.
- `boot_wait` (string) - The time to wait after booting the initial virtual
machine before typing the `boot_command`. The value of this should be
a duration. Examples are "5s" and "1m30s" which will cause Packer to wait
five seconds and one minute 30 seconds, respectively. If this isn't
specified, the default is 10 seconds.
- `floppy_files` (array of strings) - A list of files to place onto a floppy
disk that is attached when the VM is booted. This is most useful for
unattended Windows installs, which look for an `Autounattend.xml` file on
removable media. By default, no floppy will be attached. All files listed in
this setting get placed into the root directory of the floppy and the floppy
is attached as the first floppy device. Currently, no support exists for
creating sub-directories on the floppy. Wildcard characters (\*, ?,
and \[\]) are allowed. Directory names are also allowed, which will add all
the files found in the directory to the floppy.
- `fusion_app_path` (string) - Path to "VMware Fusion.app". By default this is
"/Applications/VMware Fusion.app" but this setting allows you to
customize this.
- `headless` (boolean) - Packer defaults to building VMware virtual machines
by launching a GUI that shows the console of the machine being built. When
this value is set to true, the machine will start without a console. For
VMware machines, Packer will output VNC connection information in case you
need to connect to the console to debug the build process.
- `http_directory` (string) - Path to a directory to serve using an
HTTP server. The files in this directory will be available over HTTP that
will be requestable from the virtual machine. This is useful for hosting
kickstart files and so on. By default this is "", which means no HTTP server
will be started. The address and port of the HTTP server will be available
as variables in `boot_command`. This is covered in more detail below.
- `http_port_min` and `http_port_max` (integer) - These are the minimum and
maximum port to use for the HTTP server started to serve the
`http_directory`. Because Packer often runs in parallel, Packer will choose
a randomly available port in this range to run the HTTP server. If you want
to force the HTTP server to be on one port, make this minimum and maximum
port the same. By default the values are 8000 and 9000, respectively.
- `output_directory` (string) - This is the path to the directory where the
resulting virtual machine will be created. This may be relative or absolute.
If relative, the path is relative to the working directory when `packer`
is executed. This directory must not exist or be empty prior to running
the builder. By default this is "output-BUILDNAME" where "BUILDNAME" is the
name of the build.
- `shutdown_command` (string) - The command to use to gracefully shut down the
machine once all the provisioning is done. By default this is an empty
string, which tells Packer to just forcefully shut down the machine unless a
shutdown command takes place inside script so this may safely be omitted. If
one or more scripts require a reboot it is suggested to leave this blank
since reboots may fail and specify the final shutdown command in your
last script.
- `shutdown_timeout` (string) - The amount of time to wait after executing the
`shutdown_command` for the virtual machine to actually shut down. If it
doesn't shut down in this time, it is an error. By default, the timeout is
"5m", or five minutes.
- `skip_compaction` (boolean) - VMware-created disks are defragmented and
compacted at the end of the build process using `vmware-vdiskmanager`. In
certain rare cases, this might actually end up making the resulting disks
slightly larger. If you find this to be the case, you can disable compaction
using this configuration value.
- `vm_name` (string) - This is the name of the VMX file for the new virtual
machine, without the file extension. By default this is "packer-BUILDNAME",
where "BUILDNAME" is the name of the build.
- `vmx_data` (object of key/value strings) - Arbitrary key/values to enter
into the virtual machine VMX file. This is for advanced users who want to
set properties such as memory, CPU, etc.
- `vmx_data_post` (object of key/value strings) - Identical to `vmx_data`,
except that it is run after the virtual machine is shutdown, and before the
virtual machine is exported.
- `vnc_port_min` and `vnc_port_max` (integer) - The minimum and maximum port
to use for VNC access to the virtual machine. The builder uses VNC to type
the initial `boot_command`. Because Packer generally runs in parallel,
Packer uses a randomly chosen port in this range that appears available. By
default this is 5900 to 6000. The minimum and maximum ports are inclusive.
website/source/docs/builders/vmware.html.markdown
View file @ d8e8f98b
......@@ -15,14 +15,14 @@ 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.
website/source/docs/command-line/build.html.markdown
View file @ d8e8f98b
......@@ -17,24 +17,26 @@ artifacts that are created will be outputted at the end of the build.
## Options
- `-color=false` - Disables colorized output. Enabled by default.
- `-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.
- `-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.
- `-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.
- `-color=false` - Disables colorized output. Enabled by default.
- `-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.
- `-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.
- `-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.
website/source/docs/command-line/fix.html.markdown
View file @ d8e8f98b
......@@ -19,7 +19,7 @@ The fix command will output the changed template to standard out, so you should
redirect standard using standard OS-specific techniques if you want to save it
to a file. For example, on Linux systems, you may want to do this:
$ packer fix old.json > new.json
\$ packer fix old.json &gt; new.json
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
......
website/source/docs/command-line/machine-readable.html.markdown
View file @ d8e8f98b
......@@ -53,20 +53,22 @@ timestamp,target,type,data...
Each component is explained below:
- **timestamp** is a Unix timestamp in UTC of when the message was printed.
- **target** is the target of the following output. This is empty if the message
is related to Packer globally. Otherwise, this is generally a build name so
you can relate output to a specific build while parallel builds are running.
- **type** is the type of machine-readable message being outputted. There are a
set of standard types which are covered later, but each component of Packer
(builders, provisioners, etc.) may output their own custom types as well,
allowing the machine-readable output to be infinitely flexible.
- **data** is zero or more comma-seperated values associated with the
prior type. The exact amount and meaning of this data is type-dependent, so
you must read the documentation associated with the type to understand fully.
- **timestamp** is a Unix timestamp in UTC of when the message was printed.
- **target** is the target of the following output. This is empty if the
message is related to Packer globally. Otherwise, this is generally a build
name so you can relate output to a specific build while parallel builds
are running.
- **type** is the type of machine-readable message being outputted. There are
a set of standard types which are covered later, but each component of
Packer (builders, provisioners, etc.) may output their own custom types as
well, allowing the machine-readable output to be infinitely flexible.
- **data** is zero or more comma-seperated values associated with the
prior type. The exact amount and meaning of this data is type-dependent, so
you must read the documentation associated with the type to
understand fully.
Within the format, if data contains a comma, it is replaced with
`%!(PACKER_COMMA)`. This was preferred over an escape character such as `\'`
......
website/source/docs/command-line/push.html.markdown
View file @ d8e8f98b
......@@ -26,16 +26,16 @@ configuration](/docs/templates/push.html) must be completed within the template.
## Options
- `-message` - A message to identify the purpose or changes in this Packer
template much like a VCS commit message. This message will be passed to the
Packer build service. This option is also available as a short option `-m`.
- `-message` - A message to identify the purpose or changes in this Packer
template much like a VCS commit message. This message will be passed to the
Packer build service. This option is also available as a short option `-m`.
- `-token` - An access token for authenticating the push to the Packer build
service such as Atlas. This can also be specified within the push
configuration in the template.
- `-token` - An access token for authenticating the push to the Packer build
service such as Atlas. This can also be specified within the push
configuration in the template.
- `-name` - The name of the build in the service. This typically looks like
`hashicorp/precise64`.
- `-name` - The name of the build in the service. This typically looks like
`hashicorp/precise64`.
## Examples
......
website/source/docs/command-line/validate.html.markdown
View file @ d8e8f98b
......@@ -29,5 +29,5 @@ Errors validating build 'vmware'. 1 error(s) occurred:
## Options
- `-syntax-only` - Only the syntax of the template is checked. The configuration
is not validated.
- `-syntax-only` - Only the syntax of the template is checked. The
configuration is not validated.
website/source/docs/extend/developing-plugins.html.markdown
View file @ d8e8f98b
......@@ -52,19 +52,19 @@ the following two packages, you're encouraged to use whatever packages you want.
Because plugins are their own processes, there is no danger of colliding
dependencies.
- `github.com/mitchellh/packer` - Contains all the interfaces that you have to
implement for any given plugin.
- `github.com/mitchellh/packer` - Contains all the interfaces that you have to
implement for any given plugin.
- `github.com/mitchellh/packer/plugin` - Contains the code to serve the plugin.
This handles all the inter-process communication stuff.
- `github.com/mitchellh/packer/plugin` - Contains the code to serve
the plugin. This handles all the inter-process communication stuff.
There are two steps involved in creating a plugin:
1. Implement the desired interface. For example, if you're building a builder
plugin, implement the `packer.Builder` interface.
1. Implement the desired interface. For example, if you're building a builder
plugin, implement the `packer.Builder` interface.
2. Serve the interface by calling the appropriate plugin serving method in your
main method. In the case of a builder, this is `plugin.ServeBuilder`.
2. Serve the interface by calling the appropriate plugin serving method in your
main method. In the case of a builder, this is `plugin.ServeBuilder`.
A basic example is shown below. In this example, assume the `Builder` struct
implements the `packer.Builder` interface:
......
website/source/docs/extend/plugins.html.markdown
View file @ d8e8f98b
......@@ -51,21 +51,21 @@ 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/plugins`
on Windows.
2. `~/.packer.d/plugins` on Unix systems or `%APPDATA%/packer.d/plugins`
on Windows.
3. The current working directory.
3. The current working directory.
The valid types for plugins are:
- `builder` - Plugins responsible for building images for a specific platform.
- `builder` - Plugins responsible for building images for a specific platform.
- `command` - A CLI sub-command for `packer`.
- `command` - A CLI sub-command for `packer`.
- `post-processor` - A post-processor responsible for taking an artifact from a
builder and turning it into something else.
- `post-processor` - A post-processor responsible for taking an artifact from
a builder and turning it into something else.
- `provisioner` - A provisioner to install software on images created by
a builder.
- `provisioner` - A provisioner to install software on images created by
a builder.
website/source/docs/extend/post-processor.html.markdown
View file @ d8e8f98b
......@@ -79,11 +79,11 @@ creating a new artifact with a single file: the compressed archive.
The result signature of this method is `(Artifact, bool, error)`. Each return
value is explained below:
- `Artifact` - The newly created artifact if no errors occurred.
- `bool` - If true, the input artifact will forcefully be kept. By default,
Packer typically deletes all input artifacts, since the user doesn't generally
want intermediary artifacts. However, some post-processors depend on the
previous artifact existing. If this is `true`, it forces packer to keep the
artifact around.
- `error` - Non-nil if there was an error in any way. If this is the case, the
other two return values are ignored.
- `Artifact` - The newly created artifact if no errors occurred.
- `bool` - If true, the input artifact will forcefully be kept. By default,
Packer typically deletes all input artifacts, since the user doesn't
generally want intermediary artifacts. However, some post-processors depend
on the previous artifact existing. If this is `true`, it forces packer to
keep the artifact around.
- `error` - Non-nil if there was an error in any way. If this is the case, the
other two return values are ignored.
website/source/docs/machine-readable/command-build.html.markdown
View file @ d8e8f98b
......@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer build`.
<dl>
<dt>artifact (>= 2)</dt>
<dd>
<dt>
artifact (&gt;= 2)
</dt>
<dd>
<p>
Information about an artifact of the targeted item. This is a
fairly complex (but uniform!) machine-readable type that contains
......@@ -37,10 +39,12 @@ These are the machine-readable types that exist as part of the output of
data points related to the subtype. The exact count and meaning
of this subtypes comes from the subtype documentation.
</p>
</dd>
<dt>artifact-count (1)</dt>
<dd>
</dd>
<dt>
artifact-count (1)
</dt>
<dd>
<p>
The number of artifacts associated with the given target. This
will always be outputted _before_ any other artifact information,
......@@ -51,10 +55,12 @@ These are the machine-readable types that exist as part of the output of
<strong>Data 1: count</strong> - The number of artifacts as
a base 10 integer.
</p>
</dd>
<dt>artifact subtype: builder-id (1)</dt>
<dd>
</dd>
<dt>
artifact subtype: builder-id (1)
</dt>
<dd>
<p>
The unique ID of the builder that created this artifact.
</p>
......@@ -62,19 +68,23 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: id</strong> - The unique ID of the builder.
</p>
</dd>
<dt>artifact subtype: end (0)</dt>
<dd>
</dd>
<dt>
artifact subtype: end (0)
</dt>
<dd>
<p>
The last machine-readable output line outputted for an artifact.
This is a sentinel value so you know that no more data related to
the targetted artifact will be outputted.
</p>
</dd>
<dt>artifact subtype: file (2)</dt>
<dd>
</dd>
<dt>
artifact subtype: file (2)
</dt>
<dd>
<p>
A single file associated with the artifact. There are 0 to
"files-count" of these entries to describe every file that is
......@@ -89,10 +99,12 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 2: filename</strong> - The filename.
</p>
</dd>
<dt>artifact subtype: files-count (1)</dt>
<dd>
</dd>
<dt>
artifact subtype: files-count (1)
</dt>
<dd>
<p>
The number of files associated with this artifact. Not all
artifacts have files associated with it.
......@@ -101,10 +113,12 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: count</strong> - The number of files.
</p>
</dd>
<dt>artifact subtype: id (1)</dt>
<dd>
</dd>
<dt>
artifact subtype: id (1)
</dt>
<dd>
<p>
The ID (if any) of the artifact that was built. Not all artifacts
have associated IDs. For example, AMIs built have IDs associated
......@@ -115,18 +129,22 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: id</strong> - The ID of the artifact.
</p>
</dd>
<dt>artifact subtype: nil (0)</dt>
<dd>
</dd>
<dt>
artifact subtype: nil (0)
</dt>
<dd>
<p>
If present, this means that the artifact was nil, or that the targeted
build completed successfully but no artifact was created.
</p>
</dd>
<dt>artifact subtype: string (1)</dt>
<dd>
</dd>
<dt>
artifact subtype: string (1)
</dt>
<dd>
<p>
The human-readable string description of the artifact provided by
the artifact itself.
......@@ -135,10 +153,12 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: string</strong> - The string output for the artifact.
</p>
</dd>
<dt>error-count (1)</dt>
<dd>
</dd>
<dt>
error-count (1)
</dt>
<dd>
<p>
The number of errors that occurred during the build. This will
always be outputted before any errors so you know how many are coming.
......@@ -148,10 +168,12 @@ These are the machine-readable types that exist as part of the output of
<strong>Data 1: count</strong> - The number of build errors as
a base 10 integer.
</p>
</dd>
<dt>error (1)</dt>
<dd>
</dd>
<dt>
error (1)
</dt>
<dd>
<p>
A build error that occurred. The target of this output will be
the build that had the error.
......@@ -160,6 +182,6 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: error</strong> - The error message as a string.
</p>
</dd>
</dd>
</dl>
website/source/docs/machine-readable/command-inspect.html.markdown
View file @ d8e8f98b
......@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer inspect`.
<dl>
<dt>template-variable (3)</dt>
<dd>
<dt>
template-variable (3)
</dt>
<dd>
<p>
A <a href="/docs/templates/user-variables.html">user variable</a>
defined within the template.
......@@ -32,10 +34,12 @@ These are the machine-readable types that exist as part of the output of
<strong>Data 3: required</strong> - If non-zero, then this variable
is required.
</p>
</dd>
<dt>template-builder (2)</dt>
<dd>
</dd>
<dt>
template-builder (2)
</dt>
<dd>
<p>
A builder defined within the template
</p>
......@@ -48,10 +52,12 @@ These are the machine-readable types that exist as part of the output of
generally be the same as the name unless you explicitly override
the name.
</p>
</dd>
<dt>template-provisioner (1)</dt>
<dd>
</dd>
<dt>
template-provisioner (1)
</dt>
<dd>
<p>
A provisioner defined within the template. Multiple of these may
exist. If so, they are outputted in the order they would run.
......@@ -60,6 +66,6 @@ These are the machine-readable types that exist as part of the output of
<p>
<strong>Data 1: name</strong> - The name/type of the provisioner.
</p>
</dd>
</dd>
</dl>
website/source/docs/machine-readable/command-version.html.markdown
View file @ d8e8f98b
......@@ -12,8 +12,10 @@ These are the machine-readable types that exist as part of the output of
`packer version`.
<dl>
<dt>version (1)</dt>
<dd>
<dt>
version (1)
</dt>
<dd>
<p>The version number of Packer running.</p>
<p>
......@@ -21,19 +23,23 @@ These are the machine-readable types that exist as part of the output of
only including the major, minor, and patch versions. Example:
"0.2.4".
</p>
</dd>
<dt>version-commit (1)</dt>
<dd>
</dd>
<dt>
version-commit (1)
</dt>
<dd>
<p>The SHA1 of the Git commit that built this version of Packer.</p>
<p>
<strong>Data 1: commit SHA1</strong> - The SHA1 of the commit.
</p>
</dd>
<dt>version-prerelease (1)</dt>
<dd>
</dd>
<dt>
version-prerelease (1)
</dt>
<dd>
<p>
The prerelease tag (if any) for the running version of Packer. This
can be "beta", "dev", "alpha", etc. If this is empty, you can assume
......@@ -44,6 +50,6 @@ These are the machine-readable types that exist as part of the output of
<strong>Data 1: prerelease name</strong> - The name of the
prerelease tag.
</p>
</dd>
</dd>
</dl>
website/source/docs/machine-readable/general.html.markdown
View file @ d8e8f98b
......@@ -12,8 +12,10 @@ These are the machine-readable types that can appear in almost any
machine-readable output and are provided by Packer core itself.
<dl>
<dt>ui (2)</dt>
<dd>
<dt>
ui (2)
</dt>
<dd>
<p>
Specifies the output and type of output that would've normally
gone to the console if Packer were running in human-readable
......@@ -28,6 +30,6 @@ machine-readable output and are provided by Packer core itself.
<strong>Data 2: output</strong> - The UI message that would have
been outputted.
</p>
</dd>
</dd>
</dl>
website/source/docs/machine-readable/index.html.markdown
View file @ d8e8f98b
......@@ -24,12 +24,14 @@ Within each section, the format of the documentation is the following:
<br>
<dl>
<dt>type-name (data-count)</dt>
<dd>
<dt>
type-name (data-count)
</dt>
<dd>
<p>Description of the type.</p>
<p>
<strong>Data 1: name</strong> - Description.
</p>
</dd>
</dd>
</dl>
website/source/docs/other/core-configuration.html.markdown
View file @ d8e8f98b
......@@ -32,13 +32,13 @@ The format of the configuration file is basic JSON.
Below is the list of all available configuration parameters for the core
configuration file. None of these are required, since all have sane defaults.
- `plugin_min_port` and `plugin_max_port` (integer) - These are the minimum and
maximum ports that Packer uses for communication with plugins, since plugin
communication happens over TCP connections on your local host. By default
these are 10,000 and 25,000, respectively. Be sure to set a fairly wide range
here, since Packer can easily use over 25 ports on a single run.
- `builders`, `commands`, `post-processors`, and `provisioners` are objects that
are used to install plugins. The details of how exactly these are set is
covered in more detail in the [installing plugins documentation
page](/docs/extend/plugins.html).
- `plugin_min_port` and `plugin_max_port` (integer) - These are the minimum
and maximum ports that Packer uses for communication with plugins, since
plugin communication happens over TCP connections on your local host. By
default these are 10,000 and 25,000, respectively. Be sure to set a fairly
wide range here, since Packer can easily use over 25 ports on a single run.
- `builders`, `commands`, `post-processors`, and `provisioners` are objects
that are used to install plugins. The details of how exactly these are set
is covered in more detail in the [installing plugins documentation
page](/docs/extend/plugins.html).
website/source/docs/other/environmental-variables.html.markdown
View file @ d8e8f98b
......@@ -9,28 +9,28 @@ page_title: Environmental Variables for Packer
Packer uses a variety of environmental variables. A listing and description of
each can be found below:
- `PACKER_CACHE_DIR` - The location of the packer cache.
- `PACKER_CACHE_DIR` - The location of the packer cache.
- `PACKER_CONFIG` - The location of the core configuration file. The format of
the configuration file is basic JSON. See the [core configuration
page](/docs/other/core-configuration.html).
- `PACKER_CONFIG` - The location of the core configuration file. The format of
the configuration file is basic JSON. See the [core configuration
page](/docs/other/core-configuration.html).
- `PACKER_LOG` - Setting this to any value will enable the logger. See the
[debugging page](/docs/other/debugging.html).
- `PACKER_LOG` - Setting this to any value will enable the logger. See the
[debugging page](/docs/other/debugging.html).
- `PACKER_LOG_PATH` - The location of the log file. Note: `PACKER_LOG` must be
set for any logging to occur. See the [debugging
page](/docs/other/debugging.html).
- `PACKER_LOG_PATH` - The location of the log file. Note: `PACKER_LOG` must be
set for any logging to occur. See the [debugging
page](/docs/other/debugging.html).
- `PACKER_NO_COLOR` - Setting this to any value will disable color in
the terminal.
- `PACKER_NO_COLOR` - Setting this to any value will disable color in
the terminal.
- `PACKER_PLUGIN_MAX_PORT` - The maximum port that Packer uses for communication
with plugins, since plugin communication happens over TCP connections on your
local host. The default is 25,000. See the [core configuration
page](/docs/other/core-configuration.html).
- `PACKER_PLUGIN_MAX_PORT` - The maximum port that Packer uses for
communication with plugins, since plugin communication happens over TCP
connections on your local host. The default is 25,000. See the [core
configuration page](/docs/other/core-configuration.html).
- `PACKER_PLUGIN_MIN_PORT` - The minimum port that Packer uses for communication
with plugins, since plugin communication happens over TCP connections on your
local host. The default is 10,000. See the [core configuration
page](/docs/other/core-configuration.html).
- `PACKER_PLUGIN_MIN_PORT` - The minimum port that Packer uses for
communication with plugins, since plugin communication happens over TCP
connections on your local host. The default is 10,000. See the [core
configuration page](/docs/other/core-configuration.html).
website/source/docs/post-processors/atlas.html.markdown
View file @ d8e8f98b
......@@ -25,14 +25,14 @@ location in Atlas.
Here is an example workflow:
1. Packer builds an AMI with the [Amazon AMI
builder](/docs/builders/amazon.html)
2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
The `atlas` post-processor is configured with the name of the AMI, for example
`hashicorp/foobar`, to create the artifact in Atlas or update the version if
the artifact already exists
3. The new version is ready and available to be used in deployments with a tool
like [Terraform](https://terraform.io)
1. Packer builds an AMI with the [Amazon AMI
builder](/docs/builders/amazon.html)
2. The `atlas` post-processor takes the resulting AMI and uploads it to Atlas.
The `atlas` post-processor is configured with the name of the AMI, for
example `hashicorp/foobar`, to create the artifact in Atlas or update the
version if the artifact already exists
3. The new version is ready and available to be used in deployments with a tool
like [Terraform](https://terraform.io)
## Configuration
......@@ -40,32 +40,33 @@ The configuration allows you to specify and access the artifact in Atlas.
### Required:
- `token` (string) - Your access token for the Atlas API. This can be generated
on your [tokens page](https://atlas.hashicorp.com/settings/tokens).
Alternatively you can export your Atlas token as an environmental variable and
remove it from the configuration.
- `token` (string) - Your access token for the Atlas API. This can be
generated on your [tokens
page](https://atlas.hashicorp.com/settings/tokens). Alternatively you can
export your Atlas token as an environmental variable and remove it from
the configuration.
- `artifact` (string) - The shorthand tag for your artifact that maps to Atlas,
i.e `hashicorp/foobar` for `atlas.hashicorp.com/hashicorp/foobar`. You must
have access to the organization, hashicorp in this example, in order to add an
artifact to the organization in Atlas.
- `artifact` (string) - The shorthand tag for your artifact that maps to
Atlas, i.e `hashicorp/foobar` for `atlas.hashicorp.com/hashicorp/foobar`.
You must have access to the organization, hashicorp in this example, in
order to add an artifact to the organization in Atlas.
- `artifact_type` (string) - For uploading AMIs to Atlas, `artifact_type` will
always be `amazon.ami`. This field must be defined because Atlas can host
other artifact types, such as Vagrant boxes.
- `artifact_type` (string) - For uploading AMIs to Atlas, `artifact_type` will
always be `amazon.ami`. This field must be defined because Atlas can host
other artifact types, such as Vagrant boxes.
-&gt; **Note:** If you want to upload Vagrant boxes to Atlas, use the [Atlas
post-processor](/docs/post-processors/atlas.html).
### Optional:
- `atlas_url` (string) - Override the base URL for Atlas. This is useful if
you're using Atlas Enterprise in your own network. Defaults to
`https://atlas.hashicorp.com/api/v1`.
- `atlas_url` (string) - Override the base URL for Atlas. This is useful if
you're using Atlas Enterprise in your own network. Defaults to
`https://atlas.hashicorp.com/api/v1`.
- `metadata` (map) - Send metadata about the artifact. If the artifact type is
"vagrant.box", you must specify a "provider" metadata about what provider
to use.
- `metadata` (map) - Send metadata about the artifact. If the artifact type is
"vagrant.box", you must specify a "provider" metadata about what provider
to use.
### Example Configuration
......
website/source/docs/post-processors/compress.html.markdown
View file @ d8e8f98b
......@@ -20,25 +20,25 @@ VMware or VirtualBox) and compresses the artifact into a single archive.
You must specify the output filename. The archive format is derived from the
filename.
- `output` (string) - The path to save the compressed archive. The archive
format is inferred from the filename. E.g. `.tar.gz` will be a
gzipped tarball. `.zip` will be a zip file. If the extension can't be detected
packer defaults to `.tar.gz` behavior but will not change the filename.
- `output` (string) - The path to save the compressed archive. The archive
format is inferred from the filename. E.g. `.tar.gz` will be a
gzipped tarball. `.zip` will be a zip file. If the extension can't be
detected packer defaults to `.tar.gz` behavior but will not change
the filename.
If you are executing multiple builders in parallel you should make sure
`output` is unique for each one. For example
`packer_{{.BuildName}}_{{.Provider}}.zip`.
If you are executing multiple builders in parallel you should make sure `output`
is unique for each one. For example `packer_{{.BuildName}}_{{.Provider}}.zip`.
### Optional:
If you want more control over how the archive is created you can specify the
following settings:
- `compression_level` (integer) - Specify the compression level, for algorithms
that support it, from 1 through 9 inclusive. Typically higher compression
levels take longer but produce smaller files. Defaults to `6`
- `compression_level` (integer) - Specify the compression level, for
algorithms that support it, from 1 through 9 inclusive. Typically higher
compression levels take longer but produce smaller files. Defaults to `6`
- `keep_input_artifact` (boolean) - Keep source files; defaults to `false`
- `keep_input_artifact` (boolean) - Keep source files; defaults to `false`
### Supported Formats
......
website/source/docs/post-processors/docker-import.html.markdown
View file @ d8e8f98b
......@@ -24,9 +24,9 @@ registry.
The configuration for this post-processor is extremely simple. At least a
repository is required.
- `repository` (string) - The repository of the imported image.
- `repository` (string) - The repository of the imported image.
- `tag` (string) - The tag for the imported image. By default this is not set.
- `tag` (string) - The tag for the imported image. By default this is not set.
## Example
......
website/source/docs/post-processors/docker-push.html.markdown
View file @ d8e8f98b
......@@ -18,16 +18,16 @@ pushes it to a Docker registry.
This post-processor has only optional configuration:
- `login` (boolean) - Defaults to false. If true, the post-processor will login
prior to pushing.
- `login` (boolean) - Defaults to false. If true, the post-processor will
login prior to pushing.
- `login_email` (string) - The email to use to authenticate to login.
- `login_email` (string) - The email to use to authenticate to login.
- `login_username` (string) - The username to use to authenticate to login.
- `login_username` (string) - The username to use to authenticate to login.
- `login_password` (string) - The password to use to authenticate to login.
- `login_password` (string) - The password to use to authenticate to login.
- `login_server` (string) - The server address to login to.
- `login_server` (string) - The server address to login to.
-&gt; **Note:** If you login using the credentials above, the post-processor
will automatically log you out afterwards (just the server specified).
......
website/source/docs/post-processors/docker-save.html.markdown
View file @ d8e8f98b
......@@ -25,7 +25,7 @@ familiar with this and vice versa.
The configuration for this post-processor is extremely simple.
- `path` (string) - The path to save the image.
- `path` (string) - The path to save the image.
## Example
......
website/source/docs/post-processors/docker-tag.html.markdown
View file @ d8e8f98b
......@@ -27,12 +27,12 @@ that this works with committed resources, rather than exported.
The configuration for this post-processor is extremely simple. At least a
repository is required.
- `repository` (string) - The repository of the image.
- `repository` (string) - The repository of the image.
- `tag` (string) - The tag for the image. By default this is not set.
- `tag` (string) - The tag for the image. By default this is not set.
- `force` (boolean) - If true, this post-processor forcibly tag the image even
if tag name is collided. Default to `false`.
- `force` (boolean) - If true, this post-processor forcibly tag the image even
if tag name is collided. Default to `false`.
## Example
......
website/source/docs/post-processors/vagrant-cloud.html.markdown
View file @ d8e8f98b
......@@ -36,16 +36,16 @@ and deliver them to your team in some fashion.
Here is an example workflow:
1. You use Packer to build a Vagrant Box for the `virtualbox` provider
2. The `vagrant-cloud` post-processor is configured to point to the box
`hashicorp/foobar` on Vagrant Cloud via the `box_tag` configuration
3. The post-processor receives the box from the `vagrant` post-processor
4. It then creates the configured version, or verifies the existence of it, on
Vagrant Cloud
5. A provider matching the name of the Vagrant provider is then created
6. The box is uploaded to Vagrant Cloud
7. The upload is verified
8. The version is released and available to users of the box
1. You use Packer to build a Vagrant Box for the `virtualbox` provider
2. The `vagrant-cloud` post-processor is configured to point to the box
`hashicorp/foobar` on Vagrant Cloud via the `box_tag` configuration
3. The post-processor receives the box from the `vagrant` post-processor
4. It then creates the configured version, or verifies the existence of it, on
Vagrant Cloud
5. A provider matching the name of the Vagrant provider is then created
6. The box is uploaded to Vagrant Cloud
7. The upload is verified
8. The version is released and available to users of the box
## Configuration
......@@ -54,35 +54,35 @@ on Vagrant Cloud, as well as authentication and version information.
### Required:
- `access_token` (string) - Your access token for the Vagrant Cloud API. This
can be generated on your [tokens
page](https://vagrantcloud.com/account/tokens).
- `access_token` (string) - Your access token for the Vagrant Cloud API. This
can be generated on your [tokens
page](https://vagrantcloud.com/account/tokens).
- `box_tag` (string) - The shorthand tag for your box that maps to Vagrant
Cloud, i.e `hashicorp/precise64` for `vagrantcloud.com/hashicorp/precise64`
- `box_tag` (string) - The shorthand tag for your box that maps to Vagrant
Cloud, i.e `hashicorp/precise64` for `vagrantcloud.com/hashicorp/precise64`
- `version` (string) - The version number, typically incrementing a
previous version. The version string is validated based on [Semantic
Versioning](http://semver.org/). The string must match a pattern that could be
semver, and doesn't validate that the version comes after your
previous versions.
- `version` (string) - The version number, typically incrementing a
previous version. The version string is validated based on [Semantic
Versioning](http://semver.org/). The string must match a pattern that could
be semver, and doesn't validate that the version comes after your
previous versions.
### Optional:
- `no_release` (string) - If set to true, does not release the version on
Vagrant Cloud, making it active. You can manually release the version via the
API or Web UI. Defaults to false.
- `no_release` (string) - If set to true, does not release the version on
Vagrant Cloud, making it active. You can manually release the version via
the API or Web UI. Defaults to false.
- `vagrant_cloud_url` (string) - Override the base URL for Vagrant Cloud. This
is useful if you're using Vagrant Private Cloud in your own network. Defaults
to `https://vagrantcloud.com/api/v1`
- `vagrant_cloud_url` (string) - Override the base URL for Vagrant Cloud. This
is useful if you're using Vagrant Private Cloud in your own network.
Defaults to `https://vagrantcloud.com/api/v1`
- `version_description` (string) - Optionally markdown text used as a
full-length and in-depth description of the version, typically for denoting
changes introduced
- `version_description` (string) - Optionally markdown text used as a
full-length and in-depth description of the version, typically for denoting
changes introduced
- `box_download_url` (string) - Optional URL for a self-hosted box. If this is
set the box will not be uploaded to the Vagrant Cloud.
- `box_download_url` (string) - Optional URL for a self-hosted box. If this is
set the box will not be uploaded to the Vagrant Cloud.
## Use with Vagrant Post-Processor
......
website/source/docs/post-processors/vagrant.html.markdown
View file @ d8e8f98b
......@@ -29,13 +29,13 @@ certain builders into proper boxes for their respective providers.
Currently, the Vagrant post-processor can create boxes for the following
providers.
- AWS
- DigitalOcean
- Hyper-V
- Parallels
- QEMU
- VirtualBox
- VMware
- AWS
- DigitalOcean
- Hyper-V
- Parallels
- QEMU
- VirtualBox
- VMware
-&gt; **Support for additional providers** is planned. If the Vagrant
post-processor doesn't support creating boxes for a provider you care about,
......@@ -51,28 +51,28 @@ However, if you want to configure things a bit more, the post-processor does
expose some configuration options. The available options are listed below, with
more details about certain options in following sections.
- `compression_level` (integer) - An integer representing the compression level
to use when creating the Vagrant box. Valid values range from 0 to 9, with 0
being no compression and 9 being the best compression. By default, compression
is enabled at level 6.
- `compression_level` (integer) - An integer representing the compression
level to use when creating the Vagrant box. Valid values range from 0 to 9,
with 0 being no compression and 9 being the best compression. By default,
compression is enabled at level 6.
- `include` (array of strings) - Paths to files to include in the Vagrant box.
These files will each be copied into the top level directory of the Vagrant
box (regardless of their paths). They can then be used from the Vagrantfile.
- `include` (array of strings) - Paths to files to include in the Vagrant box.
These files will each be copied into the top level directory of the Vagrant
box (regardless of their paths). They can then be used from the Vagrantfile.
- `keep_input_artifact` (boolean) - If set to true, do not delete the
`output_directory` on a successful build. Defaults to false.
- `keep_input_artifact` (boolean) - If set to true, do not delete the
`output_directory` on a successful build. Defaults to false.
- `output` (string) - The full path to the box file that will be created by
this post-processor. This is a [configuration
template](/docs/templates/configuration-templates.html). The variable
`Provider` is replaced by the Vagrant provider the box is for. The variable
`ArtifactId` is replaced by the ID of the input artifact. The variable
`BuildName` is replaced with the name of the build. By default, the value of
this config is `packer_{{.BuildName}}_{{.Provider}}.box`.
- `output` (string) - The full path to the box file that will be created by
this post-processor. This is a [configuration
template](/docs/templates/configuration-templates.html). The variable
`Provider` is replaced by the Vagrant provider the box is for. The variable
`ArtifactId` is replaced by the ID of the input artifact. The variable
`BuildName` is replaced with the name of the build. By default, the value of
this config is `packer_{{.BuildName}}_{{.Provider}}.box`.
- `vagrantfile_template` (string) - Path to a template to use for the
Vagrantfile that is packaged with the box.
- `vagrantfile_template` (string) - Path to a template to use for the
Vagrantfile that is packaged with the box.
## Provider-Specific Overrides
......
website/source/docs/post-processors/vsphere.html.markdown
View file @ d8e8f98b
......@@ -21,35 +21,36 @@ each category, the available configuration keys are alphabetized.
Required:
- `cluster` (string) - The cluster to upload the VM to.
- `cluster` (string) - The cluster to upload the VM to.
- `datacenter` (string) - The name of the datacenter within vSphere to add the
VM to.
- `datacenter` (string) - The name of the datacenter within vSphere to add the
VM to.
- `datastore` (string) - The name of the datastore to store this VM. This is
*not required* if `resource_pool` is specified.
- `datastore` (string) - The name of the datastore to store this VM. This is
*not required* if `resource_pool` is specified.
- `host` (string) - The vSphere host that will be contacted to perform the
VM upload.
- `host` (string) - The vSphere host that will be contacted to perform the
VM upload.
- `password` (string) - Password to use to authenticate to the vSphere endpoint.
- `password` (string) - Password to use to authenticate to the
vSphere endpoint.
- `resource_pool` (string) - The resource pool to upload the VM to. This is *not
required*.
- `resource_pool` (string) - The resource pool to upload the VM to. This is
*not required*.
- `username` (string) - The username to use to authenticate to the
vSphere endpoint.
- `username` (string) - The username to use to authenticate to the
vSphere endpoint.
- `vm_name` (string) - The name of the VM once it is uploaded.
- `vm_name` (string) - The name of the VM once it is uploaded.
Optional:
- `disk_mode` (string) - Target disk format. See `ovftool` manual for
available options. By default, "thick" will be used.
- `disk_mode` (string) - Target disk format. See `ovftool` manual for
available options. By default, "thick" will be used.
- `insecure` (boolean) - Whether or not the connection to vSphere can be done
over an insecure connection. By default this is false.
- `insecure` (boolean) - Whether or not the connection to vSphere can be done
over an insecure connection. By default this is false.
- `vm_folder` (string) - The folder within the datastore to store the VM.
- `vm_folder` (string) - The folder within the datastore to store the VM.
- `vm_network` (string) - The name of the VM network this VM will be added to.
- `vm_network` (string) - The name of the VM network this VM will be added to.
website/source/docs/provisioners/ansible-local.html.markdown
View file @ d8e8f98b
......@@ -35,83 +35,70 @@ The reference of available configuration options is listed below.
Required:
- `playbook_file` (string) - The playbook file to be executed by ansible. This
file must exist on your local system and will be uploaded to the
remote machine.
- `playbook_file` (string) - The playbook file to be executed by ansible. This
file must exist on your local system and will be uploaded to the
remote machine.
Optional:
- `command` (string) - The command to invoke ansible. Defaults
to "ansible-playbook".
- `command` (string) - The command to invoke ansible. Defaults
to "ansible-playbook".
- `extra_arguments` (array of strings) - An array of extra arguments to pass to
the ansible command. By default, this is empty.
- `extra_arguments` (array of strings) - An array of extra arguments to pass
to the ansible command. By default, this is empty.
- `inventory_groups` (string) - A comma-separated list of groups to which packer
will assign the host `127.0.0.1`. A value of `my_group_1,my_group_2` will
generate an Ansible inventory like:
- `inventory_groups` (string) - A comma-separated list of groups to which
packer will assign the host `127.0.0.1`. A value of `my_group_1,my_group_2`
will generate an Ansible inventory like:
``` {.text}
[my_group_1]
127.0.0.1
[my_group_2]
127.0.0.1
```
`{.text} [my_group_1] 127.0.0.1 [my_group_2] 127.0.0.1`
- `inventory_file` (string) - The inventory file to be used by ansible. This
file must exist on your local system and will be uploaded to the
remote machine.
- `inventory_file` (string) - The inventory file to be used by ansible. This
file must exist on your local system and will be uploaded to the
remote machine.
When using an inventory file, it's also required to `--limit` the hosts to the
specified host you're buiding. The `--limit` argument can be provided in the
`extra_arguments` option.
When using an inventory file, it's also required to `--limit` the hosts to the
specified host you're buiding. The `--limit` argument can be provided in the
`extra_arguments` option.
An example inventory file may look like:
An example inventory file may look like:
``` {.text}
[chi-dbservers]
db-01 ansible_connection=local
db-02 ansible_connection=local
\`\`\` {.text} \[chi-dbservers\] db-01 ansible\_connection=local db-02
ansible\_connection=local
[chi-appservers]
app-01 ansible_connection=local
app-02 ansible_connection=local
\[chi-appservers\] app-01 ansible\_connection=local app-02
ansible\_connection=local
[chi:children]
chi-dbservers
chi-appservers
\[chi:children\] chi-dbservers chi-appservers
[dbservers:children]
chi-dbservers
\[dbservers:children\] chi-dbservers
[appservers:children]
chi-appservers
```
\[appservers:children\] chi-appservers \`\`\`
- `playbook_dir` (string) - a path to the complete ansible directory structure
on your local system to be copied to the remote machine as the
`staging_directory` before all other files and directories.
- `playbook_dir` (string) - a path to the complete ansible directory structure
on your local system to be copied to the remote machine as the
`staging_directory` before all other files and directories.
- `playbook_paths` (array of strings) - An array of paths to playbook files on
your local system. These will be uploaded to the remote machine under
`staging_directory`/playbooks. By default, this is empty.
- `playbook_paths` (array of strings) - An array of paths to playbook files on
your local system. These will be uploaded to the remote machine under
`staging_directory`/playbooks. By default, this is empty.
- `group_vars` (string) - a path to the directory containing ansible group
variables on your local system to be copied to the remote machine. By default,
this is empty.
- `group_vars` (string) - a path to the directory containing ansible group
variables on your local system to be copied to the remote machine. By
default, this is empty.
- `host_vars` (string) - a path to the directory containing ansible host
variables on your local system to be copied to the remote machine. By default,
this is empty.
- `host_vars` (string) - a path to the directory containing ansible host
variables on your local system to be copied to the remote machine. By
default, this is empty.
- `role_paths` (array of strings) - An array of paths to role directories on
your local system. These will be uploaded to the remote machine under
`staging_directory`/roles. By default, this is empty.
- `role_paths` (array of strings) - An array of paths to role directories on
your local system. These will be uploaded to the remote machine under
`staging_directory`/roles. By default, this is empty.
- `staging_directory` (string) - The directory where all the configuration of
Ansible by Packer will be placed. By default this
is "/tmp/packer-provisioner-ansible-local". This directory doesn't need to
exist but must have proper permissions so that the SSH user that Packer uses
is able to create directories and write into this folder. If the permissions
are not correct, use a shell provisioner prior to this to configure
it properly.
- `staging_directory` (string) - The directory where all the configuration of
Ansible by Packer will be placed. By default this
is "/tmp/packer-provisioner-ansible-local". This directory doesn't need to
exist but must have proper permissions so that the SSH user that Packer uses
is able to create directories and write into this folder. If the permissions
are not correct, use a shell provisioner prior to this to configure
it properly.
website/source/docs/provisioners/chef-client.html.markdown
View file @ d8e8f98b
......@@ -40,70 +40,71 @@ is running must have knife on the path and configured globally, i.e,
The reference of available configuration options is listed below. No
configuration is actually required.
- `chef_environment` (string) - The name of the chef\_environment sent to the
Chef server. By default this is empty and will not use an environment.
- `chef_environment` (string) - The name of the chef\_environment sent to the
Chef server. By default this is empty and will not use an environment.
- `config_template` (string) - Path to a template that will be used for the Chef
configuration file. By default Packer only sets configuration it needs to
match the settings set in the provisioner configuration. If you need to set
configurations that the Packer provisioner doesn't support, then you should
use a custom configuration template. See the dedicated "Chef Configuration"
section below for more details.
- `config_template` (string) - Path to a template that will be used for the
Chef configuration file. By default Packer only sets configuration it needs
to match the settings set in the provisioner configuration. If you need to
set configurations that the Packer provisioner doesn't support, then you
should use a custom configuration template. See the dedicated "Chef
Configuration" section below for more details.
- `execute_command` (string) - The command used to execute Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See below
for more information.
- `execute_command` (string) - The command used to execute Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See
below for more information.
- `install_command` (string) - The command used to install Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See below
for more information.
- `install_command` (string) - The command used to install Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See
below for more information.
- `json` (object) - An arbitrary mapping of JSON that will be available as node
attributes while running Chef.
- `json` (object) - An arbitrary mapping of JSON that will be available as
node attributes while running Chef.
- `node_name` (string) - The name of the node to register with the Chef Server.
This is optional and by default is packer-{{uuid}}.
- `node_name` (string) - The name of the node to register with the
Chef Server. This is optional and by default is packer-{{uuid}}.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to install and run Chef are executed with `sudo`. If this is true,
then the sudo will be omitted.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to install and run Chef are executed with `sudo`. If this is true,
then the sudo will be omitted.
- `run_list` (array of strings) - The [run
list](http://docs.opscode.com/essentials_node_object_run_lists.html) for Chef.
By default this is empty, and will use the run list sent down by the
Chef Server.
- `run_list` (array of strings) - The [run
list](http://docs.opscode.com/essentials_node_object_run_lists.html)
for Chef. By default this is empty, and will use the run list sent down by
the Chef Server.
- `server_url` (string) - The URL to the Chef server. This is required.
- `server_url` (string) - The URL to the Chef server. This is required.
- `skip_clean_client` (boolean) - If true, Packer won't remove the client from
the Chef server after it is done running. By default, this is false.
- `skip_clean_client` (boolean) - If true, Packer won't remove the client from
the Chef server after it is done running. By default, this is false.
- `skip_clean_node` (boolean) - If true, Packer won't remove the node from the
Chef server after it is done running. By default, this is false.
- `skip_clean_node` (boolean) - If true, Packer won't remove the node from the
Chef server after it is done running. By default, this is false.
- `skip_install` (boolean) - If true, Chef will not automatically be installed
on the machine using the Opscode omnibus installers.
- `skip_install` (boolean) - If true, Chef will not automatically be installed
on the machine using the Opscode omnibus installers.
- `staging_directory` (string) - This is the directory where all the
configuration of Chef by Packer will be placed. By default this
is "/tmp/packer-chef-client". This directory doesn't need to exist but must
have proper permissions so that the SSH user that Packer uses is able to
create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
- `staging_directory` (string) - This is the directory where all the
configuration of Chef by Packer will be placed. By default this
is "/tmp/packer-chef-client". This directory doesn't need to exist but must
have proper permissions so that the SSH user that Packer uses is able to
create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
- `client_key` (string) - Path to client key. If not set, this defaults to a
file named client.pem in `staging_directory`.
- `client_key` (string) - Path to client key. If not set, this defaults to a
file named client.pem in `staging_directory`.
- `validation_client_name` (string) - Name of the validation client. If not set,
this won't be set in the configuration and the default that Chef uses will
be used.
- `validation_client_name` (string) - Name of the validation client. If not
set, this won't be set in the configuration and the default that Chef uses
will be used.
- `validation_key_path` (string) - Path to the validation key for communicating
with the Chef Server. This will be uploaded to the remote machine. If this is
NOT set, then it is your responsibility via other means (shell
provisioner, etc.) to get a validation key to where Chef expects it.
- `validation_key_path` (string) - Path to the validation key for
communicating with the Chef Server. This will be uploaded to the
remote machine. If this is NOT set, then it is your responsibility via other
means (shell provisioner, etc.) to get a validation key to where Chef
expects it.
## Chef Configuration
......@@ -135,9 +136,9 @@ This template is a [configuration
template](/docs/templates/configuration-templates.html) and has a set of
variables available to use:
- `NodeName` - The node name set in the configuration.
- `ServerUrl` - The URL of the Chef Server set in the configuration.
- `ValidationKeyPath` - Path to the validation key, if it is set.
- `NodeName` - The node name set in the configuration.
- `ServerUrl` - The URL of the Chef Server set in the configuration.
- `ValidationKeyPath` - Path to the validation key, if it is set.
## Execute Command
......@@ -155,10 +156,10 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
- `ConfigPath` - The path to the Chef configuration file. file.
- `JsonPath` - The path to the JSON attributes file for the node.
- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
value of the `prevent_sudo` configuration.
- `ConfigPath` - The path to the Chef configuration file. file.
- `JsonPath` - The path to the JSON attributes file for the node.
- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
value of the `prevent_sudo` configuration.
## Install Command
......
website/source/docs/provisioners/chef-solo.html.markdown
View file @ d8e8f98b
......@@ -36,71 +36,72 @@ directory relative to your working directory.
The reference of available configuration options is listed below. No
configuration is actually required, but at least `run_list` is recommended.
- `chef_environment` (string) - The name of the `chef_environment` sent to the
Chef server. By default this is empty and will not use an environment
- `config_template` (string) - Path to a template that will be used for the Chef
configuration file. By default Packer only sets configuration it needs to
match the settings set in the provisioner configuration. If you need to set
configurations that the Packer provisioner doesn't support, then you should
use a custom configuration template. See the dedicated "Chef Configuration"
section below for more details.
- `cookbook_paths` (array of strings) - This is an array of paths to "cookbooks"
directories on your local filesystem. These will be uploaded to the remote
machine in the directory specified by the `staging_directory`. By default,
this is empty.
- `data_bags_path` (string) - The path to the "data\_bags" directory on your
local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `encrypted_data_bag_secret_path` (string) - The path to the file containing
the secret for encrypted data bags. By default, this is empty, so no secret
will be available.
- `environments_path` (string) - The path to the "environments" directory on
your local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `execute_command` (string) - The command used to execute Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See below
for more information.
- `install_command` (string) - The command used to install Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See below
for more information.
- `json` (object) - An arbitrary mapping of JSON that will be available as node
attributes while running Chef.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to install and run Chef are executed with `sudo`. If this is true,
then the sudo will be omitted.
- `remote_cookbook_paths` (array of strings) - A list of paths on the remote
machine where cookbooks will already exist. These may exist from a previous
provisioner or step. If specified, Chef will be configured to look for
cookbooks here. By default, this is empty.
- `roles_path` (string) - The path to the "roles" directory on your
local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `run_list` (array of strings) - The [run
list](https://docs.chef.io/run_lists.html) for Chef. By default this is empty.
- `skip_install` (boolean) - If true, Chef will not automatically be installed
on the machine using the Chef omnibus installers.
- `staging_directory` (string) - This is the directory where all the
configuration of Chef by Packer will be placed. By default this
is "/tmp/packer-chef-solo". This directory doesn't need to exist but must have
proper permissions so that the SSH user that Packer uses is able to create
directories and write into this folder. If the permissions are not correct,
use a shell provisioner prior to this to configure it properly.
- `chef_environment` (string) - The name of the `chef_environment` sent to the
Chef server. By default this is empty and will not use an environment
- `config_template` (string) - Path to a template that will be used for the
Chef configuration file. By default Packer only sets configuration it needs
to match the settings set in the provisioner configuration. If you need to
set configurations that the Packer provisioner doesn't support, then you
should use a custom configuration template. See the dedicated "Chef
Configuration" section below for more details.
- `cookbook_paths` (array of strings) - This is an array of paths to
"cookbooks" directories on your local filesystem. These will be uploaded to
the remote machine in the directory specified by the `staging_directory`. By
default, this is empty.
- `data_bags_path` (string) - The path to the "data\_bags" directory on your
local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `encrypted_data_bag_secret_path` (string) - The path to the file containing
the secret for encrypted data bags. By default, this is empty, so no secret
will be available.
- `environments_path` (string) - The path to the "environments" directory on
your local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `execute_command` (string) - The command used to execute Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See
below for more information.
- `install_command` (string) - The command used to install Chef. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See
below for more information.
- `json` (object) - An arbitrary mapping of JSON that will be available as
node attributes while running Chef.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to install and run Chef are executed with `sudo`. If this is true,
then the sudo will be omitted.
- `remote_cookbook_paths` (array of strings) - A list of paths on the remote
machine where cookbooks will already exist. These may exist from a previous
provisioner or step. If specified, Chef will be configured to look for
cookbooks here. By default, this is empty.
- `roles_path` (string) - The path to the "roles" directory on your
local filesystem. These will be uploaded to the remote machine in the
directory specified by the `staging_directory`. By default, this is empty.
- `run_list` (array of strings) - The [run
list](https://docs.chef.io/run_lists.html) for Chef. By default this
is empty.
- `skip_install` (boolean) - If true, Chef will not automatically be installed
on the machine using the Chef omnibus installers.
- `staging_directory` (string) - This is the directory where all the
configuration of Chef by Packer will be placed. By default this
is "/tmp/packer-chef-solo". This directory doesn't need to exist but must
have proper permissions so that the SSH user that Packer uses is able to
create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
## Chef Configuration
......@@ -119,14 +120,14 @@ This template is a [configuration
template](/docs/templates/configuration-templates.html) and has a set of
variables available to use:
- `ChefEnvironment` - The current enabled environment. Only non-empty if the
environment path is set.
- `CookbookPaths` is the set of cookbook paths ready to embedded directly into a
Ruby array to configure Chef.
- `DataBagsPath` is the path to the data bags folder.
- `EncryptedDataBagSecretPath` - The path to the encrypted data bag secret
- `EnvironmentsPath` - The path to the environments folder.
- `RolesPath` - The path to the roles folder.
- `ChefEnvironment` - The current enabled environment. Only non-empty if the
environment path is set.
- `CookbookPaths` is the set of cookbook paths ready to embedded directly into
a Ruby array to configure Chef.
- `DataBagsPath` is the path to the data bags folder.
- `EncryptedDataBagSecretPath` - The path to the encrypted data bag secret
- `EnvironmentsPath` - The path to the environments folder.
- `RolesPath` - The path to the roles folder.
## Execute Command
......@@ -144,10 +145,10 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
- `ConfigPath` - The path to the Chef configuration file. file.
- `JsonPath` - The path to the JSON attributes file for the node.
- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
value of the `prevent_sudo` configuration.
- `ConfigPath` - The path to the Chef configuration file. file.
- `JsonPath` - The path to the JSON attributes file for the node.
- `Sudo` - A boolean of whether to `sudo` the command or not, depending on the
value of the `prevent_sudo` configuration.
## Install Command
......
website/source/docs/provisioners/file.html.markdown
View file @ d8e8f98b
......@@ -32,19 +32,19 @@ The file provisioner can upload both single files and complete directories.
The available configuration options are listed below. All elements are required.
- `source` (string) - The path to a local file or directory to upload to
the machine. The path can be absolute or relative. If it is relative, it is
relative to the working directory when Packer is executed. If this is a
directory, the existence of a trailing slash is important. Read below on
uploading directories.
- `destination` (string) - The path where the file will be uploaded to in
the machine. This value must be a writable location and any parent directories
must already exist.
- `direction` (string) - The direction of the file transfer. This defaults to
"upload." If it is set to "download" then the file "source" in the machine wll
be downloaded locally to "destination"
- `source` (string) - The path to a local file or directory to upload to
the machine. The path can be absolute or relative. If it is relative, it is
relative to the working directory when Packer is executed. If this is a
directory, the existence of a trailing slash is important. Read below on
uploading directories.
- `destination` (string) - The path where the file will be uploaded to in
the machine. This value must be a writable location and any parent
directories must already exist.
- `direction` (string) - The direction of the file transfer. This defaults to
"upload." If it is set to "download" then the file "source" in the machine
wll be downloaded locally to "destination"
## Directory Uploads
......
website/source/docs/provisioners/powershell.html.markdown
View file @ d8e8f98b
......@@ -32,52 +32,53 @@ required element is either "inline" or "script". Every other option is optional.
Exactly *one* of the following is required:
- `inline` (array of strings) - This is an array of commands to execute. The
commands are concatenated by newlines and turned into a single file, so they
are all executed within the same context. This allows you to change
directories in one command and use something in the directory in the next and
so on. Inline scripts are the easiest way to pull off simple tasks within
the machine.
- `script` (string) - The path to a script to upload and execute in the machine.
This path can be absolute or relative. If it is relative, it is relative to
the working directory when Packer is executed.
- `scripts` (array of strings) - An array of scripts to execute. The scripts
will be uploaded and executed in the order specified. Each script is executed
in isolation, so state such as variables from one script won't carry on to
the next.
- `inline` (array of strings) - This is an array of commands to execute. The
commands are concatenated by newlines and turned into a single file, so they
are all executed within the same context. This allows you to change
directories in one command and use something in the directory in the next
and so on. Inline scripts are the easiest way to pull off simple tasks
within the machine.
- `script` (string) - The path to a script to upload and execute in
the machine. This path can be absolute or relative. If it is relative, it is
relative to the working directory when Packer is executed.
- `scripts` (array of strings) - An array of scripts to execute. The scripts
will be uploaded and executed in the order specified. Each script is
executed in isolation, so state such as variables from one script won't
carry on to the next.
Optional parameters:
- `binary` (boolean) - If true, specifies that the script(s) are binary files,
and Packer should therefore not convert Windows line endings to Unix line
endings (if there are any). By default this is false.
- `environment_vars` (array of strings) - An array of key/value pairs to inject
prior to the execute\_command. The format should be `key=value`. Packer
injects some environmental variables by default into the environment, as well,
which are covered in the section below.
- `execute_command` (string) - The command to use to execute the script. By
default this is `powershell "& { {{.Vars}}{{.Path}}; exit $LastExitCode}"`.
The value of this is treated as [configuration
template](/docs/templates/configuration-templates.html). There are two
available variables: `Path`, which is the path to the script to run, and
`Vars`, which is the list of `environment_vars`, if configured.
- `elevated_user` and `elevated_password` (string) - If specified, the
PowerShell script will be run with elevated privileges using the given
Windows user.
- `remote_path` (string) - The path where the script will be uploaded to in
the machine. This defaults to "/tmp/script.sh". This value must be a writable
location and any parent directories must already exist.
- `start_retry_timeout` (string) - The amount of time to attempt to *start* the
remote process. By default this is "5m" or 5 minutes. This setting exists in
order to deal with times when SSH may restart, such as a system reboot. Set
this to a higher value if reboots take a longer amount of time.
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
default this is just 0.
- `binary` (boolean) - If true, specifies that the script(s) are binary files,
and Packer should therefore not convert Windows line endings to Unix line
endings (if there are any). By default this is false.
- `environment_vars` (array of strings) - An array of key/value pairs to
inject prior to the execute\_command. The format should be `key=value`.
Packer injects some environmental variables by default into the environment,
as well, which are covered in the section below.
- `execute_command` (string) - The command to use to execute the script. By
default this is `powershell "& { {{.Vars}}{{.Path}}; exit $LastExitCode}"`.
The value of this is treated as [configuration
template](/docs/templates/configuration-templates.html). There are two
available variables: `Path`, which is the path to the script to run, and
`Vars`, which is the list of `environment_vars`, if configured.
- `elevated_user` and `elevated_password` (string) - If specified, the
PowerShell script will be run with elevated privileges using the given
Windows user.
- `remote_path` (string) - The path where the script will be uploaded to in
the machine. This defaults to "/tmp/script.sh". This value must be a
writable location and any parent directories must already exist.
- `start_retry_timeout` (string) - The amount of time to attempt to *start*
the remote process. By default this is "5m" or 5 minutes. This setting
exists in order to deal with times when SSH may restart, such as a
system reboot. Set this to a higher value if reboots take a longer amount
of time.
- `valid_exit_codes` (list of ints) - Valid exit codes for the script. By
default this is just 0.
website/source/docs/provisioners/puppet-masterless.html.markdown
View file @ d8e8f98b
......@@ -45,59 +45,58 @@ The reference of available configuration options is listed below.
Required parameters:
- `manifest_file` (string) - This is either a path to a puppet manifest
(`.pp` file) *or* a directory containing multiple manifests that puppet will
apply (the ["main
manifest"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)).
These file(s) must exist on your local system and will be uploaded to the
remote machine.
- `manifest_file` (string) - This is either a path to a puppet manifest
(`.pp` file) *or* a directory containing multiple manifests that puppet will
apply (the ["main
manifest"](https://docs.puppetlabs.com/puppet/latest/reference/dirs_manifest.html)).
These file(s) must exist on your local system and will be uploaded to the
remote machine.
Optional parameters:
- `execute_command` (string) - The command used to execute Puppet. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See below
for more information.
- `facter` (object of key/value strings) - Additional
[facts](http://puppetlabs.com/puppet/related-projects/facter) to make
available when Puppet is running.
- `hiera_config_path` (string) - The path to a local file with hiera
configuration to be uploaded to the remote machine. Hiera data directories
must be uploaded using the file provisioner separately.
- `manifest_dir` (string) - The path to a local directory with manifests to be
uploaded to the remote machine. This is useful if your main manifest file
uses imports. This directory doesn't necessarily contain the `manifest_file`.
It is a separate directory that will be set as the "manifestdir" setting
on Puppet.
\~&gt; `manifest_dir` is passed to `puppet apply` as the
`--manifestdir` option. This option was deprecated in puppet 3.6, and removed
in puppet 4.0. If you have multiple manifests you should use
`manifest_file` instead.
- `module_paths` (array of strings) - This is an array of paths to module
directories on your local filesystem. These will be uploaded to the
remote machine. By default, this is empty.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to run Puppet are executed with `sudo`. If this is true, then the
sudo will be omitted.
- `staging_directory` (string) - This is the directory where all the
configuration of Puppet by Packer will be placed. By default this
is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but
must have proper permissions so that the SSH user that Packer uses is able to
create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
- `working_directory` (string) - This is the directory from which the puppet
command will be run. When using hiera with a relative path, this option allows
to ensure that the paths are working properly. If not specified, defaults to
the value of specified `staging_directory` (or its default value if not
specified either).
- `execute_command` (string) - The command used to execute Puppet. This has
various [configuration template
variables](/docs/templates/configuration-templates.html) available. See
below for more information.
- `facter` (object of key/value strings) - Additional
[facts](http://puppetlabs.com/puppet/related-projects/facter) to make
available when Puppet is running.
- `hiera_config_path` (string) - The path to a local file with hiera
configuration to be uploaded to the remote machine. Hiera data directories
must be uploaded using the file provisioner separately.
- `manifest_dir` (string) - The path to a local directory with manifests to be
uploaded to the remote machine. This is useful if your main manifest file
uses imports. This directory doesn't necessarily contain the
`manifest_file`. It is a separate directory that will be set as the
"manifestdir" setting on Puppet.
\~&gt; `manifest_dir` is passed to `puppet apply` as the `--manifestdir` option.
This option was deprecated in puppet 3.6, and removed in puppet 4.0. If you have
multiple manifests you should use `manifest_file` instead.
- `module_paths` (array of strings) - This is an array of paths to module
directories on your local filesystem. These will be uploaded to the
remote machine. By default, this is empty.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to run Puppet are executed with `sudo`. If this is true, then the
sudo will be omitted.
- `staging_directory` (string) - This is the directory where all the
configuration of Puppet by Packer will be placed. By default this
is "/tmp/packer-puppet-masterless". This directory doesn't need to exist but
must have proper permissions so that the SSH user that Packer uses is able
to create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
- `working_directory` (string) - This is the directory from which the puppet
command will be run. When using hiera with a relative path, this option
allows to ensure that the paths are working properly. If not specified,
defaults to the value of specified `staging_directory` (or its default value
if not specified either).
## Execute Command
......@@ -119,15 +118,15 @@ This command can be customized using the `execute_command` configuration. As you
can see from the default value above, the value of this configuration can
contain various template variables, defined below:
- `WorkingDir` - The path from which Puppet will be executed.
- `FacterVars` - Shell-friendly string of environmental variables used to set
custom facts configured for this provisioner.
- `HieraConfigPath` - The path to a hiera configuration file.
- `ManifestFile` - The path on the remote machine to the manifest file for
Puppet to use.
- `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.
- `WorkingDir` - The path from which Puppet will be executed.
- `FacterVars` - Shell-friendly string of environmental variables used to set
custom facts configured for this provisioner.
- `HieraConfigPath` - The path to a hiera configuration file.
- `ManifestFile` - The path on the remote machine to the manifest file for
Puppet to use.
- `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.
## Default Facts
......@@ -135,10 +134,10 @@ In addition to being able to specify custom Facter facts using the `facter`
configuration, the provisioner automatically defines certain commonly useful
facts:
- `packer_build_name` is set to the name of the build that Packer is running.
This is most useful when Packer is making multiple builds and you want to
distinguish them in your Hiera hierarchy.
- `packer_build_name` is set to the name of the build that Packer is running.
This is most useful when Packer is making multiple builds and you want to
distinguish them in your Hiera hierarchy.
- `packer_builder_type` is the type of the builder that was used to create the
machine that Puppet is running on. This is useful if you want to run only
certain parts of your Puppet code on systems built with certain builders.
- `packer_builder_type` is the type of the builder that was used to create the
machine that Puppet is running on. This is useful if you want to run only
certain parts of your Puppet code on systems built with certain builders.
website/source/docs/provisioners/puppet-server.html.markdown
View file @ d8e8f98b
......@@ -41,36 +41,36 @@ The reference of available configuration options is listed below.
The provisioner takes various options. None are strictly required. They are
listed below:
- `client_cert_path` (string) - Path to the client certificate for the node on
your disk. This defaults to nothing, in which case a client cert won't
be uploaded.
- `client_cert_path` (string) - Path to the client certificate for the node on
your disk. This defaults to nothing, in which case a client cert won't
be uploaded.
- `client_private_key_path` (string) - Path to the client private key for the
node on your disk. This defaults to nothing, in which case a client private
key won't be uploaded.
- `client_private_key_path` (string) - Path to the client private key for the
node on your disk. This defaults to nothing, in which case a client private
key won't be uploaded.
- `facter` (object of key/value strings) - Additional Facter facts to make
available to the Puppet run.
- `facter` (object of key/value strings) - Additional Facter facts to make
available to the Puppet run.
- `ignore_exit_codes` (boolean) - If true, Packer will never consider the
provisioner a failure.
- `ignore_exit_codes` (boolean) - If true, Packer will never consider the
provisioner a failure.
- `options` (string) - Additional command line options to pass to `puppet agent`
when Puppet is ran.
- `options` (string) - Additional command line options to pass to
`puppet agent` when Puppet is ran.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to run Puppet are executed with `sudo`. If this is true, then the
sudo will be omitted.
- `prevent_sudo` (boolean) - By default, the configured commands that are
executed to run Puppet are executed with `sudo`. If this is true, then the
sudo will be omitted.
- `puppet_node` (string) - The name of the node. If this isn't set, the fully
qualified domain name will be used.
- `puppet_node` (string) - The name of the node. If this isn't set, the fully
qualified domain name will be used.
- `puppet_server` (string) - Hostname of the Puppet server. By default "puppet"
will be used.
- `puppet_server` (string) - Hostname of the Puppet server. By default
"puppet" will be used.
- `staging_directory` (string) - This is the directory where all the
configuration of Puppet by Packer will be placed. By default this
is "/tmp/packer-puppet-server". This directory doesn't need to exist but must
have proper permissions so that the SSH user that Packer uses is able to
create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
- `staging_directory` (string) - This is the directory where all the
configuration of Puppet by Packer will be placed. By default this
is "/tmp/packer-puppet-server". This directory doesn't need to exist but
must have proper permissions so that the SSH user that Packer uses is able
to create directories and write into this folder. If the permissions are not
correct, use a shell provisioner prior to this to configure it properly.
website/source/docs/provisioners/salt-masterless.html.markdown
View file @ d8e8f98b
......@@ -31,28 +31,28 @@ required argument is the path to your local salt state tree.
Optional:
- `bootstrap_args` (string) - Arguments to send to the bootstrap script. Usage
is somewhat documented on
[github](https://github.com/saltstack/salt-bootstrap), but the [script
itself](https://github.com/saltstack/salt-bootstrap/blob/develop/bootstrap-salt.sh)
has more detailed usage instructions. By default, no arguments are sent to
the script.
- `local_pillar_roots` (string) - The path to your local [pillar
roots](http://docs.saltstack.com/ref/configuration/master.html#pillar-configuration).
This will be uploaded to the `/srv/pillar` on the remote.
- `local_state_tree` (string) - The path to your local [state
tree](http://docs.saltstack.com/ref/states/highstate.html#the-salt-state-tree).
This will be uploaded to the `/srv/salt` on the remote.
- `minion_config` (string) - The path to your local [minion
config](http://docs.saltstack.com/topics/configuration.html). This will be
uploaded to the `/etc/salt` on the remote.
- `skip_bootstrap` (boolean) - By default the salt provisioner runs [salt
bootstrap](https://github.com/saltstack/salt-bootstrap) to install salt. Set
this to true to skip this step.
- `temp_config_dir` (string) - Where your local state tree will be copied before
moving to the `/srv/salt` directory. Default is `/tmp/salt`.
- `bootstrap_args` (string) - Arguments to send to the bootstrap script. Usage
is somewhat documented on
[github](https://github.com/saltstack/salt-bootstrap), but the [script
itself](https://github.com/saltstack/salt-bootstrap/blob/develop/bootstrap-salt.sh)
has more detailed usage instructions. By default, no arguments are sent to
the script.
- `local_pillar_roots` (string) - The path to your local [pillar
roots](http://docs.saltstack.com/ref/configuration/master.html#pillar-configuration).
This will be uploaded to the `/srv/pillar` on the remote.
- `local_state_tree` (string) - The path to your local [state
tree](http://docs.saltstack.com/ref/states/highstate.html#the-salt-state-tree).
This will be uploaded to the `/srv/salt` on the remote.
- `minion_config` (string) - The path to your local [minion
config](http://docs.saltstack.com/topics/configuration.html). This will be
uploaded to the `/etc/salt` on the remote.
- `skip_bootstrap` (boolean) - By default the salt provisioner runs [salt
bootstrap](https://github.com/saltstack/salt-bootstrap) to install salt. Set
this to true to skip this step.
- `temp_config_dir` (string) - Where your local state tree will be copied
before moving to the `/srv/salt` directory. Default is `/tmp/salt`.
website/source/docs/provisioners/shell.html.markdown
View file @ d8e8f98b
......@@ -37,55 +37,56 @@ required element is either "inline" or "script". Every other option is optional.
Exactly *one* of the following is required:
- `inline` (array of strings) - This is an array of commands to execute. The
commands are concatenated by newlines and turned into a single file, so they
are all executed within the same context. This allows you to change
directories in one command and use something in the directory in the next and
so on. Inline scripts are the easiest way to pull off simple tasks within
the machine.
- `script` (string) - The path to a script to upload and execute in the machine.
This path can be absolute or relative. If it is relative, it is relative to
the working directory when Packer is executed.
- `scripts` (array of strings) - An array of scripts to execute. The scripts
will be uploaded and executed in the order specified. Each script is executed
in isolation, so state such as variables from one script won't carry on to
the next.
- `inline` (array of strings) - This is an array of commands to execute. The
commands are concatenated by newlines and turned into a single file, so they
are all executed within the same context. This allows you to change
directories in one command and use something in the directory in the next
and so on. Inline scripts are the easiest way to pull off simple tasks
within the machine.
- `script` (string) - The path to a script to upload and execute in
the machine. This path can be absolute or relative. If it is relative, it is
relative to the working directory when Packer is executed.
- `scripts` (array of strings) - An array of scripts to execute. The scripts
will be uploaded and executed in the order specified. Each script is
executed in isolation, so state such as variables from one script won't
carry on to the next.
Optional parameters:
- `binary` (boolean) - If true, specifies that the script(s) are binary files,
and Packer should therefore not convert Windows line endings to Unix line
endings (if there are any). By default this is false.
- `environment_vars` (array of strings) - An array of key/value pairs to inject
prior to the execute\_command. The format should be `key=value`. Packer
injects some environmental variables by default into the environment, as well,
which are covered in the section below.
- `execute_command` (string) - The command to use to execute the script. By
default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`. The value of
this is treated as [configuration
template](/docs/templates/configuration-templates.html). There are two
available variables: `Path`, which is the path to the script to run, and
`Vars`, which is the list of `environment_vars`, if configured.
- `inline_shebang` (string) - The
[shebang](http://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use when
running commands specified by `inline`. By default, this is `/bin/sh -e`. If
you're not using `inline`, then this configuration has no effect.
**Important:** If you customize this, be sure to include something like the
`-e` flag, otherwise individual steps failing won't fail the provisioner.
- `remote_path` (string) - The path where the script will be uploaded to in
the machine. This defaults to "/tmp/script.sh". This value must be a writable
location and any parent directories must already exist.
- `start_retry_timeout` (string) - The amount of time to attempt to *start* the
remote process. By default this is "5m" or 5 minutes. This setting exists in
order to deal with times when SSH may restart, such as a system reboot. Set
this to a higher value if reboots take a longer amount of time.
- `binary` (boolean) - If true, specifies that the script(s) are binary files,
and Packer should therefore not convert Windows line endings to Unix line
endings (if there are any). By default this is false.
- `environment_vars` (array of strings) - An array of key/value pairs to
inject prior to the execute\_command. The format should be `key=value`.
Packer injects some environmental variables by default into the environment,
as well, which are covered in the section below.
- `execute_command` (string) - The command to use to execute the script. By
default this is `chmod +x {{ .Path }}; {{ .Vars }} {{ .Path }}`. The value
of this is treated as [configuration
template](/docs/templates/configuration-templates.html). There are two
available variables: `Path`, which is the path to the script to run, and
`Vars`, which is the list of `environment_vars`, if configured.
- `inline_shebang` (string) - The
[shebang](http://en.wikipedia.org/wiki/Shebang_%28Unix%29) value to use when
running commands specified by `inline`. By default, this is `/bin/sh -e`. If
you're not using `inline`, then this configuration has no effect.
**Important:** If you customize this, be sure to include something like the
`-e` flag, otherwise individual steps failing won't fail the provisioner.
- `remote_path` (string) - The path where the script will be uploaded to in
the machine. This defaults to "/tmp/script.sh". This value must be a
writable location and any parent directories must already exist.
- `start_retry_timeout` (string) - The amount of time to attempt to *start*
the remote process. By default this is "5m" or 5 minutes. This setting
exists in order to deal with times when SSH may restart, such as a
system reboot. Set this to a higher value if reboots take a longer amount
of time.
## Execute Command Example
......@@ -128,13 +129,13 @@ In addition to being able to specify custom environmental variables using the
`environment_vars` configuration, the provisioner automatically defines certain
commonly useful environmental variables:
- `PACKER_BUILD_NAME` is set to the name of the build that Packer is running.
This is most useful when Packer is making multiple builds and you want to
distinguish them slightly from a common provisioning script.
- `PACKER_BUILD_NAME` is set to the name of the build that Packer is running.
This is most useful when Packer is making multiple builds and you want to
distinguish them slightly from a common provisioning script.
- `PACKER_BUILDER_TYPE` is the type of the builder that was used to create the
machine that the script is running on. This is useful if you want to run only
certain parts of the script on systems built with certain builders.
- `PACKER_BUILDER_TYPE` is the type of the builder that was used to create the
machine that the script is running on. This is useful if you want to run
only certain parts of the script on systems built with certain builders.
## Handling Reboots
......@@ -181,46 +182,41 @@ provisioner](/docs/provisioners/file.html) (more secure) or using `ssh-keyscan`
to populate the file (less secure). An example of the latter accessing github
would be:
{
"type": "shell",
"inline": [
"sudo apt-get install -y git",
"ssh-keyscan github.com >> ~/.ssh/known_hosts",
"git clone git@github.com:exampleorg/myprivaterepo.git"
]
}
{ "type": "shell", "inline": \[ "sudo apt-get install -y git", "ssh-keyscan
github.com &gt;&gt; \~/.ssh/known\_hosts", "git clone
git@github.com:exampleorg/myprivaterepo.git" \] }
## Troubleshooting
*My shell script doesn't work correctly on Ubuntu*
- On Ubuntu, the `/bin/sh` shell is
[dash](http://en.wikipedia.org/wiki/Debian_Almquist_shell). If your script has
[bash](http://en.wikipedia.org/wiki/Bash_(Unix_shell))-specific commands in
it, then put `#!/bin/bash` at the top of your script. Differences between dash
and bash can be found on the
[DashAsBinSh](https://wiki.ubuntu.com/DashAsBinSh) Ubuntu wiki page.
- On Ubuntu, the `/bin/sh` shell is
[dash](http://en.wikipedia.org/wiki/Debian_Almquist_shell). If your script
has [bash](http://en.wikipedia.org/wiki/Bash_(Unix_shell))-specific commands
in it, then put `#!/bin/bash` at the top of your script. Differences between
dash and bash can be found on the
[DashAsBinSh](https://wiki.ubuntu.com/DashAsBinSh) Ubuntu wiki page.
*My shell works when I login but fails with the shell provisioner*
- See the above tip. More than likely, your login shell is using `/bin/bash`
while the provisioner is using `/bin/sh`.
- See the above tip. More than likely, your login shell is using `/bin/bash`
while the provisioner is using `/bin/sh`.
*My installs hang when using `apt-get` or `yum`*
- Make sure you add a `-y` to the command to prevent it from requiring user
input before proceeding.
- Make sure you add a `-y` to the command to prevent it from requiring user
input before proceeding.
*How do I tell what my shell script is doing?*
- Adding a `-x` flag to the shebang at the top of the script (`#!/bin/sh -x`)
will echo the script statements as it is executing.
- Adding a `-x` flag to the shebang at the top of the script (`#!/bin/sh -x`)
will echo the script statements as it is executing.
*My builds don't always work the same*
- Some distributions start the SSH daemon before other core services which can
create race conditions. Your first provisioner can tell the machine to wait
until it completely boots.
- Some distributions start the SSH daemon before other core services which can
create race conditions. Your first provisioner can tell the machine to wait
until it completely boots.
``` {.javascript}
{
......
website/source/docs/templates/configuration-templates.html.markdown
View file @ d8e8f98b
......@@ -57,17 +57,17 @@ While some configuration settings have local variables specific to only that
configuration, a set of functions are available globally for use in *any string*
in Packer templates. These are listed below for reference.
- `build_name` - The name of the build being run.
- `build_type` - The type of the builder being used currently.
- `isotime [FORMAT]` - UTC time, which can be
[formatted](http://golang.org/pkg/time/#example_Time_Format). See more
examples below.
- `lower` - Lowercases the string.
- `pwd` - The working directory while executing Packer.
- `template_dir` - The directory to the template for the build.
- `timestamp` - The current Unix timestamp in UTC.
- `uuid` - Returns a random UUID.
- `upper` - Uppercases the string.
- `build_name` - The name of the build being run.
- `build_type` - The type of the builder being used currently.
- `isotime [FORMAT]` - UTC time, which can be
[formatted](http://golang.org/pkg/time/#example_Time_Format). See more
examples below.
- `lower` - Lowercases the string.
- `pwd` - The working directory while executing Packer.
- `template_dir` - The directory to the template for the build.
- `timestamp` - The current Unix timestamp in UTC.
- `uuid` - Returns a random UUID.
- `upper` - Uppercases the string.
### isotime Format
......@@ -112,7 +112,8 @@ Timezone
Numeric
</th>
<td align="center">
-
-
</td>
<td align="center">
01
......@@ -147,19 +148,24 @@ Monday (Mon)
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
......@@ -205,6 +211,6 @@ Please note that double quote characters need escaping inside of templates:
Specific to Amazon builders:
- `clean_ami_name` - AMI names can only contain certain characters. This
function will replace illegal characters with a '-" character. Example usage
since ":" is not a legal AMI name is: `{{isotime | clean_ami_name}}`.
- `clean_ami_name` - AMI names can only contain certain characters. This
function will replace illegal characters with a '-" character. Example usage
since ":" is not a legal AMI name is: `{{isotime | clean_ami_name}}`.
website/source/docs/templates/introduction.html.markdown
View file @ d8e8f98b
......@@ -27,40 +27,41 @@ A template is a JSON object that has a set of keys configuring various
components of Packer. The available keys within a template are listed below.
Along with each key, it is noted whether it is required or not.
- `builders` (*required*) is an array of one or more objects that defines the
builders that will be used to create machine images for this template, and
configures each of those builders. For more information on how to define and
configure a builder, read the sub-section on [configuring builders in
templates](/docs/templates/builders.html).
- `description` (optional) is a string providing a description of what the
template does. This output is used only in the [inspect
command](/docs/command-line/inspect.html).
- `min_packer_version` (optional) is a string that has a minimum Packer version
that is required to parse the template. This can be used to ensure that proper
versions of Packer are used with the template. A max version can't be
specified because Packer retains backwards compatibility with `packer fix`.
- `post-processors` (optional) is an array of one or more objects that defines
the various post-processing steps to take with the built images. If not
specified, then no post-processing will be done. For more information on what
post-processors do and how they're defined, read the sub-section on
[configuring post-processors in
templates](/docs/templates/post-processors.html).
- `provisioners` (optional) is an array of one or more objects that defines the
provisioners that will be used to install and configure software for the
machines created by each of the builders. If it is not specified, then no
provisioners will be run. For more information on how to define and configure
a provisioner, read the sub-section on [configuring provisioners in
templates](/docs/templates/provisioners.html).
- `variables` (optional) is an array of one or more key/value strings that
defines user variables contained in the template. If it is not specified, then
no variables are defined. For more information on how to define and use user
variables, read the sub-section on [user variables in
templates](/docs/templates/user-variables.html).
- `builders` (*required*) is an array of one or more objects that defines the
builders that will be used to create machine images for this template, and
configures each of those builders. For more information on how to define and
configure a builder, read the sub-section on [configuring builders in
templates](/docs/templates/builders.html).
- `description` (optional) is a string providing a description of what the
template does. This output is used only in the [inspect
command](/docs/command-line/inspect.html).
- `min_packer_version` (optional) is a string that has a minimum Packer
version that is required to parse the template. This can be used to ensure
that proper versions of Packer are used with the template. A max version
can't be specified because Packer retains backwards compatibility with
`packer fix`.
- `post-processors` (optional) is an array of one or more objects that defines
the various post-processing steps to take with the built images. If not
specified, then no post-processing will be done. For more information on
what post-processors do and how they're defined, read the sub-section on
[configuring post-processors in
templates](/docs/templates/post-processors.html).
- `provisioners` (optional) is an array of one or more objects that defines
the provisioners that will be used to install and configure software for the
machines created by each of the builders. If it is not specified, then no
provisioners will be run. For more information on how to define and
configure a provisioner, read the sub-section on [configuring provisioners
in templates](/docs/templates/provisioners.html).
- `variables` (optional) is an array of one or more key/value strings that
defines user variables contained in the template. If it is not specified,
then no variables are defined. For more information on how to define and use
user variables, read the sub-section on [user variables in
templates](/docs/templates/user-variables.html).
## Comments
......
website/source/docs/templates/push.html.markdown
View file @ d8e8f98b
......@@ -37,31 +37,31 @@ each category, the available configuration keys are alphabetized.
### Required
- `name` (string) - Name of the build configuration in the build service. If
this doesn't exist, it will be created (by default).
- `name` (string) - Name of the build configuration in the build service. If
this doesn't exist, it will be created (by default).
### Optional
- `address` (string) - The address of the build service to use. By default this
is `https://atlas.hashicorp.com`.
- `address` (string) - The address of the build service to use. By default
this is `https://atlas.hashicorp.com`.
- `base_dir` (string) - The base directory of the files to upload. This will be
the current working directory when the build service executes your template.
This path is relative to the template.
- `base_dir` (string) - The base directory of the files to upload. This will
be the current working directory when the build service executes
your template. This path is relative to the template.
- `include` (array of strings) - Glob patterns to include relative to the
`base_dir`. If this is specified, only files that match the include pattern
are included.
- `include` (array of strings) - Glob patterns to include relative to the
`base_dir`. If this is specified, only files that match the include pattern
are included.
- `exclude` (array of strings) - Glob patterns to exclude relative to the
`base_dir`.
- `exclude` (array of strings) - Glob patterns to exclude relative to the
`base_dir`.
- `token` (string) - An access token to use to authenticate to the
build service.
- `token` (string) - An access token to use to authenticate to the
build service.
- `vcs` (boolean) - If true, Packer will detect your VCS (if there is one) and
only upload the files that are tracked by the VCS. This is useful for
automatically excluding ignored files. This defaults to false.
- `vcs` (boolean) - If true, Packer will detect your VCS (if there is one) and
only upload the files that are tracked by the VCS. This is useful for
automatically excluding ignored files. This defaults to false.
## Examples
......
website/source/intro/platforms.html.markdown
View file @ d8e8f98b
......@@ -33,40 +33,42 @@ is noted. They are listed in alphabetical order. For more detailed information
on supported configuration parameters and usage, please see the appropriate
[documentation page within the documentation section](/docs).
- ***Amazon EC2 (AMI)***. Both EBS-backed and instance-store AMIs within
[EC2](http://aws.amazon.com/ec2/), optionally distributed to multiple regions.
- ***Amazon EC2 (AMI)***. Both EBS-backed and instance-store AMIs within
[EC2](http://aws.amazon.com/ec2/), optionally distributed to
multiple regions.
- ***DigitalOcean***. Snapshots for [DigitalOcean](http://www.digitalocean.com/)
that can be used to start a pre-configured DigitalOcean instance of any size.
- ***DigitalOcean***. Snapshots for
[DigitalOcean](http://www.digitalocean.com/) that can be used to start a
pre-configured DigitalOcean instance of any size.
- ***Docker***. Snapshots for [Docker](http://www.docker.io/) that can be used
to start a pre-configured Docker instance.
- ***Docker***. Snapshots for [Docker](http://www.docker.io/) that can be used
to start a pre-configured Docker instance.
- ***Google Compute Engine***. Snapshots for [Google Compute
Engine](https://cloud.google.com/products/compute-engine) that can be used to
start a pre-configured Google Compute Engine instance.
- ***Google Compute Engine***. Snapshots for [Google Compute
Engine](https://cloud.google.com/products/compute-engine) that can be used
to start a pre-configured Google Compute Engine instance.
- ***OpenStack***. Images for [OpenStack](http://www.openstack.org/) that can be
used to start pre-configured OpenStack servers.
- ***OpenStack***. Images for [OpenStack](http://www.openstack.org/) that can
be used to start pre-configured OpenStack servers.
- ***Parallels (PVM)***. Exported virtual machines for
[Parallels](http://www.parallels.com/downloads/desktop/), including virtual
machine metadata such as RAM, CPUs, etc. These virtual machines are portable
and can be started on any platform Parallels runs on.
- ***Parallels (PVM)***. Exported virtual machines for
[Parallels](http://www.parallels.com/downloads/desktop/), including virtual
machine metadata such as RAM, CPUs, etc. These virtual machines are portable
and can be started on any platform Parallels runs on.
- ***QEMU***. Images for [KVM](http://www.linux-kvm.org/) or
[Xen](http://www.xenproject.org/) that can be used to start pre-configured KVM
or Xen instances.
- ***QEMU***. Images for [KVM](http://www.linux-kvm.org/) or
[Xen](http://www.xenproject.org/) that can be used to start pre-configured
KVM or Xen instances.
- ***VirtualBox (OVF)***. Exported virtual machines for
[VirtualBox](https://www.virtualbox.org/), including virtual machine metadata
such as RAM, CPUs, etc. These virtual machines are portable and can be started
on any platform VirtualBox runs on.
- ***VirtualBox (OVF)***. Exported virtual machines for
[VirtualBox](https://www.virtualbox.org/), including virtual machine
metadata such as RAM, CPUs, etc. These virtual machines are portable and can
be started on any platform VirtualBox runs on.
- ***VMware (VMX)***. Exported virtual machines for
[VMware](http://www.vmware.com/) that can be run within any desktop products
such as Fusion, Player, or Workstation, as well as server products such
as vSphere.
- ***VMware (VMX)***. Exported virtual machines for
[VMware](http://www.vmware.com/) that can be run within any desktop products
such as Fusion, Player, or Workstation, as well as server products such
as vSphere.
As previously mentioned, these are just the target image types that Packer ships
with out of the box. You can always [extend Packer through
......
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