The document discusses the challenges of inconsistent configurations in software environments and introduces Packer, a tool by HashiCorp that can create consistent images across multiple platforms using JSON templates. It outlines the key features of Packer, including build configurations, provisioners, and post-processing capabilities, which streamline the deployment process. The overall message emphasizes the importance of using Packer to achieve consistent and efficient software deployment while minimizing guesswork.

1. 1

2. 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

3. 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

4. Setting up environments manually results in inconsistent, incongruent configurations between dev,
test and production systems.
4

5. 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

6. 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

7. Packer can create images for various platforms from a single configuration:
Amazon AMIs Docker Containers Azure Resource Manager
… and many, many more!
7

8. Packer templates are written in JSON. These templates contain build configurations and can also
contain provisioning and post-processing configurations.
8

9. 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

10. Some build configuration options are target specific. In this case, Amazon requires access and secret
keys among other parameters.
10

11. 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

12. 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

13. 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

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

15. 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

16. We have our golden images. What’s next? Post-processing.
Post processors do tasks outside the purview of building and configuring the image.
16

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

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

19. No more guess work and manually constructing environments! With one configuration to rule them
all, everybody wins!
19

20. 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

21. 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