[chef] Re: Re: Re: Re: Re: Re: Where do YOU put your environment and role files?

[Fabien Delpierre < >]

Thanks everyone for sharing your thoughts! I have things to think about.

On Mon, Mar 9, 2015 at 4:29 PM, Michael Weinberg < " target="_blank"> > wrote:

Our experience working with many clients is strongly pro-monolithic, to a point:

I draw a distinction between general wrapper cookbooks and specific logic cookbooks. I've seen myriad names for both these ideas, here's the difference:

General cookbooks: These are typically wrappers that provide a standard, within your org, means of doing something. If you regularly deployed LAMP stacks, this might be a cookbook that pulls in Apache, MySQL, and PHP, setting them up your standard fashion. Similarly, if you had a suite of security mandated things that apply everywhere, you could have a single cookbook that delivers the same setup everywhere. These are essentially "dumb" cookbooks, that do the same thing everywhere. 

Each of these make sense in their own repos, because they do not have interdependencies with other cookbooks you manage. They should be independently testable, and essentially provide known, org-specific service installations/configurations. They would generally not deploy any application code, but rather prepare a system for the application deployment.

Specific cookbooks: These are cookbooks that tie things together, and deliver application "aware" configuration logic. Here you might find "role cookbooks", or other approaches to deliver fairly granular configuration to your deployments. Another example might be a monitoring cookbook that has distinct recipes that correspond to different applications or services.  

These go in a monolithic repo, because each one has little-to-no meaning outside of the collective. This repo also holds data bags, roles, and environments. It is the only repo that uploads directly to the Chef Server. This keeps your ultimate concerns (the application and service deployment and configuration) all together, while allowing you to offload as many general items to cookbooks that are then treated as upstream dependencies. 

Michael

--

Michael F. Weinberg | Director of Operations

http://heavywaterops.com | @heavywaterops

On Mon, Mar 9, 2015 at 1:12 PM, Lamont Granquist < " target="_blank"> > wrote:

Keep in mind that the monolithic cookbook repository is not wrong, and we've committed to supporting it:

https://github.com/chef/chef-rfc/blob/master/rfc019-chef-workflows.md

You should switch only if you can see where the workflow improves for you.  If not, you'll buy yourself a lot more management cost (more git repos, more per-repo files to synchronize across multiple repos) and if there's no other benefit, then you'll spend the costs of switching plus the additional per-repo maintenance, for no gain. If you want to do CI and test cookbooks in isolation and you want to break up the monolithic repo to avoid having engineers stepping on each other toes when doing edits to the single repo or stuff like that, then it makes sense.  If its just you, it may not make sense.