[chef] Re: Chef Environments - Logical vs. Physical

[Daniel DeLeo < >]

On Wednesday, January 22, 2014 at 3:16 AM, Tristan Keen wrote:

  My company has a number of "Physical" environments ("clusters" ?), by which I mean a group of VMs with a copy of the major company application on for isolated use by a team/purpose - e.g. "Prod", "Staging", "Regression", "NFT", "DevTeam1", "DevTeam2".  They have some slight differences such as domains, passwords, urls, base software policy, which I want as attributes for cookbooks to consume.  Additionally, most chef searches for other nodes, e.g. to auto-find the database server, will need to be constrained to the current physical environment.

  Hence I started off using chef Environment objects & their attributes for this, but have come across advice that the one-to-one mapping between what most non-chef people think of as an "environment" and the chef concept is not such a good thing.  So I want to explore how to try using fewer "Logical" or chef environments like "Live", "Test" and "Dev", so I can flip individual VMs between them as required by the cluster/physical environment's users.  Logical environments would probably have only version constraints, and few attributes if any.

1) Anybody tried the same shift to Logical environments & care to share experiences?

2) How to represent the physical environment a node is in - e.g. a "cluster" attribute?

3) How to represent the extra attributes - a databag keyed by cluster name? A cookbook which sets attributes via code (a lot of them are very similar except for urls containing the cluster name)?

Thanks,

Tristan.

The original intention of environments was that they’d map to things like “dev”, “stage”, “prod”. That said, there’s a fundamental assumption in the design that a given cookbook version will work correctly for all of the different server types you have in those environments. For stuff that’s relatively self-contained and maps well to the “logical” environment (centralized logging, user accounts, etc.), this is fine. However, for cookbooks that you combine to build a working application service, the interactions between different cookbooks (attribute names, assumptions about where files are, etc.) are often more important than whether a cookbook “works” in isolation. This means that you need to ensure that an updated cookbook works with all of the server types that belong to a chef environment when you promote that cookbook.

Depending on your workflow, the above might be fine, but you might want to also consider mapping environments to systems’ functional roles plus logical environment, e.g., loadbalancer+prodution. This blog post describes how to do that with berkshelf, but you could adapt the ideas to your own workflow if you prefer: http://vialstudios.logdown.com/posts/166848-the-environment-cookbook-pattern

-- 

Daniel DeLeo