[chef] Re: Re: Re: Re: Workflow of Making, Testing and Using a Cookbook?

[Rajiv Ranganath < >]

On Mon, May 19, 2014 at 8:06 AM, Julian C. Dunn 
<
 >
wrote:

[...]

> I usually set things up like this for customers:
>
> + chef-repo [its own Git module, with a .gitignore containing cookbooks/*]
>   + roles
>   + environments
>   + data_bags
>   + cookbooks (empty directory, maybe with a README.md in it
> explaining why it's empty)

Following is something that we use and has worked really well for us and
our customers.

/vagrant/chef/
+ cookbooks/
+ cookbooks-for-chef-solo-run/
+ data-bags/
+ environments/
+ file-cache-path/
+ handlers/

Below are some notable differences and an overview of the approach that
we take.

-  This directory structure maps directly to what we consider are
   fundamental concepts in Chef. Its lot easier for us to explain Chef
   Server once these concepts are well understood by beginners.

   We also want to be able introduce concepts in a layered fashion, and
   this directory structure allows us to do just that.

-  Any changes to this directory structure is managed through
   - `Vagrantfile`, `solo.rb` and `client.rb`.

-  During development we use `Berksfile` and `Berksfile.lock` in
   `cookbooks/` directory to copy (or download) cookbooks and their
   dependencies to `cookbooks-for-chef-solo-run/` directory. This is
   done using the following commands,

   -  `cd /vagrant/chef/cookbooks`
   -  `berks apply`
   -  `berks install --path /vagrant/chef/cookbooks-for-chef-solo-run/`

   For beginners, this de-mystifies all the magic around cookbook
   dependencies, versioning etc., (We use Berkshelf 2.0.16 and ignore
   rest of Berkshelf features at this stage, including Berkshelf 3.x).

   Chef::Config[:cookbook_path] points to `cookbooks-for-chef-solo-run/`
   directory.

   Later when we are ready, we can nuke
   `/vagrant/chef/cookbooks-for-chef-solo-run/` directory and introduce
   Chef Server.

-  Next we introduce `Chef::Node` object along with Chef Attribute
   precedence - Automatic, Override, Normal (set) and Default. We don't
   cover (or encourage the use of) Force Default and Force Override.

   This reduces the attribute precedence to 4 levels - Automatic,
   Override, Normal and Default. However, effectively you have only
   3 because automatic attributes are read-only.

-  With `Chef::Node` object explained along with attribute precedence
   we've the required foundation to explain cookbook patterns.

-  *Yes*, we explain Cookbook Patterns to beginners. They are going to
   encounter it anyway, and we might as well teach it to them. We cover
   library, application, wrapper, base cookbook patterns.

-  We don't talk about environment cookbook pattern because to
   a beginner it can be very confusing with Chef environment. Instead we
   introduce the idea in a different way.

-  Our `cookbooks/` directory consists of,

   1.  Library Cookbooks, Application Cookbooks (when they are under
       development)

   2.  Wrapper Cookbooks and Base Cookbooks (These are checked in along
       with `cookbook/Berksfile` and `cookbooks/Berksfile.lock`)

-  We don't cover roles. That is the reason why you see it missing in
   the directory structure. We expect roles not to feature in the book
   "Chef: The Good Parts" :-)

Hopefully we can make this material (slides, exercises etc.,) available
to the community soon.

Best,
Rajiv