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