[chef] Re: Re: Re: Any experiences building on top of Chef?

[Andrew Gross < >]

Most of the secret bootstrapping is done via IAM roles in EC2.  Instead of having keys on the machine to authenticate your API requests, the machine just has a role assigned to it so that any requests coming from that machine have access per the role definition.

Netflix gave us the idea after we questioned how they had "No keys on the machine, only in memory"

https://groups.google.com/forum/?fromgroups#!topicsearchin/asgardusers/authorname$3A"Andrew$20Gross"/asgardusers/n-1V5mmkvW4

Most metadata is kept in databags, though we are still transitioning a lot out of our monolithic app.  At the moment we "launch" from a custom AMI we created that has a base_client.pem key for initial registration, though we may transition that to download S3 in the future.

We are currently moving away from individual instance creation to having everything launched in a "Launch Configuration", wrapped in an autoscaling group.  Cloud Formation forces a bunch of this, but even for services where we do not use CFN we find it is a good practice to keep up standardization.  The main differentiator between Launch Configs is the user data, which contains the lightweight role for the machine.

On Tue, Jun 11, 2013 at 7:40 PM, Joseph Holsten < " target="_blank"> > wrote:

knife is great for adding, modifying and deleting data in your chef server. But it's way too general purpose for our node workflow. We want to make it idiot proof to ensure instance sizes, cloud-init user data, chef roles and hostnames all are consistent.

So we're similar developing tooling and workflow around cloud-init bootstrapping. We're implementing it as a knife plugin, but we're trying to get it so we only use our plugin's actions for actual node workflow. We're planning on extracting this into a standalone set of thor scripts once we've got all the use cases locked down.

Andrew: I'd be very interested in seeing your specific implementation, especially how you're bootstrapping secrets, and what metadata you keep where.
--
~j

On 2013-06-11, at 15:52, Andrew Gross < "> > wrote:

> I recommend moving away from `knife` for orchestration.  It is a great command line tool, but is not intended for heavy automation.
>
> Use the REST Api, either through Chef or Ridley.
> If possible, make it so you don't have to SSH in to bootstrap nodes (we are on EC2 and use User Data w/ cloud-init).
>
> Our automation is Python with Boto, and a dash of PyChef.  Our primary development language is python so it makes it easier for me to work with other developers and forces cleaner interfaces between the infrastructure and Chef.
>
> In our case we use Boto to set up cloud formation templates instead of configuring Zookeeper. Either is very workable once you don't need to SSH for bootstrapping.
>
>
> On Tue, Jun 11, 2013 at 12:36 PM, Noah Kantrowitz < "> > wrote:
>
> On Jun 11, 2013, at 5:32 AM, Jeppe Nejsum Madsen wrote:
>
> > Ohai,
> >
> > I would be interested in hearing how people are building tools on top of Chef. Basically I'm thinking an orchestration layer with simple tasks such as "spin up a new qa environment with latest build", "shutdown all dev environments" etc.
> >
> >
> >
> > We have all the low level components done with Chef. And while everything works using e.g. knife commands, it would be nice to shield e.g. QA from having to install chef, clone repo, remember long command lines etc.
> >
> > So, are there any good tools for these scenarios? If you've built your own, how did you approach it it? Using knife, the Chef gem or the Chef REST Api?
>
> http://pychef.readthedocs.org/en/latest/fabric.html if you are a fan of Fabric (hint: you should be).
>
> --Noah
>
>