#packer (2018-11)
Discuss Packer for building AMIs and Docker Images
Archive: https://archive.sweetops.com/packer/
2018-11-30
@Erik Osterman (Cloud Posse) has joined the channel
set the channel description: Discuss Packer for building AMIs and Docker Images
@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?
set the channel topic:
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.