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

[Ranjib Dey < >]

we use a mix of the approaches described here. We have multiple projects and each of them have multiple environments (dev, qa, staging, uat, prod), chef environments are treated as first class entities for isolation and customization. Most of the scaffolding is done automagically by enforcing conventions(like environments will be <project>-<environment>, and instances will be <proj>-<env>-<service>-<instance #>), all cookbooks inside the prod and uat are version constrained and frozen, dev and qa does not have any restriction, while staging and  qa has version constrained cookbooks but not frozen (and  upstream of prod). Nagios/graphite and other systems exploit the naming conventions to generate appropriate service groupings . In all cases we have the app environment (be it RoR or python/django or LAMP or tomcat/spring) is different from chef environments , but they are derived automatically from the chef environment. This let the devs work without necessarily tied down to the chef environments, while also eliminates manually managing multiple environments.

All our cookbooks along with the community contributed ones goes through CI, where foodcritic based lint checks, integration tests (against centos 5/6 & ubuntu 10/11), and the whole environment (chef+nodes+apps) is tested (for nodes with empty runlist, nodes that are in _default, nodes having recipes directly assigned in runlist etc).  Individual stages of cookbook testing is modeled as individual pipelines, there are multiple custom foodcritic rules (like checks for `supports` directive in metadata ) that ensures cookbooks are eligible for downstream CI stages.

From my experience, comparing individual techniques in isolation is not very helpful, in stead if we can discuss on end to end workflows, involving change management, qa, safety nates and integration with other services is something we should discuss while comparing implications of individual techniques.

On Thu, May 3, 2012 at 9:23 PM, Adam Jacob < " target="_blank"> > wrote:

Nothing wrong with manual uploading of cookbooks - the important step
is that you are taking the cookbook policy and promoting it through to
other environments, essentially.

Adam

On Wed, May 2, 2012 at 10:19 PM, Bryan Berry < "> > wrote:
> gotta say I really like Peter's solution, will have to look at it in more
> detail
>
> To answer Adam's, question I use manual upload for my cookbooks
>
> The big cause of the instability in my cookbooks is that I am essentially
> learning these applications at the same time that I write cookbooks for
> them, not the ideal situation. I am also under a lot of pressure to set up a
> quite complicated  architecture in a very short period of time.
> Consequently, many of my initial configuration choices are less than ideal.
> Going back and fixing those choices w/out breaking running apps is a
> challenge. The obvious answer here is to implement automated cookbook
> testing w/ minitest/cucumber and toft/vagrant. Once my cookbooks are more
> stable and tested, i should be able to move many of those attributes that I
> have in data_bags over to environments. The only drawback is that I will
> have a long duplicated list of cookbook version constraints in each
> environment.
>
>
> On Wed, May 2, 2012 at 2:02 AM, AJ Christensen < "> > wrote:
>>
>> 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
>
>



--
Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: ">