2013-07-25 11:51:21 -04:00
|
|
|
---
|
2015-07-22 22:31:00 -04:00
|
|
|
layout: docs
|
2017-03-25 18:13:52 -04:00
|
|
|
sidebar_current: docs-builders-amazon
|
|
|
|
page_title: Amazon AMI - Builders
|
|
|
|
description: |-
|
|
|
|
Packer is able to create Amazon AMIs. To achieve this, Packer comes with
|
|
|
|
multiple builders depending on the strategy you want to use to build the AMI.
|
|
|
|
---
|
2013-07-25 11:51:21 -04:00
|
|
|
|
|
|
|
# Amazon AMI Builder
|
|
|
|
|
|
|
|
Packer is able to create Amazon AMIs. To achieve this, Packer comes with
|
2015-07-24 23:55:08 -04:00
|
|
|
multiple builders depending on the strategy you want to use to build the AMI.
|
|
|
|
Packer supports the following builders at the moment:
|
2013-07-25 11:51:21 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
- [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.
|
2015-07-22 23:25:58 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
- [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.
|
2015-07-22 23:25:58 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
- [amazon-chroot](/docs/builders/amazon-chroot.html) - Create EBS-backed AMIs
|
|
|
|
from an existing EC2 instance by mounting the root device and using a
|
2016-01-14 15:31:19 -05:00
|
|
|
[Chroot](https://en.wikipedia.org/wiki/Chroot) environment to provision
|
2015-07-24 23:55:08 -04:00
|
|
|
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.
|
2017-03-01 02:09:52 -05:00
|
|
|
|
2017-03-06 03:44:07 -05:00
|
|
|
- [amazon-ebssurrogate](/docs/builders/amazon-ebssurrogate.html) - Create EBS
|
2016-12-30 16:21:23 -05:00
|
|
|
-backed AMIs from scratch. Works similarly to the `chroot` builder but does
|
|
|
|
not require running in AWS. This is an **advanced builder and should not be
|
|
|
|
used by newcomers**.
|
2013-07-31 01:17:58 -04:00
|
|
|
|
2017-03-25 18:13:52 -04:00
|
|
|
-> **Don't know which builder to use?** If in doubt, use the [amazon-ebs
|
2015-07-24 23:55:08 -04:00
|
|
|
builder](/docs/builders/amazon-ebs.html). It is much easier to use and Amazon
|
|
|
|
generally recommends EBS-backed images nowadays.
|
2013-11-25 07:27:38 -05:00
|
|
|
|
builder/amazon: Add `ebs-volume` builder
This commit adds a builder that works like EBS builders, except does not
create an AMI, and instead is intended to create EBS volumes in an
initialized state. For example, the following template can be used to
create and export a set of 3 EBS Volumes in a ZFS zpool named `data` for
importing by instances running production systems:
```
{
"variables": {
"aws_access_key_id": "{{ env `AWS_ACCESS_KEY_ID` }}",
"aws_secret_access_key": "{{ env `AWS_SECRET_ACCESS_KEY` }}",
"region": "{{ env `AWS_REGION` }}",
"source_ami": "{{ env `PACKER_SOURCE_AMI` }}",
"vpc_id": "{{ env `PACKER_VPC_ID` }}",
"subnet_id": "{{ env `PACKER_SUBNET_ID` }}"
},
"builders": [{
"type": "amazon-ebs-volume",
"access_key": "{{ user `aws_access_key_id` }}",
"secret_key": "{{ user `aws_secret_access_key` }}",
"region": "{{user `region`}}",
"spot_price_auto_product": "Linux/UNIX (Amazon VPC)",
"ssh_pty": true,
"instance_type": "t2.medium",
"vpc_id": "{{user `vpc_id` }}",
"subnet_id": "{{user `subnet_id` }}",
"associate_public_ip_address": true,
"source_ami": "{{user `source_ami` }}",
"ssh_username": "ubuntu",
"ssh_timeout": "5m",
"ebs_volumes": [
{
"device_name": "/dev/xvdf",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data1",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdg",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data2",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdh",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data3",
"zpool": "data",
"Component": "TeamCity"
}
}
]
}],
"provisioners": [
{
"type": "shell",
"start_retry_timeout": "10m",
"inline": [
"DEBIAN_FRONTEND=noninteractive sudo apt-get update",
"DEBIAN_FRONTEND=noninteractive sudo apt-get install -y zfs",
"lsblk",
"sudo parted /dev/xvdf --script mklabel GPT",
"sudo parted /dev/xvdg --script mklabel GPT",
"sudo parted /dev/xvdh --script mklabel GPT",
"sudo zpool create -m none data raidz xvdf xvdg xvdh",
"sudo zpool status",
"sudo zpool export data",
"sudo zpool status"
]
}
]
}
```
StepModifyInstance and StepStopInstance are now shared between EBS and
EBS-Volume builders - move them into the AWS common directory and rename
them to indicate that they only apply to EBS-backed builders.
2016-10-31 17:44:41 -04:00
|
|
|
# Amazon EBS Volume Builder
|
|
|
|
|
|
|
|
Packer is able to create Amazon EBS Volumes which are preinitialized with a
|
2016-11-30 06:32:46 -05:00
|
|
|
filesystem and data.
|
builder/amazon: Add `ebs-volume` builder
This commit adds a builder that works like EBS builders, except does not
create an AMI, and instead is intended to create EBS volumes in an
initialized state. For example, the following template can be used to
create and export a set of 3 EBS Volumes in a ZFS zpool named `data` for
importing by instances running production systems:
```
{
"variables": {
"aws_access_key_id": "{{ env `AWS_ACCESS_KEY_ID` }}",
"aws_secret_access_key": "{{ env `AWS_SECRET_ACCESS_KEY` }}",
"region": "{{ env `AWS_REGION` }}",
"source_ami": "{{ env `PACKER_SOURCE_AMI` }}",
"vpc_id": "{{ env `PACKER_VPC_ID` }}",
"subnet_id": "{{ env `PACKER_SUBNET_ID` }}"
},
"builders": [{
"type": "amazon-ebs-volume",
"access_key": "{{ user `aws_access_key_id` }}",
"secret_key": "{{ user `aws_secret_access_key` }}",
"region": "{{user `region`}}",
"spot_price_auto_product": "Linux/UNIX (Amazon VPC)",
"ssh_pty": true,
"instance_type": "t2.medium",
"vpc_id": "{{user `vpc_id` }}",
"subnet_id": "{{user `subnet_id` }}",
"associate_public_ip_address": true,
"source_ami": "{{user `source_ami` }}",
"ssh_username": "ubuntu",
"ssh_timeout": "5m",
"ebs_volumes": [
{
"device_name": "/dev/xvdf",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data1",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdg",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data2",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdh",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data3",
"zpool": "data",
"Component": "TeamCity"
}
}
]
}],
"provisioners": [
{
"type": "shell",
"start_retry_timeout": "10m",
"inline": [
"DEBIAN_FRONTEND=noninteractive sudo apt-get update",
"DEBIAN_FRONTEND=noninteractive sudo apt-get install -y zfs",
"lsblk",
"sudo parted /dev/xvdf --script mklabel GPT",
"sudo parted /dev/xvdg --script mklabel GPT",
"sudo parted /dev/xvdh --script mklabel GPT",
"sudo zpool create -m none data raidz xvdf xvdg xvdh",
"sudo zpool status",
"sudo zpool export data",
"sudo zpool status"
]
}
]
}
```
StepModifyInstance and StepStopInstance are now shared between EBS and
EBS-Volume builders - move them into the AWS common directory and rename
them to indicate that they only apply to EBS-backed builders.
2016-10-31 17:44:41 -04:00
|
|
|
|
2017-01-14 07:03:39 -05:00
|
|
|
- [amazon-ebsvolume](/docs/builders/amazon-ebsvolume.html) - Create EBS volumes
|
builder/amazon: Add `ebs-volume` builder
This commit adds a builder that works like EBS builders, except does not
create an AMI, and instead is intended to create EBS volumes in an
initialized state. For example, the following template can be used to
create and export a set of 3 EBS Volumes in a ZFS zpool named `data` for
importing by instances running production systems:
```
{
"variables": {
"aws_access_key_id": "{{ env `AWS_ACCESS_KEY_ID` }}",
"aws_secret_access_key": "{{ env `AWS_SECRET_ACCESS_KEY` }}",
"region": "{{ env `AWS_REGION` }}",
"source_ami": "{{ env `PACKER_SOURCE_AMI` }}",
"vpc_id": "{{ env `PACKER_VPC_ID` }}",
"subnet_id": "{{ env `PACKER_SUBNET_ID` }}"
},
"builders": [{
"type": "amazon-ebs-volume",
"access_key": "{{ user `aws_access_key_id` }}",
"secret_key": "{{ user `aws_secret_access_key` }}",
"region": "{{user `region`}}",
"spot_price_auto_product": "Linux/UNIX (Amazon VPC)",
"ssh_pty": true,
"instance_type": "t2.medium",
"vpc_id": "{{user `vpc_id` }}",
"subnet_id": "{{user `subnet_id` }}",
"associate_public_ip_address": true,
"source_ami": "{{user `source_ami` }}",
"ssh_username": "ubuntu",
"ssh_timeout": "5m",
"ebs_volumes": [
{
"device_name": "/dev/xvdf",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data1",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdg",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data2",
"zpool": "data",
"Component": "TeamCity"
}
},
{
"device_name": "/dev/xvdh",
"delete_on_termination": false,
"volume_size": 10,
"volume_type": "gp2",
"tags": {
"Name": "TeamCity-Data3",
"zpool": "data",
"Component": "TeamCity"
}
}
]
}],
"provisioners": [
{
"type": "shell",
"start_retry_timeout": "10m",
"inline": [
"DEBIAN_FRONTEND=noninteractive sudo apt-get update",
"DEBIAN_FRONTEND=noninteractive sudo apt-get install -y zfs",
"lsblk",
"sudo parted /dev/xvdf --script mklabel GPT",
"sudo parted /dev/xvdg --script mklabel GPT",
"sudo parted /dev/xvdh --script mklabel GPT",
"sudo zpool create -m none data raidz xvdf xvdg xvdh",
"sudo zpool status",
"sudo zpool export data",
"sudo zpool status"
]
}
]
}
```
StepModifyInstance and StepStopInstance are now shared between EBS and
EBS-Volume builders - move them into the AWS common directory and rename
them to indicate that they only apply to EBS-backed builders.
2016-10-31 17:44:41 -04:00
|
|
|
by launching a source AMI with block devices mapped. Provision the instance,
|
|
|
|
then destroy it, retaining the EBS volumes.
|
|
|
|
|
2015-07-25 00:00:24 -04:00
|
|
|
<span id="specifying-amazon-credentials"></span>
|
2015-07-24 23:38:14 -04:00
|
|
|
|
2015-07-25 00:00:24 -04:00
|
|
|
## Specifying Amazon Credentials
|
2015-07-24 23:55:08 -04:00
|
|
|
|
|
|
|
When you use any of the amazon builders, you must provide credentials to the API
|
|
|
|
in the form of an access key id and secret. These look like:
|
2015-07-24 23:38:14 -04:00
|
|
|
|
|
|
|
access key id: AKIAIOSFODNN7EXAMPLE
|
|
|
|
secret access key: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
|
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
If you use other AWS tools you may already have these configured. If so, packer
|
|
|
|
will try to use them, *unless* they are specified in your packer template.
|
|
|
|
Credentials are resolved in the following order:
|
2015-07-24 23:38:14 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
1. Values hard-coded in the packer template are always authoritative.
|
|
|
|
2. *Variables* in the packer template may be resolved from command-line flags
|
|
|
|
or from environment variables. Please read about [User
|
2016-01-14 15:33:00 -05:00
|
|
|
Variables](https://www.packer.io/docs/templates/user-variables.html)
|
2015-07-24 23:55:08 -04:00
|
|
|
for details.
|
|
|
|
3. If no credentials are found, packer falls back to automatic lookup.
|
2015-07-24 23:38:14 -04:00
|
|
|
|
|
|
|
### Automatic Lookup
|
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
If no AWS credentials are found in a packer template, we proceed on to the
|
|
|
|
following steps:
|
|
|
|
|
|
|
|
1. Lookup via environment variables.
|
|
|
|
- First `AWS_ACCESS_KEY_ID`, then `AWS_ACCESS_KEY`
|
|
|
|
- First `AWS_SECRET_ACCESS_KEY`, then `AWS_SECRET_KEY`
|
|
|
|
|
|
|
|
2. Look for [local AWS configuration
|
2016-01-14 15:31:19 -05:00
|
|
|
files](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
|
2017-03-01 02:09:52 -05:00
|
|
|
- Looks for the credentials file in the `AWS_SHARED_CREDENTIALS_FILE`
|
|
|
|
environment variable, and if that's empty, use the default credentials
|
|
|
|
file (`.aws/credentials`) in the user's home directory.
|
2017-03-01 02:23:36 -05:00
|
|
|
- Uses the profile name set in the `AWS_PROFILE` environment variable. If
|
|
|
|
the environment variable is not set, uses "default" as the profile name.
|
2015-07-24 23:38:14 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
3. Lookup an IAM role for the current EC2 instance (if you're running in EC2)
|
2015-07-24 23:38:14 -04:00
|
|
|
|
2017-03-25 18:13:52 -04:00
|
|
|
~> **Subtle details of automatic lookup may change over time.** The most
|
2015-07-24 23:55:08 -04:00
|
|
|
reliable way to specify your configuration is by setting them in template
|
|
|
|
variables (directly or indirectly), or by using the `AWS_ACCESS_KEY_ID` and
|
|
|
|
`AWS_SECRET_ACCESS_KEY` environment variables.
|
2015-07-24 23:38:14 -04:00
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
Environment variables provide the best portability, allowing you to run your
|
|
|
|
packer build on your workstation, in Atlas, or on another build server.
|
2013-11-25 07:27:38 -05:00
|
|
|
|
|
|
|
## Using an IAM Instance Profile
|
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
If AWS keys are not specified in the template, a
|
2016-01-14 15:31:19 -05:00
|
|
|
[credentials](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-config-files)
|
2015-07-22 22:31:00 -04:00
|
|
|
file or through environment variables Packer will use credentials provided by
|
|
|
|
the instance's IAM profile, if it has one.
|
2013-11-25 07:27:38 -05:00
|
|
|
|
2015-07-22 22:31:00 -04:00
|
|
|
The following policy document provides the minimal set permissions necessary for
|
|
|
|
Packer to work:
|
2013-11-25 07:27:38 -05:00
|
|
|
|
2017-03-25 18:13:52 -04:00
|
|
|
```javascript
|
2013-11-25 07:27:38 -05:00
|
|
|
{
|
2016-08-22 11:06:20 -04:00
|
|
|
"Version": "2012-10-17",
|
2013-11-25 07:27:38 -05:00
|
|
|
"Statement": [{
|
|
|
|
"Effect": "Allow",
|
|
|
|
"Action" : [
|
|
|
|
"ec2:AttachVolume",
|
2016-11-03 14:48:55 -04:00
|
|
|
"ec2:AuthorizeSecurityGroupIngress",
|
|
|
|
"ec2:CopyImage",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:CreateImage",
|
|
|
|
"ec2:CreateKeypair",
|
|
|
|
"ec2:CreateSecurityGroup",
|
2016-11-03 14:48:55 -04:00
|
|
|
"ec2:CreateSnapshot",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:CreateTags",
|
|
|
|
"ec2:CreateVolume",
|
|
|
|
"ec2:DeleteKeypair",
|
|
|
|
"ec2:DeleteSecurityGroup",
|
2013-11-25 07:27:38 -05:00
|
|
|
"ec2:DeleteSnapshot",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:DeleteVolume",
|
2016-08-23 17:55:01 -04:00
|
|
|
"ec2:DeregisterImage",
|
2016-06-01 12:59:25 -04:00
|
|
|
"ec2:DescribeImageAttribute",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:DescribeImages",
|
|
|
|
"ec2:DescribeInstances",
|
2016-08-23 17:54:42 -04:00
|
|
|
"ec2:DescribeRegions",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:DescribeSecurityGroups",
|
|
|
|
"ec2:DescribeSnapshots",
|
|
|
|
"ec2:DescribeSubnets",
|
|
|
|
"ec2:DescribeTags",
|
|
|
|
"ec2:DescribeVolumes",
|
|
|
|
"ec2:DetachVolume",
|
|
|
|
"ec2:GetPasswordData",
|
|
|
|
"ec2:ModifyImageAttribute",
|
2016-11-09 14:20:06 -05:00
|
|
|
"ec2:ModifyInstanceAttribute",
|
2016-12-04 14:18:27 -05:00
|
|
|
"ec2:ModifySnapshotAttribute",
|
2016-11-03 14:49:50 -04:00
|
|
|
"ec2:RegisterImage",
|
|
|
|
"ec2:RunInstances",
|
|
|
|
"ec2:StopInstances",
|
2016-11-09 14:20:06 -05:00
|
|
|
"ec2:TerminateInstances"
|
2013-11-25 07:27:38 -05:00
|
|
|
],
|
|
|
|
"Resource" : "*"
|
|
|
|
}]
|
|
|
|
}
|
2014-10-20 13:55:16 -04:00
|
|
|
```
|
2015-07-24 21:55:36 -04:00
|
|
|
|
|
|
|
## Troubleshooting
|
|
|
|
|
|
|
|
### Attaching IAM Policies to Roles
|
|
|
|
|
2017-02-21 14:13:06 -05:00
|
|
|
IAM policies can be associated with users or roles. If you use packer with IAM
|
2015-07-24 23:55:08 -04:00
|
|
|
roles, you may encounter an error like this one:
|
2015-07-24 21:55:36 -04:00
|
|
|
|
|
|
|
==> amazon-ebs: Error launching source instance: You are not authorized to perform this operation.
|
|
|
|
|
2015-07-24 23:55:08 -04:00
|
|
|
You can read more about why this happens on the [Amazon Security
|
2016-01-14 15:31:19 -05:00
|
|
|
Blog](https://blogs.aws.amazon.com/security/post/Tx3M0IFB5XBOCQX/Granting-Permission-to-Launch-EC2-Instances-with-IAM-Roles-PassRole-Permission).
|
2015-07-24 23:55:08 -04:00
|
|
|
The example policy below may help packer work with IAM roles. Note that this
|
|
|
|
example provides more than the minimal set of permissions needed for packer to
|
|
|
|
work, but specifics will depend on your use-case.
|
2015-07-24 21:55:36 -04:00
|
|
|
|
2017-03-25 18:13:52 -04:00
|
|
|
```json
|
2015-07-24 21:55:36 -04:00
|
|
|
{
|
|
|
|
"Sid": "PackerIAMPassRole",
|
|
|
|
"Effect": "Allow",
|
|
|
|
"Action": "iam:PassRole",
|
|
|
|
"Resource": [
|
|
|
|
"*"
|
|
|
|
]
|
|
|
|
}
|
|
|
|
```
|
2016-10-02 20:32:57 -04:00
|
|
|
|
|
|
|
### Checking that system time is current
|
|
|
|
|
|
|
|
Amazon uses the current time as part of the [request signing
|
|
|
|
process](http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html). If
|
|
|
|
your system clock is too skewed from the current time, your requests might
|
2016-10-03 20:36:54 -04:00
|
|
|
fail. If that's the case, you might see an error like this:
|
|
|
|
|
|
|
|
==> amazon-ebs: Error querying AMI: AuthFailure: AWS was not able to validate the provided access credentials
|
|
|
|
|
|
|
|
If you suspect your system's date is wrong, you can compare it against
|
2016-10-02 20:32:57 -04:00
|
|
|
http://www.time.gov/. On Linux/OS X, you can run the `date` command to get the
|
2016-10-03 20:36:54 -04:00
|
|
|
current time. If you're on Linux, you can try setting the time with ntp by
|
|
|
|
running `sudo ntpd -q`.
|