[chef] Re: Re: Re: Re: Re: Re: Versioned Environments


Chronological Thread 
  • From: Bryan Brandau < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Versioned Environments
  • Date: Sat, 13 Oct 2012 09:32:27 -0500

This has been a hot topic for us.  We have multiple data centers that use one chef server as the source.  As we have multiple front end load balancers that can either be running a different version of things or is in the process of going through a rolling upgrade, we've had to avoid role or environment clobbering.

When a node launches it knows what role it's supposed to be.  We've implemented what I call fancy roles.  They are versioned by a name/date combination and cookbooks are versioned inside of the role.  In the code repository we have separate directories for prod/stage/dev.  For us it's a matter of spinning up a new farm of nodes with a specific name/date role or updating the running node to the new role.  It does create some duplication but what we felt was the safest for having a set of nodes that need to maintain a specific version of state or waiting to be upgraded.

It would be incredibly nice if Chef had the same versioning concept for roles or environments that cookbooks have.  

On Sat, Oct 13, 2012 at 4:25 AM, Torben Knerr < " target="_blank"> > wrote:
Cool, thanks!


On Fri, Oct 12, 2012 at 11:52 PM, steve . < " target="_blank"> > wrote:
Sure!

For application 'app' in environments 'dev' and 'live' your data bag
might look like this:

"app": {
  "dev": {
    "0": {
      "version": "0.16.1"
      "active": "0"
    }
    "1": {
      "version": "0.11.0"
      "active": "1"
    }
  }
  "live": {
    "0": {
      "version": "0.6.1"
      "active": "1"
    }
    "1": {
      "version": "0.6.2"
      "active": "0"
    }
  }
}


Hope that helps.

On Fri, Oct 12, 2012 at 10:28 AM, Torben Knerr < " target="_blank"> > wrote:
> Sounds interesting, would you mind posting an example of your data bag?
>
> Cheers, Torben
>
> Am 11.10.2012 20:26 schrieb "steve ." < " target="_blank"> >:
>
>> I implemented application swim lanes as a data bag per application
>> with environments as items and the top-level keys being lanes.
>> ( So, production has four instances per app, each instance has a
>> version and maybe some custom attributes you use in a config template
>> or something. )
>>
>> After that, it's just a matter of retrieving the appropriate data bag
>> item for the environment and doing a for loop.
>>
>> If you spend a bit of time up front writing the cookbook with this in
>> mind, you can support additional lanes very easily -- just update the
>> application data bag.
>>
>> On Thu, Oct 11, 2012 at 9:36 AM, Adam Jacob < " target="_blank"> > wrote:
>> > I've implemented this as a series of environments that get promoted
>> > into/out of. Basically take the environment policy and attributes from A and
>> > slam them into B.
>> >
>> > Adam
>> >
>> > On Oct 11, 2012, at 5:39 AM, Michael Leikind wrote:
>> >
>> >> Hi Mike,
>> >>
>> >> Thanks for your reply,
>> >> Yes we use internal chef cookbook versions all the time, but this time
>> >> we want to use the similar for the environment.
>> >> I know environments do not support it, and I wonder of there some
>> >> "nice" workaround for this ..
>> >>
>> >>
>> >> On Oct 11, 2012, at 1:43 PM, Mike < " target="_blank"> > wrote:
>> >>
>> >>> I guess I'd be curious to understand the "versioning" of an
>> >>> environment - is the app code currently version1 on dev, and now you
>> >>> want a version2 dev environment? Or is the versioning for
>> >>> chef-specific code?
>> >>>
>> >>> If it is for chef cookbooks and such, you can version your cookbooks
>> >>> in metadata.rb, and have specific versions of your cookbook available
>> >>> for a given environment.
>> >>>
>> >>> i.e.:
>> >>> "prod" => cookbook "myapplication", "= 0.1.0"
>> >>> "dev" => cookbook "myapplication", "= 0.2.0"
>> >>>
>> >>> So any changes to the cookbook code (as long as you increment the
>> >>> version in metadata.rb) will not be applied to an environment that
>> >>> does not match the version constraints.
>> >>>
>> >>> (Read more on version constraints:
>> >>> http://wiki.opscode.com/display/chef/Version+Constraints )
>> >>>
>> >>> On Thu, Oct 11, 2012 at 7:27 AM, Michael Leikind < " target="_blank"> >
>> >>> wrote:
>> >>>> Hi All,
>> >>>>
>> >>>> I am looking for the best way for versioning the multiple
>> >>>> environments.
>> >>>> For instance, we have now 3 main environments (like dev, staging and
>> >>>> production) Now we want to have multiple environment versions per
>> >>>> each of
>> >>>> these three (dev/ver1, production/ver2, etc.)
>> >>>> Although I didn't find any Chef way to achieve that, I wonder if any
>> >>>> of you
>> >>>> have done this and what is the logic.
>> >>>> As a side note, we are using Git for source control.
>> >>>>
>> >>>> thanks !
>> >>>>
>> >>>> --
>> >>>>
>> >>>> --
>> >>>> Michael L.
>> >>>>
>> >>
>> >>
>> >
>> >





Archive powered by MHonArc 2.6.16.

§