1

The scenario is all too common. You’re working on a product for a client and it is time to release the

first version. But in production the product does not behave as expected.

You are sad and the customer is mad…

2

You’ve worked so hard. Why has this happened? Didn’t configuration settings get documented?

Sadly, our best intentions at documentation may not reveal themselves in actual written form.

3

Setting up environments manually results in inconsistent, incongruent configurations between dev,

test and production systems.

4

Luckily, there is a tool that will allows consistency in systems. Packer is the tool I explored for the

January DevOps Ignite talk at SEP. Let’s dig in.

5

Packer is created by Hashicorp and is written in Go. Hashicorp also created Vagrant which is another

blade in the Swiss army knife of DevOps tools available.

6

Packer can create images for various platforms from a single configuration:

Amazon AMIs Docker Containers Azure Resource Manager

… and many, many more!

7

Packer templates are written in JSON. These templates contain build configurations and can also

contain provisioning and post-processing configurations.

8

A build configuration is an array of JSON objects. Each build needs to have a type defined which

determines the target. (e.g. VirtualBox, Amazon AMIs, etc.)

9

Some build configuration options are target specific. In this case, Amazon requires access and secret

keys among other parameters.

10

Many images can be built because the builder configuration is an array. These builds can also be run

in parallel which is the default but can be turned off if desired.

11

Provisioners are run after builds finish if a provisioning step is defined. Some provisioning resources

include PowerShell, Chef, Ansible or Puppet, to name a few.

12

But what about windows images? Boxstarter can create windows images in an unattended format in

conjunction with Packer. Check it out at http://www.boxstarter.org/

13

Coupling a base image with provisioners creates a beefy image to use for all your deployment needs.

14

Good-bye, Disparity! Hello, Consistent Deployments!

Of course, for the different resulting images, different target specific items can be defined, like HTTP

ports for web projects.

15

We have our golden images. What’s next? Post-processing.

Post processors do tasks outside the purview of building and configuring the image.

16

A common workflow would be to compress the new image. Simply define a compress post-processor

and its format.

17

Post-processing also allows uploading the new image to a specific repository.

18

No more guess work and manually constructing environments! With one configuration to rule them

all, everybody wins!

19

No need to waste time with guess work when it matters most. As needs change, merely add to the

template and run it through Packer again!

20

You may not use Packer everyday but when you need it, you’ll be glad you have it.

Here are a few resources to help you on your way.

21