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

[Peter Donald < >]

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