This repository was forked from Opscode's blank Chef repository. My goal in creating this repository is to create a repository and corresponding documentation to help users get started in a collaborative environment with tools that are popular within the chef community. I am trying to learn and document what I've learned as I go; if I'm not doing something right, or if there is a better/easier way, please let me know so I can learn and fix any issues.

Every Chef installation needs a Chef Repository. This is the place where cookbooks, roles, config files and other artifacts for managing systems with Chef will live. We strongly recommend storing this repository in a version control system such as Git and treat it like source code.

While we prefer Git, and make this repository available via GitHub, you are welcome to download a tar or zip archive and use your favorite version control system to manage the code.

This repository contains several directories, and each directory contains a README file that describes what it is for in greater detail, and how to use it for managing your systems with Chef.

• certificates/ - SSL certificates generated by rake ssl_cert live here.
• config/ - Contains the Rake configuration file, rake.rb.
• cookbooks/ - Cookbooks you download or create.
• data_bags/ - Store data bags and items in .json in the repository.
• roles/ - Store roles in .rb or .json in the repository.

The repository contains a Rakefile that includes tasks that are installed with the Chef libraries. To view the tasks available with in the repository with a brief description, run rake -T.

The default task (default) is run when executing rake with no arguments. It will call the task test_cookbooks.

The following tasks are not directly replaced by knife sub-commands.

• bundle_cookbook[cookbook] - Creates cookbook tarballs in the pkgs/ dir.
• install - Calls update, roles and upload_cookbooks Rake tasks.
• ssl_cert - Create self-signed SSL certificates in certificates/ dir.
• update - Update the repository from source control server, understands git and svn.

The following tasks duplicate functionality from knife and may be removed in a future version of Chef.

• metadata - replaced by knife cookbook metadata -a.
• new_cookbook - replaced by knife cookbook create.
• role[role_name] - replaced by knife role from file.
• roles - iterates over the roles and uploads with knife role from file.
• test_cookbooks - replaced by knife cookbook test -a.
• test_cookbook[cookbook] - replaced by knife cookbook test COOKBOOK.
• upload_cookbooks - replaced by knife cookbook upload -a.
• upload_cookbook[cookbook] - replaced by knife cookbook upload COOKBOOK.

Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team.

To achieve its magic, Vagrant stands on the shoulders of giants. Machines are provisioned on top of VirtualBox, VMware, AWS, or any other provider. Then, industry-standard provisioning tools such as shell scripts, Chef, or Puppet, can be used to automatically install and configure software on the machine.

The repository contains a Vagrantfile that can be used to set up and manage virtual machines on your local system or in the cloud.

By default, the following boxes are configured:

• precise32 - Ubuntu 12.04 LTS (32-bit)
• precise64 - Ubuntu 12.04 LTS (64-bit)
• lucid32 - Ubuntu 10.04 LTS (32-bit)
• lucid64 - Ubuntu 10.04 LTS (64-bit)

Run vagrant up <<VM Name>>; so, for example, you could run vagrant up precise32.

Run vagrant ssh <<VM Name>>; so, for example, you could run vagrant ssh precise32.

• Suspending the virtual machine by calling vagrant suspend <<VM Name>> will save the current running state of the machine and stop it. When you're ready to begin working again, just run vagrant up <<VM Name>>, and it will be resumed from where you left off. The main benefit of this method is that it is super fast, usually taking only 5 to 10 seconds to stop and start your work. The downside is that the virtual machine still eats up your disk space, and requires even more disk space to store all the state of the virtual machine RAM on disk.

• Halting the virtual machine by calling vagrant halt <<VM Name>> will gracefully shut down the guest operating system and power down the guest machine. You can use vagrant up <<VM Name>> when you're ready to boot it again. The benefit of this method is that it will cleanly shut down your machine, preserving the contents of disk, and allowing it to be cleanly started again. The downside is that it'll take some extra time to start from a cold boot, and the guest machine still consumes disk space.

• Destroying the virtual machine by calling the vagrant destroy <<VM Name>> will remove all traces of the guest machine from your system. It'll stop the guest machine, power it down, and remove all of the guest hard disks. Again, when you're ready to work again, just issue a vagrant up <<VM Name>>. The benefit of this is that no cruft is left on your machine. The disk space and RAM consumed by the guest machine is reclaimed and your host machine is left clean. The downside is that vagrant up to get working again will take some extra time since it has to reimport the machine and reprovision it.

For installation instructions and more information, see the Vagrant's documentation: http://docs.vagrantup.com/

The repository uses five configuration files.

• config/rake.rb
• .chef/knife.rb
• Gemfile
• Vagrantfile
• .kitchen.yml

The first, config/rake.rb configures the Rakefile in two sections.

• Constants used in the ssl_cert task for creating the certificates.
• Constants that set the directory locations used in various tasks.

If you use the ssl_cert task, change the values in the config/rake.rb file appropriately. These values were also used in the new_cookbook task, but that task is replaced by the knife cookbook create command which can be configured below.

The second config file, .chef/knife.rb is a repository specific configuration file for knife. If you're using the Opscode Platform, you can download one for your organization from the management console. If you're using the Open Source Chef Server, you can generate a new one with knife configure. For more information about configuring Knife, see the Knife documentation.

http://docs.opscode.com/knife.html

The third config file, Gemfile is a repository specific configuration file for the gems used in this Chef repository. Rather than running 'gem install x; gem install y; gem install z;' on every workstation, simply install the bundler gem and then run 'bundle install' to automatically install all of the necessary gems on a workstation. The command is idempotent so users can call 'bundle install' again in the future to be sure they have all of the latest gems. For more information about using bundler, see the bundler documentation.

http://bundler.io/

The fourth config file, Vagrantfile is a repository specific configuration file for the Vagrant tool. All Vagrant configuration is done here. For a complete reference, please see the online documentation at http://vagrantup.com.

The fifth config file, .kitchen.yml is a repository specific configuration file for the Test Kitchen tool. For a complete reference, please see the online documentation at https://github.com/opscode/test-kitchen.

Read the README file in each of the subdirectories for more information about what goes in those directories.