[chef] Re: RE: Re: Re: RE: Re: RE: RE: RE: Re: RE: Re: No chefdk RPM available for RHEL 5?

[Daniel DeLeo < >]

On Thursday, March 26, 2015 at 3:12 PM, Nico Kadel-Garcia wrote:
> I’ve several reasons to want chefdk on individual hosts:
>  
> · Chef servers are, from painful personal experience, bulky, expensive to 
> host, and destabilizing to dynamic, mixed environments. A single mistaken 
> update to a data bag for a central service, or a simple cookbook update, 
> can take down an entire environment by screwing up every host. Particular 
> examples include:
> o Typos in ‘bind’ configuration files, for which there used to be no sanity 
> checking and would break the ‘named’ service on restart.
> o The refactoring and non-backwards-compatible update to yum, splitting off 
> “yum::epel” recipe to a separate “yum-epel” cookbook and breaking all the 
> old cookbooks that relied on yum::epel.
> o The refactoring and non-backwards-compatible update to mysql, which went 
> from a single MySQL instance configuration tool to an LWRP for multiple 
> instances, and which deleted /etc/my.cnf.
> · Using chef-solo on individual hosts makes them much safer to modify and 
> update.
> · chefdk is prefereable to the “chef-client” tool because already contains 
> precompiled copies of the libgecode software, and I can pre-deploy it in a 
> managed fashion to my chef-solo environments to manage their cookbooks 
> individually.
> o I consider the components necessary to build libgecode to be 
> inappropriate to install on lightweight, exposed servers of any sort. (gcc 
> and g++, in particular, are begging for trouble to install on a production 
> server.) chefdk is therefore, much, much safer than building libgecode.
> · I’d use librarian-chef instead of Berkshelf, but librarian-chef has a 
> nasty tendency to update every depencency for your designated cookbook is 
> unacceptable for daily use. This is unsafe, precisely because of the 
> unexpected ‘yum’ and ‘mysql’ udpates I mentioned above.
> · If you have two sysadmins developing changes on the same cookbook pushed 
> to the same chef server, you’re going to have conflicts when you both 
> upload modified cookbooks with the same number. There is no way around this 
> that fits the standard numbering schemes for chef: one of you can take a 
> *much lower* build number and keep it out of the way of the other active 
> developer, but that’s likely to cause confusion  
>  
> So, I use chef-solo for small environments, I use Berkshelf to manipulate 
> localized chef cookbook selection on each host, and I use chefdk to get 
> Berkshelf installed consistently.
>  
> Now, if I could find and shave the yak responsible for making libgecode a 
> requirement for Berrkshelf, I’d do so. But that code is a bit out of my 
> personal reach to rewrite or publish fixes for.

You’re right about the risk of dynamic updates of code to Chef Servers; 
that’s what the Policyfile feature seeks to address, and I hope you’ll give 
it a shot as it becomes available.

As for the other parts of your workflow, it seems like this is exactly what 
`berks package` is for.


--  
Daniel DeLeo