[chef] Environment Cookbook Patterns & Questions


Chronological Thread 
  • From: Matt Juszczak < >
  • To:
  • Subject: [chef] Environment Cookbook Patterns & Questions
  • Date: Sat, 3 Jan 2015 12:04:42 -0800

Hi all,

I’ve been playing with the Berkshelf Way for quite some time now: 
application, library, base, and wrapper cookbooks all make sense to me. 
However, I’ve been stuck on two issues and reading the available 
documentation online hasn’t really solved them. I’m looking for some insight 
on how folks seem to accomplish what I’m trying to achieve.

From what I’ve read, there seems to be two ways to look at “environment 
cookbooks”: one that is application centric, and one that is code environment 
centric. 

For instance, Berksflow seems to encourage the creation of environment 
cookbooks that actually have an application name in them (such as myface), 
and then environment files live in Chef (prod, qa, dev, etc.), and the two 
get concatenated when managing the environments with a tool like “blo” (IE: 
myface-prod). However, this seems to get confusing when code and 
infrastructure environments do not go hand-in-hand. For example, our 
infrastructure lives at EC2, and there’s often different configuration for 
nodes living in US East vs US West (usually dealing with networking). 
However, instances living in both US East and US West are technically in the 
“prod” code environment, so I’m hesitant to create environment files in Chef 
called “prod-east” and “prod-west” when in actuality, these should be treated 
identically from a Chef standpoint (we’d want to upgrade cookbooks at the 
same time, etc.). How does the environment cookbook pattern handle situations 
like this where “prod” from a code environment (IE: what your customers are 
accessing) doesn’t necessarily match “prod” for an infrastructure standpoint 
(IE: multiple data centers)? And is it safe to say that environment specific 
configurations can live in environment files, as those aren’t versioned so I 
didn’t think their use was encouraged. Additionally, in this blog post 
(http://blog.vialstudios.com/the-environment-cookbook-pattern/) by Jamie 
Windsor, he states that environment cookbooks often look like application 
cookbooks. Does that mean the environment cookbook replaces the application 
cookbook in most cases? Would the myface::database_server recipe include 
everything it needs to setup a myface database server, or simply include the 
myface::database_server recipe in an application cookbook living elsewhere? 
(IE: https://github.com/reset/myface-cookbook). I’m kind of confused as to 
where the “logic” of the application goes when using the “environment 
cookbook pattern": what does the environment cookbook’s recipe look like?

As for solving the main issue, there seems to be another route that is 
entirely 100% cookbook based (with zero use of environment files or even 
roles): making environment cookbooks start with the environment name (IE: 
prod, dev) and then contain the application configuration within. For 
example, creating a prod cookbook and then having recipes like 
“prod::myface_dbserver” that installs a production my face database server 
and can be applied to any run-list anywhere. In this case, for my example I’d 
have to do something like prod-east and prod-west to accomplish what I’m 
looking for, with even more cut/pasting between the cookbooks, and/or come up 
with something perhaps I’m missing (which is why I’m emailing the list!).

Thank you for any insight!

-Matt


Archive powered by MHonArc 2.6.16.

§