README
This commit is contained in:
parent
0dadf12164
commit
149dc65a3f
63
README.md
63
README.md
|
@ -7,6 +7,69 @@ machine images to launch into any environment, such as VirtualBox, VMware,
|
|||
Amazon EC2, etc. Because this build process is automated, you can develop in
|
||||
VirtualBox, then deploy to EC2 with an identical image.
|
||||
|
||||
## Quick Start
|
||||
|
||||
First, get Packer by either downloading a pre-built Packer binary for
|
||||
your operating system or [downloading and compiling Packer yourself](#developing-packer).
|
||||
|
||||
After Packer is installed, build your first machine image.
|
||||
|
||||
```
|
||||
$ packer build quick-start.toml
|
||||
...
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
## Templates
|
||||
|
||||
Templates are static configurations that describe what machine images
|
||||
you want to create, how to create them, and what format you finally want
|
||||
them to be in.
|
||||
|
||||
Packer reads a template and builds all the requested machine images
|
||||
in parallel.
|
||||
|
||||
Templates are written in [TOML](https://github.com/mojombo/toml). TOML is
|
||||
a fantastic configuration language that you can learn in minutes, and is
|
||||
very human-readable as well.
|
||||
|
||||
First, a complete template is shown below. Then, the details and
|
||||
structure of a template are discussed:
|
||||
|
||||
```toml
|
||||
name = "my-custom-image"
|
||||
|
||||
[builder.amazon-ebs]
|
||||
source = "ami-de0d9eb7"
|
||||
|
||||
[provision]
|
||||
|
||||
[provison.shell]
|
||||
type = "shell"
|
||||
path = "script.sh"
|
||||
|
||||
[output]
|
||||
|
||||
[output.vagrant]
|
||||
```
|
||||
|
||||
Templates are comprised of three parts:
|
||||
|
||||
* **builders** (1 or more) specify how the initial running system is
|
||||
built.
|
||||
|
||||
* **provisioners** (0 or more) specify how to install and configure
|
||||
software from within the base running system.
|
||||
|
||||
* **outputs** (0 or more) specify what to do with the completed system.
|
||||
For example, these can output [Vagrant](http://www.vagrantup.com)-compatible
|
||||
boxes, gzipped files, etc.
|
||||
|
||||
## Developing Packer
|
||||
|
||||
If you wish to work on Packer itself, you'll first need [Go](http://golang.org)
|
||||
|
|
27
packer.go
27
packer.go
|
@ -1,8 +1,31 @@
|
|||
// This is the main package for the `packer` application.
|
||||
package main
|
||||
|
||||
import (
|
||||
)
|
||||
// A command is a runnable sub-command of the `packer` application.
|
||||
// When `packer` is called with the proper subcommand, this will be
|
||||
// called.
|
||||
//
|
||||
// The mapping of command names to command interfaces is in the
|
||||
// Environment struct.
|
||||
type Command interface {
|
||||
Run(args []string)
|
||||
}
|
||||
|
||||
// The environment struct contains all the state necessary for a single
|
||||
// instance of Packer.
|
||||
//
|
||||
// It is *not* a singleton, but generally a single environment is created
|
||||
// when Packer starts running to represent that Packer run. Technically,
|
||||
// if you're building a custom Packer binary, you could instantiate multiple
|
||||
// environments and run them in parallel.
|
||||
type Environment struct {
|
||||
commands map[string]Command
|
||||
}
|
||||
|
||||
func main() {
|
||||
env := Environment {
|
||||
commands: map[string]Command {
|
||||
""
|
||||
},
|
||||
}
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue