YoshiCheers,Hi Torben,Not sure if you know, but the A/B choice you stated above aren't actually mutually exclusive. If you want to use berkflow/berks apply to apply cookbook version locks to an environment that doesn't stop you supplying normal environment variables to the environment. Berkflow/berks apply doesn't change any attributes other than the version locks.--On Sun, Jun 21, 2015 at 6:39 AM, Torben Knerr < " target="_blank"> > wrote:Hey Doug,I believe you first have to decide for what purpose you actually want to use Chef environments, and this decision then limits the options for technically implementing this.For me the key decision is:a) if you are going to use the berkflow / the environment cookbook pattern with `berks apply environment`, then this means you will end up with one environment per nodeb) if you are going to use environments for dev / test / staging / prod stages, you probably want to share environmental attributes across many nodesPersonally, I prefer b) and try to stick to the following principles:- use environments only for supplying environment specific data- don't use environment for composing a node's run list or other node specific internals- instead I use a single "top-level" wrapper cookbook per node, which* glues together the run list* sets attributes for configuring the wrapped cookbooks* sometimes adds addional glue code* locks the whole cookbook dependency graph via metadata.rb (so I can do it per node here and not need to use an environment for that)* defines the interface for the user (i.e. README, attributes, etc..)- the environments should contain only environment specific attribute overrides + the versions of the "top-level" cookbooksSince I'm wrapping other cookbooks and setting their attributes in (the "top-level" cookbook's) recipe, I'm sometimes faced with the "computed attributes problem". I tackle that by reloading the wrapped attributes file between setting the attributes and including the recipe, e.g. here:Also, my environments often share the same data, i.e. common attributes that are environmental data but still the same for many or even all of my environments. Ranjib recently posted a nice way on how to deal with that:Hope that helps or at least gives you some more ideas. There are many ways and even more opinions ;-)Cheers,TorbenOn Fri, Jun 19, 2015 at 4:22 PM, Douglas Garstang < " target="_blank"> > wrote:DougIt doesn't seem like the benefits of gaining some revision control outweigh the maintenance disadvantages here. For all those that espouse the use of putting environment attributes into a cookbook how do you get around this?For my base cookbook it gets even worse. It would need to have every single attribute from every cookbook it includes put into the Vagrantfile's json data. This just does not scale.If I was going to put move my environmental attributes into cookbooks...When deployed to an instance, the top level run list would need to include the environmental run list. That's ok.However, when testing, this would mean that each cookbook would need to either include the environment cookbook (ie #include_recipe "env-dev") and refer to it in the metadata.rb and Berksfile files, OR I'd have to specifically put each attribute into the Vagrantfile's json data.
This might work for simple cookbooks, but it would mean the cookbook is not being effectively tested. The attributes I'm testing against aren't what really gets deployed to an instance. I also have to maintain two copies of the attributes and the worst case scenario is where the attribute is set in both places but the value in the Vagranrfile is incorrect and therefore leads to the incorrect assumption that the cookbook is working correctly.
Archive powered by MHonArc 2.6.16.