[chef] Re: Environment Cookbook Patterns & Questions

[Christine Draper < >]

This is a great question. I'm looking forward to other people's answers.

Here's my thoughts to get the ball rolling.

It makes sense to me to create a base 'myface' cookbook that knows how to set up the logical components of the application like database servers, application servers, the actual application code etc.  I'd consider this to be an application cookbook, one that you could then reuse in multiple contexts (e.g. the different production data centers).  Perhaps it might even be reused in different lifecycle phases (prod, staging, systest).

The above might become an environment cookbook if you use it to lock down the cookbook versioning for actual deployments. In your case it sounds like intend the east and west data centers to be part of one overall production environment and want to keep them in sync from a cookbook (and application software) version perspective. If so, the environment cookbook could be 'myface-prod' and consist of little more than a berksfile.lock plus attributes to customize the application cookbook specifically for prod environment.

The key question is how you can then add in the 'east' and 'west' data center variances. Environment files for myface-prod-east and myface-prod-west would seem a decent option, if the variances are fairly simple attribute differences, and particularly if the variances were relatively independent/orthogonal to the application (e.g. updating networking information for one data center is relatively independent of changes to the myface application). You'd likely want to version the environment definitions externally in source control.  You may need to coordinate cookbook changes with environment changes, in the case where an application change requires networking changes in the two data centers.

However, if application changes routinely need different updates in the two data centers, you may want to take a different approach - e.g. creating myface-prod-east and myface-prod-west cookbooks that customize the myface cookbook for those environments.  You gain the flexibility of two separately versionable/testable cookbooks at the expense of extra coordination.

Regards,

Christine Draper

On Sat, Jan 3, 2015 at 2:04 PM, Matt Juszczak < " target="_blank"> > wrote:

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