@ -2,7 +2,7 @@ _Please read these instructions before submitting_
**DELETE THIS TEMPLATE BEFORE SUBMITTING**
_Only use Github issues to report bugs or feature requests, see
_Only use GitHub issues to report bugs or feature requests, see
https://www.packer.io/community.html_
For example, _Timeouts waiting for SSH/WinRM_ are generally not bugs within packer and are better addressed by the mailing list. Ask on the mailing list if you are unsure.
- `volume_size` (number) - The size of the volume, in GiB. Required if not
specifying a `snapshot_id`
specifying a `snapshot_id`.
- `volume_type` (string) - The volume type. `gp2` for General Purpose (SSD)
volumes, `io1` for Provisioned IOPS (SSD) volumes, and `standard` for Magnetic
@ -231,7 +231,7 @@ each category, the available configuration keys are alphabetized.
to the `mount` command ran by Packer. Because this command is ran in a
shell, user discretion is advised. See [this manual page for the mount
command](http://linuxcommand.org/man_pages/mount8.html) for valid file
system specific options
system specific options.
- `nvme_device_path` (string) - When we call the mount command (by default
`mount -o device dir`), the string provided in `nvme_mount_path` will
@ -264,7 +264,7 @@ each category, the available configuration keys are alphabetized.
- `root_volume_type` (string) - The type of EBS volume for the chroot environment
and resulting AMI. The default value is the type of the `source_ami`, unless
`from_scratch` is true, in which case the default value is `gp2`. You can only
`from_scratch` is `true`, in which case the default value is `gp2`. You can only
specify `io1` if building based on top of a `source_ami` which is also `io1`.
- `root_volume_tags` (object of key/value strings) - Tags to apply to the volumes
@ -272,7 +272,7 @@ each category, the available configuration keys are alphabetized.
[template engine](/docs/templates/engine.html),
see [Build template data](#build-template-data) for more information.
- `skip_region_validation` (boolean) - Set to true if you want to skip
- `skip_region_validation` (boolean) - Set to `true` if you want to skip
validation of the `ami_regions` configuration option. Default `false`.
- `snapshot_tags` (object of key/value strings) - Tags to apply to snapshot.
@ -318,7 +318,7 @@ each category, the available configuration keys are alphabetized.
for example, "amazon", "aws-marketplace", or "microsoft".
This option is required for security reasons.
- `most_recent` (boolean) - Selects the newest created image when true.
- `most_recent` (boolean) - Selects the newest created image when `true`.
This is most useful for selecting a daily distro build.
You may set this in place of `source_ami` or in conjunction with it. If you
@ -328,7 +328,7 @@ each category, the available configuration keys are alphabetized.
but will cause Packer to fail if the `source_ami` does not exist.
- `sriov_support` (boolean) - Enable enhanced networking (SriovNetSupport but not ENA)
on HVM-compatible AMIs. If true, add `ec2:ModifyInstanceAttribute` to your AWS IAM
on HVM-compatible AMIs. If `true`, add `ec2:ModifyInstanceAttribute` to your AWS IAM
policy. Note: you must make sure enhanced networking is enabled on your instance. See [Amazon's
documentation on enabling enhanced networking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html#enabling_enhanced_networking).
Default `false`.
@ -472,7 +472,7 @@ A working example for mounting an NVMe device is below:
```
Note that in the `nvme_device_path` you must end with the `p`; if you try to
define the partition in this path (e.g. "nvme_device_path": `/dev/nvme1n1p1`)
define the partition in this path (e.g. `nvme_device_path`: `/dev/nvme1n1p1`)
and haven't also set the `"mount_partition": 0`, a `1` will be appended to the
4. On Google Compute Engine and Google App Engine Managed VMs, it fetches credentials from the metadata server. (Needs a correct VM authentication scope configuration, see above)
4. On Google Compute Engine and Google App Engine Managed VMs, it fetches
credentials from the metadata server. (Needs a correct VM authentication scope
configuration, see above.)
## Examples
@ -328,9 +333,9 @@ builder.
Startup scripts can be a powerful tool for configuring the instance from which the image is made.
The builder will wait for a startup script to terminate. A startup script can be provided via the
`startup_script_file` or 'startup-script' instance creation `metadata` field. Therefore, the build
`startup_script_file` or `startup-script` instance creation `metadata` field. Therefore, the build
time will vary depending on the duration of the startup script. If `startup_script_file` is set,
the 'startup-script'`metadata` field will be overwritten. In other words,`startup_script_file`
the `startup-script``metadata` field will be overwritten. In other words,`startup_script_file`
takes precedence.
The builder does not check for a pass/fail/error signal from the startup script, at this time. Until
@ -339,14 +344,14 @@ when a startup script fails.
### Windows
A Windows startup script can only be provided via the 'windows-startup-script-cmd' instance
creation `metadata` field. The builder will *not* wait for a Windows startup scripts to
A Windows startup script can only be provided via the `windows-startup-script-cmd` instance
creation `metadata` field. The builder will *not* wait for a Windows startup script to
terminate. You have to ensure that it finishes before the instance shuts down.
### Logging
Startup script logs can be copied to a Google Cloud Storage (GCS) location specified via the
'startup-script-log-dest' instance creation `metadata` field. The GCS location must be writeable by
`startup-script-log-dest` instance creation `metadata` field. The GCS location must be writeable by
the credentials provided in the builder config's `account_file`.
Megan Marsh
8 years ago
committed by
GitHub