github.com/ttysteale/packer@v0.8.2-0.20150708160520-e5f8ea386ed8/README.md (about)

     1  # Packer
     2  
     3  [![Build Status](https://travis-ci.org/mitchellh/packer.svg?branch=master)](https://travis-ci.org/mitchellh/packer)
     4  [![Windows Build Status](https://ci.appveyor.com/api/projects/status/github/mitchellh/packer?branch=master&svg=true)](https://ci.appveyor.com/project/hashicorp/packer)
     5  
     6  * Website: http://www.packer.io
     7  * IRC: `#packer-tool` on Freenode
     8  * Mailing list: [Google Groups](http://groups.google.com/group/packer-tool)
     9  
    10  Packer is a tool for building identical machine images for multiple platforms
    11  from a single source configuration.
    12  
    13  Packer is lightweight, runs on every major operating system, and is highly
    14  performant, creating machine images for multiple platforms in parallel.
    15  Packer comes out of the box with support for the following platforms:
    16  * Amazon EC2 (AMI). Both EBS-backed and instance-store AMIs
    17  * DigitalOcean
    18  * Docker
    19  * Google Compute Engine
    20  * OpenStack
    21  * Parallels
    22  * QEMU. Both KVM and Xen images.
    23  * VirtualBox
    24  * VMware
    25  
    26  Support for other platforms can be added via plugins.
    27  
    28  The images that Packer creates can easily be turned into
    29  [Vagrant](http://www.vagrantup.com) boxes.
    30  
    31  ## Quick Start
    32  
    33  **Note:** There is a great
    34  [introduction and getting started guide](http://www.packer.io/intro)
    35  for those with a bit more patience. Otherwise, the quick start below
    36  will get you up and running quickly, at the sacrifice of not explaining some
    37  key points.
    38  
    39  First, [download a pre-built Packer binary](http://www.packer.io/downloads.html)
    40  for your operating system or [compile Packer yourself](#developing-packer).
    41  
    42  After Packer is installed, create your first template, which tells Packer
    43  what platforms to build images for and how you want to build them. In our
    44  case, we'll create a simple AMI that has Redis pre-installed. Save this
    45  file as `quick-start.json`. Be sure to replace any credentials with your
    46  own.
    47  
    48  ```json
    49  {
    50    "builders": [{
    51      "type": "amazon-ebs",
    52      "access_key": "YOUR KEY HERE",
    53      "secret_key": "YOUR SECRET KEY HERE",
    54      "region": "us-east-1",
    55      "source_ami": "ami-de0d9eb7",
    56      "instance_type": "t1.micro",
    57      "ssh_username": "ubuntu",
    58      "ami_name": "packer-example {{timestamp}}"
    59    }]
    60  }
    61  ```
    62  
    63  Next, tell Packer to build the image:
    64  
    65  ```
    66  $ packer build quick-start.json
    67  ...
    68  ```
    69  
    70  Packer will build an AMI according to the "quick-start" template. The AMI
    71  will be available in your AWS account. To delete the AMI, you must manually
    72  delete it using the [AWS console](https://console.aws.amazon.com/). Packer
    73  builds your images, it does not manage their lifecycle. Where they go, how
    74  they're run, etc. is up to you.
    75  
    76  ## Documentation
    77  
    78  Full, comprehensive documentation is viewable on the Packer website:
    79  
    80  http://www.packer.io/docs
    81  
    82  ## Developing Packer
    83  
    84  If you wish to work on Packer itself or any of its built-in providers,
    85  you'll first need [Go](http://www.golang.org) installed (version 1.4+ is
    86  _required_). Make sure Go is properly installed, including setting up
    87  a [GOPATH](http://golang.org/doc/code.html#GOPATH).
    88  
    89  Next, install the following software packages, which are needed for some dependencies:
    90  
    91  - [Bazaar](http://bazaar.canonical.com/en/)
    92  - [Git](http://git-scm.com/)
    93  - [Mercurial](http://mercurial.selenic.com/)
    94  
    95  Then, install [Gox](https://github.com/mitchellh/gox), which is used
    96  as a compilation tool on top of Go:
    97  
    98      $ go get -u github.com/mitchellh/gox
    99  
   100  Next, clone this repository into `$GOPATH/src/github.com/mitchellh/packer`.
   101  Install the necessary dependencies by running `make updatedeps` and then just
   102  type `make`. This will compile some more dependencies and then run the tests. If
   103  this exits with exit status 0, then everything is working!
   104  
   105      $ make updatedeps
   106      ...
   107      $ make
   108      ...
   109  
   110  To compile a development version of Packer and the built-in plugins,
   111  run `make dev`. This will put Packer binaries in the `bin` folder:
   112  
   113      $ make dev
   114      ...
   115      $ bin/packer
   116      ...
   117  
   118  
   119  If you're developing a specific package, you can run tests for just that
   120  package by specifying the `TEST` variable. For example below, only
   121  `packer` package tests will be run.
   122  
   123      $ make test TEST=./packer
   124      ...
   125  
   126  ### Acceptance Tests
   127  
   128  Packer has comprehensive [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing)
   129  covering the builders of Packer.
   130  
   131  If you're working on a feature of a builder or a new builder and want
   132  verify it is functioning (and also hasn't broken anything else), we recommend
   133  running the acceptance tests.
   134  
   135  **Warning:** The acceptance tests create/destroy/modify *real resources*, which
   136  may incur real costs in some cases. In the presence of a bug, it is technically
   137  possible that broken backends could leave dangling data behind. Therefore,
   138  please run the acceptance tests at your own risk. At the very least,
   139  we recommend running them in their own private account for whatever builder
   140  you're testing.
   141  
   142  To run the acceptance tests, invoke `make testacc`:
   143  
   144  ```sh
   145  $ make testacc TEST=./builder/amazon/ebs
   146  ...
   147  ```
   148  
   149  The `TEST` variable is required, and you should specify the folder where the
   150  backend is. The `TESTARGS` variable is recommended to filter down to a specific
   151  resource to test, since testing all of them at once can sometimes take a very
   152  long time.
   153  
   154  Acceptance tests typically require other environment variables to be set for
   155  things such as access keys. The test itself should error early and tell
   156  you what to set, so it is not documented here.