packer-cn/README.md

161 lines
5.4 KiB
Markdown
Raw Normal View History

# Packer
2015-01-22 21:55:34 -05:00
[![Build Status](https://travis-ci.org/mitchellh/packer.svg?branch=master)](https://travis-ci.org/mitchellh/packer)
2015-06-29 13:23:44 -04:00
[![Windows Build Status](https://ci.appveyor.com/api/projects/status/github/mitchellh/packer?branch=master&svg=true)](https://ci.appveyor.com/project/hashicorp/packer)
2015-01-22 21:55:34 -05:00
2013-06-09 01:56:34 -04:00
* Website: http://www.packer.io
* IRC: `#packer-tool` on Freenode
* Mailing list: [Google Groups](http://groups.google.com/group/packer-tool)
2013-06-09 01:35:58 -04:00
Packer is a tool for building identical machine images for multiple platforms
from a single source configuration.
2013-06-09 01:35:58 -04:00
Packer is lightweight, runs on every major operating system, and is highly
performant, creating machine images for multiple platforms in parallel.
Packer comes out of the box with support for the following platforms:
* Amazon EC2 (AMI). Both EBS-backed and instance-store AMIs
* DigitalOcean
* Docker
* Google Compute Engine
* OpenStack
* Parallels
* QEMU. Both KVM and Xen images.
* VirtualBox
* VMware
Support for other platforms can be added via plugins.
The images that Packer creates can easily be turned into
2013-06-28 09:36:01 -04:00
[Vagrant](http://www.vagrantup.com) boxes.
2013-03-23 18:59:17 -04:00
## Quick Start
2013-06-28 09:36:01 -04:00
**Note:** There is a great
[introduction and getting started guide](http://www.packer.io/intro)
2013-06-28 09:36:01 -04:00
for those with a bit more patience. Otherwise, the quick start below
will get you up and running quickly, at the sacrifice of not explaining some
key points.
2013-06-28 16:54:31 -04:00
First, [download a pre-built Packer binary](http://www.packer.io/downloads.html)
2013-06-28 09:36:01 -04:00
for your operating system or [compile Packer yourself](#developing-packer).
2013-03-23 18:59:17 -04:00
2013-06-09 01:35:58 -04:00
After Packer is installed, create your first template, which tells Packer
what platforms to build images for and how you want to build them. In our
case, we'll create a simple AMI that has Redis pre-installed. Save this
file as `quick-start.json`. Export your AWS credentials as the
`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables.
2013-06-09 01:35:58 -04:00
```json
{
"variables": {
"access_key": "{{env `AWS_ACCESS_KEY_ID`}}",
"secret_key": "{{env `AWS_SECRET_ACCESS_KEY`}}"
},
2013-06-09 01:35:58 -04:00
"builders": [{
"type": "amazon-ebs",
"access_key": "{{user `access_key`}}",
"secret_key": "{{user `access_key`}}",
2013-06-09 01:35:58 -04:00
"region": "us-east-1",
"source_ami": "ami-de0d9eb7",
2013-06-28 09:36:01 -04:00
"instance_type": "t1.micro",
2013-06-09 01:35:58 -04:00
"ssh_username": "ubuntu",
2013-08-08 20:01:41 -04:00
"ami_name": "packer-example {{timestamp}}"
2013-06-09 01:35:58 -04:00
}]
}
```
Next, tell Packer to build the image:
2013-03-23 18:59:17 -04:00
```
2013-05-09 00:09:19 -04:00
$ packer build quick-start.json
2013-03-23 18:59:17 -04:00
...
```
Packer will build an AMI according to the "quick-start" template. The AMI
will be available in your AWS account. To delete the AMI, you must manually
delete it using the [AWS console](https://console.aws.amazon.com/). Packer
builds your images, it does not manage their lifecycle. Where they go, how
they're run, etc. is up to you.
2013-06-09 01:35:58 -04:00
## Documentation
2013-03-23 18:59:17 -04:00
2013-06-09 01:35:58 -04:00
Full, comprehensive documentation is viewable on the Packer website:
2013-03-23 18:59:17 -04:00
2013-06-09 01:35:58 -04:00
http://www.packer.io/docs
2013-03-23 18:59:17 -04:00
2013-03-23 03:48:20 -04:00
## Developing Packer
If you wish to work on Packer itself or any of its built-in providers,
2015-05-29 11:37:41 -04:00
you'll first need [Go](http://www.golang.org) installed (version 1.4+ is
_required_). Make sure Go is properly installed, including setting up
a [GOPATH](http://golang.org/doc/code.html#GOPATH).
2013-06-29 17:32:27 -04:00
Next, install the following software packages, which are needed for some dependencies:
- [Bazaar](http://bazaar.canonical.com/en/)
- [Git](http://git-scm.com/)
- [Mercurial](http://mercurial.selenic.com/)
Then, install [Gox](https://github.com/mitchellh/gox), which is used
as a compilation tool on top of Go:
$ go get -u github.com/mitchellh/gox
2013-03-23 03:48:20 -04:00
Next, clone this repository into `$GOPATH/src/github.com/mitchellh/packer`.
Install the necessary dependencies by running `make updatedeps` and then just
type `make`. This will compile some more dependencies and then run the tests. If
this exits with exit status 0, then everything is working!
$ make updatedeps
...
$ make
...
2013-05-09 00:09:19 -04:00
To compile a development version of Packer and the built-in plugins,
run `make dev`. This will put Packer binaries in the `bin` folder:
2014-04-26 18:10:33 -04:00
$ make dev
...
$ bin/packer
...
2013-09-03 11:53:29 -04:00
If you're developing a specific package, you can run tests for just that
package by specifying the `TEST` variable. For example below, only
`packer` package tests will be run.
$ make test TEST=./packer
...
2015-05-26 16:50:45 -04:00
### Acceptance Tests
Packer has comprehensive [acceptance tests](https://en.wikipedia.org/wiki/Acceptance_testing)
covering the builders of Packer.
If you're working on a feature of a builder or a new builder and want
verify it is functioning (and also hasn't broken anything else), we recommend
running the acceptance tests.
**Warning:** The acceptance tests create/destroy/modify *real resources*, which
may incur real costs in some cases. In the presence of a bug, it is technically
possible that broken backends could leave dangling data behind. Therefore,
please run the acceptance tests at your own risk. At the very least,
we recommend running them in their own private account for whatever builder
you're testing.
To run the acceptance tests, invoke `make testacc`:
```sh
$ make testacc TEST=./builder/amazon/ebs
...
```
The `TEST` variable is required, and you should specify the folder where the
backend is. The `TESTARGS` variable is recommended to filter down to a specific
resource to test, since testing all of them at once can sometimes take a very
long time.
Acceptance tests typically require other environment variables to be set for
things such as access keys. The test itself should error early and tell
you what to set, so it is not documented here.