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.
Each cookbook is then autonatically "built" (binary encoded) by jenkins as payload of a shell script that is deployed on each node of its infrastructure using a custom rails webapp.
Finally we developed an internal tool to automatically create such cookbooks from a model described within a json file.
Regards,
Marco
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"> ]
Sent: Friday, April 24, 2015 12:48 PM
To: " target="_blank">
Subject: [chef] Re: RE: How to manage cookbook versions more efficiently?
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."
That's why I asked the question, you just seconded it. :)
Chris
-----Original Message-----
From: Nico Kadel-Garcia [mailto: " target="_blank"> ]
Sent: Friday, April 24, 2015 11:41 AM
To: " target="_blank">Subject: [chef] RE: How to manage cookbook versions more efficiently?
From: Fouts, Chris [mailto: " target="_blank"> ]
Sent: Thursday, April 23, 2015 10:29 AM
To: " target="_blank">
Subject: [chef] How to manage cookbook versions more efficiently?
> I use role cookbooks to pin down versions of the specific versions of the cookbooks they use. Since I have 25 nodes in my product and each node has a role, I have at least 25 role cookbooks. I just then add my role cookbooks to my nodes' run list. For example I have: the following. I DO want to pin a particular cookbook version in my role cookbooks.
> Any ideas on how to alleviate this situation?
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.
This is one of my major reasons for giving up on the "chef-server/chef-client" model, and preferring "chef-solo" for small environments. I can lock down every single cookbook in Berkshelf in a much more controlled fashion than mixing and matching and unweaving roles, cookbook, or environment wrappers, and I can apply an updated or testing cookbook on a single host with a locally updated or git branched Berkshelf.lock without potentially inflicting it on any other unexpected host. There are costs: using chefdk is a fast way to get a full Berkshelf enabled chef-solo environment, but it's not pre-built for all operating systems that Chef supports.
Nico Kadel-Garcia
Lead DevOps Engineer
" target="_blank">
Archive powered by MHonArc 2.6.16.