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

[Torben Knerr < >]

Personally I make a clear cut between "cookbook repositories" and
"infrastructure repositories": the former ones contain the reusable
and versioned cookbooks, while the latter ones represent my
infrastructure with its environments (dev -> test -> staging -> prod
etc). Typically I have one "infrastructure repo" per project /
application, and the structure resembles that of a chef repo quite
much, except that it does not contain any cookbooks. Any cookbooks
needed come in via dependency management (berks).

Here is an example using Vagrant as the "infrastructure DSL" (have not
looked into chef-provisioning yet):
https://github.com/tknerr/sample-infrastructure-repo

Cheers, Torben


P.S.: might be worth noting that I don't use `berks apply` to lock the
cookbook dependency graph via environments. Instead I lock the graph
in the "top-level" cookbook's metadata. This lets you use environments
in a more natural way, but it also has its drawbacks and there are
several discussions and opinions on how to do it, including the new
Policyfile feature as yet another alternative (which I have not tried
yet).


On Mon, Mar 9, 2015 at 8:31 PM, Michael Lindsay 
<
 >
 wrote:
> Over here, we are deploying micro services to environments. Our layout is
> that chef_repo is a sibling to all of our application cookbooks ( and
> cookbooks dir in chef_repo is empty )  This allows us to have both shared
> and application specific attributes in the environment file and deploy apps
> configured correctly for each of our services.
>
> On Mon, Mar 9, 2015 at 12:18 PM, Xabier de Zuazo 
> <
 >
>  wrote:
>>
>> On 2015-03-09 14:21, Fabien Delpierre wrote:
>> > [...]
>> > I could just gut the old Chef repo, removing all the cookbooks and
>> > leaving
>> > only the environments, roles and data bags, then point my Vagrantfiles
>> > to
>> > the same paths for those types of resources every time, but most of the
>> > time, the environments or roles make no sense except when considered in
>> > the
>> > context of a given cookbook.
>> >
>> > It would make sense (to me at least) to keep them with the cookbook
>> > they're
>> > meant to be used with, and to put them in the same git repo as the
>> > cookbook, but then when I use Berkshelf to create a cookbook, it creates
>> > the standard directory structure and it feels weird to me to add a
>> > ./environments and a ./roles under my cookbook's directory structure,
>> > alongside the ./attributes, ./recipes and so forth.
>> >
>> > So does it make more sense to keep the environments and roles in the
>> > same
>> > git repo as a cookbook, or continue to keep all environments and roles
>> > in a
>> > central repo, like so:
>> >
>> > chef-repo
>> >  |_ cookbooks
>> >      |_ cookbook1
>> >          |_ individual git repo
>> >          |_ Vagrantfile pointed at ../../ for environments and roles
>> >      |_ cookbook2
>> >          |_ individual git repo
>> >          |_ Vagrantfile pointed at ../../ for environments and roles
>> >      |_ etc.
>> >  |_ environments
>> >      |_ all environments ever written
>> >  |_ roles
>> >      |_ all roles ever written
>> >  |_ .gitignore to ignore contents of ./cookbooks
>> >
>> > What about data bags? Keep them directly under the repo, or with
>> > individual
>> > cookbooks? Or both, depending on what makes the most sense?
>>
>> In our case, we are using a provisioning cookbook that uses the
>> chef-provisioning gem and we put the environments and the data bags inside
>> this
>> cookbook recipes. Something like this:
>>
>> myapp_provisioning::environments
>> myapp_provisioning::data_bags
>> myapp_provisioning::roles
>> ...
>>
>> You could put them in the same cookbook, in a recipe called something like
>> `myapp::provisioning`. But that could be confusing, because those recipes
>> are
>> used differently.
>>
>> The downside is you can not include them with vagrant so easily :-(
>>
>> https://docs.chef.io/provisioning.html#chef-environment
>>
>> --
>> Xabier de Zuazo
>
>