[chef] Re: Re: Re: RE: Best Practices for Retrieving Generated Passwords


Chronological Thread 
  • From: Andrea Campi < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: RE: Best Practices for Retrieving Generated Passwords
  • Date: Wed, 5 Dec 2012 00:24:48 +0100

Dane,

I just pushed this to Github: https://github.com/andreacampi/consume_json-cookbook
It contains some basic documentation, I trust you'll be able to figure it out (it's really trivial).

One more idea: a neat trick is to change the JSON document returned by that endpoint on every request.
Does that sound like violating the "idempotent" tenet? Read on :)

We run several dozens (and growing) of instances of pretty much the same application; they are usually pinned to the same release.
When we want to roll out a new build, we'll just tell the Rails app that emits the JSON document, and wait for the next Chef run.
On each request the controller app will randomly pick a few instances to upgrade; it will also remember not to pick that instance again for some amount of time.
Once the instance comes up after the upgrade, they will broadcast the current version info on AMQP; the controller will notice and mark that instance as up to date.

Ignoring details specific to us, what we accomplish in this way is:
* rate limiting: each Chef client will only process x work items every y minutes;
* horizontal scaling: if we need to process more per time unit, we can just add more Chef clients;
* robust retry on error with throttling;
* out of band feedback loop on the outcome of the deployment (we don't need to act on notifications, if anything goes wrong we'll just do it again after the quiet period);

Hope somebody else can find this interesting!

Andrea



On Mon, Dec 3, 2012 at 7:12 PM, Dane Elwell < " target="_blank"> > wrote:
On 2012-12-03 16:49, Andrea Campi wrote:

Another option I've used (if you have some means of authenticating the
client, e.g. own the network and can ensure IP addresses can't possibly
be spoofed):

Have the "in-house provisioning application" generate passwords and serve
a JSON (or other) file.
It's a rather simple matter to replace data bags uses with a method that
consumes JSON.
This usually ends up reducing duplication, and makes it easy to enforce
any kind of additional constraints you may have.

I will clean up and publish my consume_json cookbook if you are
interested.

Andrea

That would be quite interesting to see if you don't mind sharing? Replacing databags with that means I can invoke my requests directly to the other system rather than have that pull from the Chef server. I think this would be the best way of going about things for my intentions.

Thanks

Dane




Archive powered by MHonArc 2.6.16.

§