[chef] Re: RE: Re: RE: Re: berkshelf gem listed as a requirement in cookbook gemfile

[Torben Knerr < >]

Few inline comments below

On Mon, Jan 5, 2015 at 4:57 PM, Nico Kadel-Garcia
<
 >
 wrote:
>> -----Original Message-----
>> From: Tensibai Zhaoying 
>> [mailto:
 
>> Sent: Friday, January 02, 2015 5:21 PM
>> Cc: 
>> 
 
>> Subject: [chef] Re: RE: Re: berkshelf gem listed as a requirement in 
>> cookbook
>> gemfile
>>
>> Why the hell would you do a bundle install on a node ?
>>
>> Berkshelf is of use on your workstation to create a pack of cookbooks with
>> correct versions to distribute as tarball or to upload to chef-server.
>
> Or using it under chef-solo to pull and apply on the local host.
>
>        cd /var/chef-solo
>        git pull [ designated git repo, tag, branch, etc., etc. ]
>            [ Modify locally in testable environments ]
>            [ Or checkout out git tag for production ]
>        berks install
>        berks vendor
>            [ Consistent Berksfile.lock allows use of hard-coded cookbook 
> versions, including rollback to previous version without touching upstream ]
>        chef-solo [ with configuration that looks in 
> /var/chef-solo/berks-cookbooks ]
>           [ test ]
>           [ Record git changes ]
>           [ Push git changes back upstream ]
>
> 'Deploy from tarball' involves maintaining tarballs and an available server 
> to deploy them from, and potentially pushing tarballs from a development 
> server to the chef server, which raises serious management and security 
> concerns. This also gets really hairy when older cookbooks are incompatible 
> with newer cookbooks or different chef releases, and some servers need one 
> or the other. Recent architectural changes in the yum and mysql cookbooks 
> are good examples where the chef server, itself, might need to have 
> multiple cookbooks for multiple categories of servers. And Berksfile and a 
> chef server do not trivially support deploying multiple cookbook versions, 
> especially legacy ones that have not historically been deployed on that 
> chef server. And they break *horribly* when different versions of the same 
> numbered cookbook are in use on two development  hosts with the same chef 
> server or the same "tarball building setup" as you mentioned, which happens 
> when two different people are working on different parts of the same 
> cookbook at the same time in the same chef server environment.
>

That's my workflow as well, except that I'm not bundle installing it
*on* the node, but rather from the outside. If that is a desired
scenario for you then Vagrant is a perfect fit.

Example here: 
https://github.com/tknerr/sample-toplevel-cookbook/blob/master/Gemfile


>> If your day to day workstation is a lightweight Vm you recreate often, 
>> include
>> chef-dk or do bundle install in the source template box...
>
> "Recreating vm's" is a surprisingly resource expensive operation in many 
> environments. It requires privileges to create VM's, and the sys-admin time 
> and resources to manage those privileges to prevent mistakes which may 
> corrupt critical resources. Being able to spin up  a VM or test environment 
> with only local git privileges and *no* chef server privileges is much 
> safer in many environments.
>
>> I don't see any use case where you would do a bundle install from a 
>> cookbook
>> dir within a chef run, you should install needed gems for a recipe with 
>> chef-gem
>> resource if you need it inside your recipes.
>
> Roles and node configurations and environments benefit from having 
> consistent, locked cookbooks especially between QA, staging, and production 
> environments. A "template box" is not good enough for production if you've 
> not recorded your chef changes, especially including cookbook versions, and 
> the 'Berksfile.lock' for chef-solo on individual test environments provides 
> that.
>
> There are trade-offs: you can't use "search" functions as you might on a 
> chef server. But for many test environments, testing on a single chef-solo 
> instance and then propagating it to the relevant staging or production 
> environment is quite useful.
>

You can use chef-zero though which is almost a drop-in replacement for
chef-solo, especially when using Vagrant (simply replace the
:chef_solo with the :chef_zero provisioner). This will give you more
chef-client like behaviour and especially lets you use search as with
chef server.

Cheers,
Torben


>> Please enlight me if I missed your point...
>
> I'm happy to do so: see above.
>
>
> Nico Kadel-Garcia
> Lead DevOps Engineer
> 
 
>
>
>
>
>