I’d prefer not to go down this route at all. My original goal was to
automate the creation of security groups around a cookbook. I just learned
that in order to use encrypted data bags (which the aws_security cookbook
requires since it can’t work with IAM roles) I have to deposit the secret
on the client somehow, I don’t think that scales.
If all that did scale, then my other concerns are around security. Should
an instance be able to add itself to security groups? Smells fishy. On top
of that, all the dependencies the aws_security cookbook requires take a
long time to download and install (gcc, c++, fog and so on) and also
increase the complexity and decrease the chances of an instance coming up
The problem here is not a chef one. It’s infrastructure automation.
CloudFormation has a number of limitations. One is that if you want to use
reuse code, each piece of reused code becomes a stack in unto inself, and
your very quickly going to reach your stack limit of 20. You can request an
increase, but I’ve also heard anecdotally that once you hit about 100
stacks per account, performance starts to suffer.
Chef provisioner is cool, and I have some stuff working with that. However,
it’s hard to install. I’ve been working with a developer for a week now
trying to clearly document how to install the chef client, which is
required to use chef provisioner. The biggest problem with the chef
provisioner is that it doesn’t do anything except instances (and load
balancers?). No security groups, no EBS volumes. Nothing.
I just took a look at Terraform today. I’m disappointed. It seems you can’t
have programmatic resource (ie instance) names. I imagine most people, like
us, have multiple environments, and therefore multiple instances with the
same name. It looks like the only way to do this with Terraform at the
moment would be to have multiple files, once per environment, and hard code
the resource names, eg: web01.prod.foo.com and web01.qa.foo.com.
On Mon, Nov 17, 2014 at 11:37 AM, Lamont Granquist email@example.com
On Mon Nov 17 11:23:49 2014, Thom May wrote:
I had a JIRA ticket open for ages asking for nokogiri to get included
in the omnibus build of chef (not chef-dk); I think for very little
pain it would solve a lot of pain…
chef-dk supported O/Sen != chef supported O/Sen.
the required pain would be maintaining building nokogiri on centos 5,
solaris 9, aix 6, and whatever other crazy operating systems we wind up
supporting chef-client on. and if you think building nokogiri on the
latest ubuntu and centos is painful…