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

[Nico Kadel-Garcia < >]

> -----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.

> 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.

> Please enlight me if I missed your point...

I'm happy to do so: see above.


Nico Kadel-Garcia
Lead DevOps Engineer