[chef] Re: Re: conflict between using environments to manage cookbook releases and to manage application environments

[AJ Christensen < >]

Peter,

That's an awesome assertion to have as part of your run_list -- may be
stealing this one for ourselves!

--AJ

On 2 May 2012 11:43, Peter Donald 
<
 >
 wrote:
> Hi,
>
> We have a very similar requirements here but the way we represent it
> in chef is with different environments. We do not allow the _default
> environment and instead have the following set
>
> * production
> * staging (still needed as some of the infrastructure is still part of
> a manual non-chef managed release process)
> * uat
> * development
> * ci (aka integration tests)
> * desktop (i.e our desktop managed machines)
> * chef_dev (i.e. when developing cookbooks)
>
> For each of these environments we have flags indicating the
> datacenter/location of the environment and the equivalent of a
> "stable" flag. If the "stable" flag is set then we require that the
> environment explicitly lists a version of a cookbook and that the
> cookbook version is frozen. This workflow is enforced by a recipe that
> included at the start of every chef run. You can see a snippet that
> illustrates the idea at [1].
>
> [1] https://gist.github.com/2048310
>
> On Tue, May 1, 2012 at 6:47 PM, Bryan Berry 
> <
 >
>  wrote:
>> Dear Chefs,
>>
>> I am flummoxed by my conflicting needs for Chef environments. I currently
>> have 2 environments:
>>
>> _default
>> QA:   cookbooks that I am testing,  I know exactly which nodes are in here
>> and they can tolerate a service restart or two. No important nodes belong 
>> to
>> this environment
>>
>> PROD: Only stable, tested cookbook versions here, the vast majority of 
>> nodes
>> belong to this environment
>>
>> on the other hand, my organization has 4, count 'em, 4
>> application_environments
>>
>> PROD - production
>> QA   - user-facing tests
>> TS    - integration tests
>> DV    - development servers
>>
>> All of these servers should be using stable, tested cookbooks as my devs
>> don't want to be disrupted by a misbehaving cookbook. Thus all of them
>> belong to PROD chef_environment, besides the couple that I am using to test
>> cookbooks at a given moment.
>>
>> I currently manage application_environments with data bags that look like
>> this
>>
>> apps/esb.json
>> {
>>    "pr": {
>>           "database_schema": "production_schema"
>>      },
>>      "qa": {
>>           "database_schema": "qa_schema"
>>      }
>>     . . . .
>> }
>>
>> additionally, I add a top-level attribute to each node "app_env"  that
>> indicates which application_environment a node belongs to
>>
>> Some cookbooks, such as the haproxy cookbook, treat chef_environments like
>> application_environments
>>
>> I would love to treat chef_environments like application_environments but
>> that would completely break my workflow. How are others dealing w/ the
>> issues I have brought up here?
>>
>>
>
>
>
> --
> Cheers,
>
> Peter Donald