[chef] Re: Re: Re: Re: RE: Running chef in multiple environments


Chronological Thread 
  • From: Torben Knerr < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Re: RE: Running chef in multiple environments
  • Date: Sat, 26 Jul 2014 14:18:20 +0200

​Hi Tom,

same problem here. I think the "Berkshelf Way" and the patterns that Jamie describe are perfectly valid:

However I don't like the "environment cookbook" pattern because it uses environments for pinning cookbook versions, i.e. you can't use them for 'dev' / 'prod' / 'staging' anymore. Instead of environments I pin the cookbook dependency versions in a "top-level" cookbook's metadata.rb. This gets me the whole dependency graph pinned and also allows me to use environments for  'dev' / 'prod' / 'staging'. Within the environments I only pin the "top-level" cookbooks:

More discussion here and here:

Cheers,
Torben






On Sat, Jul 26, 2014 at 1:22 AM, Scott Hain < " target="_blank"> > wrote:
There are other ways of setting this up - I've seen a successful example of automated promotion using a few complicated "version pinning" mechanisms, both via environment and 'wrapper' cookbook. The key thing I noted in each of the situations where this was successful was a well defined promotion path for each cookbook as it makes its way through the environments AND some kind of automation (be it in CI or just scripts or whatever) that enforce this.

I've seen first-hand an attempt to 'promote' cookbooks between multiple chef servers and that got ugly really fast (not to say it's not possible).

Personally I've found the concept of a 'wrapper' cookbook that you can version independent of the version of the cookbook they pull in to be successful, but your mileage will vary depending on your node setup/cookbook setup/workflow, etc.


On Fri, Jul 25, 2014 at 4:09 PM, AJ Christensen < " target="_blank"> > wrote:
Use multiple Chef Servers or adopt "The Berkshelf Way"

--AJ

On Sat, Jul 26, 2014 at 2:04 AM, Sean OMeara < " target="_blank"> > wrote:
> That's a pretty old post, but I like the spirit.
> One thing I'd change is node.default instead of node.override
>
> Try not to think of "kinds of cookbooks"... they're all Just Cookbooks.
>
> -s
>
>
> On Fri, Jul 25, 2014 at 9:05 AM, Fitzwater, Brian K (CTR)
> < " target="_blank"> > wrote:
>> Check this post on using role cookbooks:
>>
>> http://realityforge.org/code/2012/11/19/role-cookbooks-and-wrapper-cookbooks.html
>>
>>
>>
>> From: Deprez, Tom [mailto: " target="_blank"> ]
>>
>> Sent: Friday, July 25, 2014 4:56 AM
>> To: " target="_blank">
>> Subject: [chef] Running chef in multiple environments
>>
>>
>>
>> Hi,
>>
>>
>>
>> We’re using chef to build our new hosting environment, which comprises of 3
>> environments (dev, staging and production), and manage our own chef server.
>> So far we’ve been using chef environments to change variables etc between
>> the 3 environments. However, we’ve come across an issue whereby we need to
>> test a new role in our dev environement.
>>
>>
>>
>> With cookbooks we can restrict the version that is used between
>> environments, but there doesn’t seem to be anything similar with roles (or
>> data bags, which is another issue).
>>
>>
>>
>> I’m just wondering, what do people do in this situation? Should we be
>> looking to run a separate chef server in each environment instead of using
>> chef environments?
>>
>>
>>
>> Thanks
>>
>> Tom
>>
>>
>>
>>
>>
>>
>>
>> HBVB trading as Bauer Corporate Services (BCS) is a division of the Bauer
>> Media
>> Group the largest consumer publisher in the UK, and second largest
>> commercial
>> radio broadcaster. BCS provides financial services and manages and develops
>> IT
>> systems on which our UK publishing, broadcast, digital and partner
>> businesses depend.
>>
>> The information in this email is intended only for the addressee(s) named
>> above.
>> Access to this email by anyone else is unauthorised. If you are not the
>> intended
>> recipient of this message any disclosure, copying, distribution or any
>> action
>> taken in reliance on it is prohibited and may be unlawful. HBVB do not
>> warrant that
>> any attachments are free from viruses or other defects and accept no
>> liability for
>> any losses resulting from infected email transmissions.
>>
>> Please note that any views expressed in this email may be those of the
>> originator
>> and do not necessarily reflect those of this organisation.
>>
>> HBVB is registered in England; Registered address is
>> 1 Lincoln Court, Lincoln Road, Peterborough, PE1 2RF.
>>
>> Registration number 8453545



--




Archive powered by MHonArc 2.6.16.

§