github.com/supr/packer@v0.3.10-0.20131015195147-7b09e24ac3c1/website/source/docs/builders/amazon-chroot.html.markdown (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Amazon AMI Builder (chroot)"
     4  ---
     5  
     6  # AMI Builder (chroot)
     7  
     8  Type: `amazon-chroot`
     9  
    10  The `amazon-chroot` builder is able to create Amazon AMIs backed by
    11  an EBS volume as the root device. For more information on the difference
    12  between instance storage and EBS-backed instances, see the
    13  ["storage for the root device" section in the EC2 documentation](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device).
    14  
    15  The difference between this builder and the `amazon-ebs` builder is that
    16  this builder is able to build an EBS-backed AMI without launching a new
    17  EC2 instance. This can dramatically speed up AMI builds for organizations
    18  who need the extra fast build.
    19  
    20  <div class="alert alert-block alert-warn">
    21  <p><strong>This is an advanced builder.</strong> If you're just getting
    22  started with Packer, we recommend starting with the
    23  <a href="/docs/builders/amazon-ebs.html">amazon-ebs builder</a>, which is
    24  much easier to use.</p>
    25  </div>
    26  
    27  The builder does _not_ manage AMIs. Once it creates an AMI and stores it
    28  in your account, it is up to you to use, delete, etc. the AMI.
    29  
    30  ## How Does it Work?
    31  
    32  This builder works by creating a new EBS volume from an existing source AMI
    33  and attaching it into an already-running EC2 instance. One attached, a
    34  [chroot](http://en.wikipedia.org/wiki/Chroot) is used to provision the
    35  system within that volume. After provisioning, the volume is detached,
    36  snapshotted, and an AMI is made.
    37  
    38  Using this process, minutes can be shaved off the AMI creation process
    39  because a new EC2 instance doesn't need to be launched.
    40  
    41  There are some restrictions, however. The host EC2 instance where the
    42  volume is attached to must be a similar system (generally the same OS
    43  version, kernel versions, etc.) as the AMI being built. Additionally,
    44  this process is much more expensive because the EC2 instance must be kept
    45  running persistently in order to build AMIs, whereas the other AMI builders
    46  start instances on-demand to build AMIs as needed.
    47  
    48  ## Configuration Reference
    49  
    50  There are many configuration options available for the builder. They are
    51  segmented below into two categories: required and optional parameters. Within
    52  each category, the available configuration keys are alphabetized.
    53  
    54  Required:
    55  
    56  * `access_key` (string) - The access key used to communicate with AWS.
    57    If not specified, Packer will attempt to read this from environmental
    58    variables `AWS_ACCESS_KEY_ID` or `AWS_ACCESS_KEY` (in that order).
    59    If the environmental variables aren't set and Packer is running on
    60    an EC2 instance, Packer will check the instance metadata for IAM role
    61    keys.
    62  
    63  * `ami_name` (string) - The name of the resulting AMI that will appear
    64    when managing AMIs in the AWS console or via APIs. This must be unique.
    65    To help make this unique, use a function like `timestamp` (see
    66    [configuration templates](/docs/templates/configuration-templates.html) for more info)
    67  
    68  * `secret_key` (string) - The secret key used to communicate with AWS.
    69    If not specified, Packer will attempt to read this from environmental
    70    variables `AWS_SECRET_ACCESS_KEY` or `AWS_SECRET_KEY` (in that order).
    71    If the environmental variables aren't set and Packer is running on
    72    an EC2 instance, Packer will check the instance metadata for IAM role
    73    keys.
    74  
    75  * `source_ami` (string) - The source AMI whose root volume will be copied
    76    and provisioned on the currently running instance. This must be an
    77    EBS-backed AMI with a root volume snapshot that you have access to.
    78  
    79  Optional:
    80  
    81  * `ami_description` (string) - The description to set for the resulting
    82    AMI(s). By default this description is empty.
    83  
    84  * `ami_groups` (array of string) - A list of groups that have access
    85    to launch the resulting AMI(s). By default no groups have permission
    86    to launch the AMI.
    87  
    88  * `ami_product_codes` (array of string) - A list of product codes to
    89    associate with the AMI. By default no product codes are associated with
    90    the AMI.
    91  
    92  * `ami_regions` (array of string) - A list of regions to copy the AMI to.
    93    Tags and attributes are copied along with the AMI. AMI copying takes time
    94    depending on the size of the AMI, but will generally take many minutes.
    95  
    96  * `ami_users` (array of string) - A list of account IDs that have access
    97    to launch the resulting AMI(s). By default no additional users other than the user
    98    creating the AMI has permissions to launch it.
    99  
   100  * `chroot_mounts` (list of list of strings) - This is a list of additional
   101    devices to mount into the chroot environment. This configuration parameter
   102    requires some additional documentation which is in the "Chroot Mounts" section
   103    below. Please read that section for more information on how to use this.
   104  
   105  * `copy_files` (list of strings) - Paths to files on the running EC2 instance
   106    that will be copied into the chroot environment prior to provisioning.
   107    This is useful, for example, to copy `/etc/resolv.conf` so that DNS lookups
   108    work.
   109  
   110  * `device_path` (string) - The path to the device where the root volume
   111    of the source AMI will be attached. This defaults to "" (empty string),
   112    which forces Packer to find an open device automatically.
   113  
   114  * `command_wrapper` (string) - How to run shell commands. This
   115    defaults to "{{.Command}}". This may be useful to set if you want to set
   116    environmental variables or perhaps run it with `sudo` or so on. This is a
   117    configuration template where the `.Command` variable is replaced with the
   118    command to be run..
   119  
   120  * `mount_path` (string) - The path where the volume will be mounted. This is
   121    where the chroot environment will be. This defaults to
   122    `packer-amazon-chroot-volumes/{{.Device}}`. This is a configuration
   123    template where the `.Device` variable is replaced with the name of the
   124    device where the volume is attached.
   125  
   126  * `tags` (object of key/value strings) - Tags applied to the AMI.
   127  
   128  ## Basic Example
   129  
   130  Here is a basic example. It is completely valid except for the access keys:
   131  
   132  <pre class="prettyprint">
   133  {
   134    "type": "amazon-chroot",
   135    "access_key": "YOUR KEY HERE",
   136    "secret_key": "YOUR SECRET KEY HERE",
   137    "source_ami": "ami-e81d5881",
   138    "ami_name": "packer-amazon-chroot {{timestamp}}"
   139  }
   140  </pre>
   141  
   142  ## Chroot Mounts
   143  
   144  The `chroot_mounts` configuration can be used to mount additional devices
   145  within the chroot. By default, the following additional mounts are added
   146  into the chroot by Packer:
   147  
   148  * `/proc` (proc)
   149  * `/sys` (sysfs)
   150  * `/dev` (bind to real `/dev`)
   151  * `/dev/pts` (devpts)
   152  * `/proc/sys/fs/binfmt_misc` (binfmt_misc)
   153  
   154  These default mounts are usually good enough for anyone and are sane
   155  defaults. However, if you want to change or add the mount points, you may
   156  using the `chroot_mounts` configuration. Here is an example configuration:
   157  
   158  <pre class="prettyprint">
   159  {
   160    "chroot_mounts": [
   161      ["proc", "proc", "/proc"],
   162      ["bind", "/dev", "/dev"]
   163    ]
   164  }
   165  </pre>
   166  
   167  `chroot_mounts` is a list of a 3-tuples of strings. The three components
   168  of the 3-tuple, in order, are:
   169  
   170  * The filesystem type. If this is "bind", then Packer will properly bind
   171    the filesystem to another mount point.
   172  
   173  * The source device.
   174  
   175  * The mount directory.
   176  
   177  ## Parallelism
   178  
   179  A quick note on parallelism: it is perfectly safe to run multiple
   180  _separate_ Packer processes with the `amazon-chroot` builder on the same
   181  EC2 instance. In fact, this is recommended as a way to push the most performance
   182  out of your AMI builds.
   183  
   184  Packer properly obtains a process lock for the parallelism-sensitive parts
   185  of its internals such as finding an available device.
   186  
   187  ## Using an IAM Instance Profile
   188  
   189  If AWS keys are not specified in the template or through environment variables
   190  Packer will use credentials provided by the instance's IAM profile, if it has one.
   191  
   192  The following policy document provides the minimal set permissions necessary for Packer to work:
   193  
   194  <pre class="prettyprint">
   195  {
   196    "Statement": [{
   197        "Effect": "Allow",
   198        "Action" : [
   199          "ec2:AttachVolume",
   200          "ec2:CreateVolume",
   201          "ec2:DeleteVolume",
   202          "ec2:DescribeVolumes",
   203          "ec2:DetachVolume",
   204  
   205          "ec2:DescribeInstances",
   206  
   207          "ec2:CreateSnapshot",
   208          "ec2:DeleteSnapshot",
   209          "ec2:DescribeSnapshots",
   210  
   211          "ec2:DescribeImages",
   212          "ec2:RegisterImage",
   213  
   214          "ec2:CreateTags"
   215        ],
   216        "Resource" : "*"
   217    }]
   218  }
   219  </pre>