[chef] Re: Re: Re: Re: Re: Re: Re: AWS Security Cookbook

[Douglas Garstang < >]

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

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.

Very frustrated.

Doug.

On Mon, Nov 17, 2014 at 11:37 AM, Lamont Granquist < " target="_blank"> > wrote:

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

--

Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: ">
Cell: +1-805-340-5627