Thanks, but your environment does not apply to ours. We have a large infrastructure, that (may) require a different set of cookbooks per each organization. Chris From: Marco Betti [mailto:
For the same concern (roles, environments and data bags not versioned) AND due to the fact we have small infrastructures (less then 10/20 nodes for production environment) for each product on our vmware private cloud infrastructure we are currently using
chef-zero (actually chef client with local mode) instead of chef-server. We pin each cookbook exact version within Berksfile and our environment cookbook contains everything, including list of nodes, environments, roles, databags. Everything is under version
control within each "environment" cookbook, even if we don't need to pin cookbook versions within environments. Il 24/apr/2015 20:02 "Fouts, Chris" <
">
> ha scritto: Here’s an abbreviated description of our product. Say we have two different applications, say, a “cacheserver” and a “flexip” application, running
in separate RHEL VMs. For each, I created a “cacheserver_role” and a “flexip_role” cookbooks to install their respective application. They do however, share some “common” books, say a “java” cookbook. So role cookbooks’ metadata.rb files look like cacheserver_role name ‘cacheserver_role’ depends ‘java’, ‘= 1.0.0’
depends ‘cacheserver’, ‘= 1.0.0’ flexip_role name ‘flexip_role’ depends ‘java’, ‘= 1.0.0’
depends ‘flexip’, ‘= 1.0.0’ I want to purposely “pin” a specific version of the aggregate cookbooks in each role cookbook. This
is an important requirement. As you can see, if I want to update my java cookbook, I have to modify (at least) two cookbooks.
In my real product, I have more than just two role cookbooks. I’m purposely moving away from environment.json and role.json files because they are NOT versioned,
that is, they do NOT have a metadata.rb file. Chris From: Nathen Harvey [mailto:
" target="_blank">
]
I'm not sure I understand why you have a single role for each node in your infrastructure. Could you help me understand that? Or do you mean you have 25 different types of nodes in your infrastructure where each type might have N instances? Have you considered using Environments [1] for pinning your cookbook versions? I think this might be a more sustainable approach for what you've described. -Nathen On Fri, Apr 24, 2015 at 12:25 PM, Fouts, Chris <
" target="_blank">
> wrote: " For complete consistency, you have to specify every single cookbook, including all dependencies for and on your desired cookbooks in your roles or run_lists. Your role based
approach gets very nasty if you start mixing roles, and mixing conflicting cookbook versions or unintended dependencies. There were big problems when the yum and mysql cookbooks were updated and were incompatible with many older, stable, tested, production
cookbooks that relied on them." Subject: [chef] RE: How to manage cookbook versions more efficiently? |
Archive powered by MHonArc 2.6.16.