#packer (2018-11)

@Erik Osterman (Cloud Posse) has joined the channel

@rohit has joined the channel

@tamsky has joined the channel

@catdevman has joined the channel

@rohit.verma has joined the channel

so i am just thinking about creating a custom ami off of redhat ami in aws using packer

anything i should know before i go down that path ?

I’m not a huge fan of humans reading or writing json; I use a python tool that generates ephemeral packer.json files from version-controlled packer.yaml https://gist.github.com/tamsky/c7df19684e5605023f2e biggest additional feature that tool has is: it supports !include which encourages good re-use of code.

what happens when you say !include ?

@davidvasandani has joined the channel

@joshmyers has joined the channel

@rohit what are you wanting to accomplish?

@jsanchez has joined the channel

@joshmyers we are planning to encrypt our root volume and by default it is not

so we are planning to create a custom ami off of redhat ami and also apply yum updates, install aws cli, chef-client so that when there is an autoscaling event it doesn’t take lot of time

so we are planning to solve 2 problems with this solution

are going you going build in one account and distribute to others, or build in all accounts and regions?

Have done before and it was a royal PITA (namely because of some of the IAM policies we had in place)

AMIs are region and account specific as are the KMS keys that are used

At the time we had to write a wrapper script with packer to: provision new AMI and bootstrap, take that underlying EBS volume and create a new AMI out of that

with a custom KMS key to allow for cross account policies

(you couldn’t share a default KMS key across accounts AFAICR)

I believe that this has been built natively into packer now though, not digged to see what it is doing under the covers

Note that shunting AMIs around is slooooowww

are you planning on doing this for each Chef role you have? There is overhead in managing all those AMIs (pruning script or the like)

how do your cookbooks end up on the instances in the ASG?

this will be for one aws account but in multiple regions

we would only install chef-client but the cookbook will end up later when the ami is used in a launch template

makes sense ?

Yeah, you want to block for the entire first chef run on a node before it is provisioned

You are going to have to shunt AMIs around regions

How long does your Chef bootstrap run take?

chef bootstrap currently takes somewhere aroung 8-10 mins

because the user data includes yum updates, instaling awscli, installing chef-client

by creating the custom ami we are planning to reduce this time

now that you know my usecase, is there an example that you could recommend ?

well, if you are going down this route, may as well do a first chef run during packer build, right?

Even if you don’t do it for each role you have, there is a lot common base across all I’m sure.

Can take an initial chef run from 10mins to 1 min or so

Basically updates and anything on top of base

no, we don’t want to do that because then we will have to create an AMI for each app

how much do you care about it being the exact same artefact in different regions/accounts vs building in each

each app or each role?

even if you do base, the common denominator between all your roles will shave some time off that first run

Also not suggesting baking apps into the AMI

or do you use Chef runs for app deployments?

we use chef run for app deployments

You may want to split that out.

we use chef to pull/extract artifact from artifactory

OK, I’d look into benefits of splitting out that deployment process

do a base role during packer build and have cloud-init pull in the extra role to add on?

do a base role during packer build and have cloud-init pull in the extra role to add on?

I’ve typically followed this pattern as well, @rohit – a base image, also built by packer, that other app-specific images use as their source_ami when they get built in packer.