Why use Packer? Infrastructure as code has become part of the buzzword bingo surrounding operational teams and their desired optimal workflows.

Theoretically, one could just start with a base AMI and manually update it, and then re-save it as a new AMI, but this process is not repeatable.  We can check in our desired infrastructure states as code to version control.  This is good practice for change control management.  We can readily see what worked before and what was changed in the latest update.  If something catastrophic happens or we encounter unforeseen issues, we can always roll back to a previous state.

I'm the first new guy on our ops team in a few years.  We work with a base image to create our EC2 instances and that image does not have my ssh keys.  In our current workflow, when I spin up a new instance using our latest base AMI, I can't ssh to the box because my key isn't on there.  Amazon has also released Amazon Linux 2, so we had a card to update the base AMI in the backlog.  I picked up this task and found the HashiCorp tool to be very powerful and useful.

  "description": "Builds a Base Image for EC2 AWS provisioner",
    "hostname": "cne-aws-trusty64",
    "config_dir": "."

  "builders": [
      "type": "amazon-ebs",
      "region": "us-east-1",
      "source_ami": "ami-04681a1dbd79675a5",
      "instance_type": "m5.xlarge",
      "ssh_username": "ec2-user",
      "ami_name": "snapdragon-v3.6.9",
      "subnet_id": "subnet-0000000000",
      "tags": {
        "OS_Version": "Amazon Linux 2",
        "Release": "2017-12",
        "Builder": "packer"
      "ssh_timeout": "60m"

  "provisioners": [
      "type": "shell",
        "scripts": [

In our setup script, we install dependencies, and a configuration management tool adds users and updates permissions as needed for all of our applications.  It's basically the equivalent of whatever you would do manually to achieve the desired state.