- 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
- [chef] Environment Cookbook Patterns & Questions, Matt Juszczak, 01/03/2015
Archive powered by MHonArc 2.6.16.