Skip to main content

Chef Solo an Introduction


Introduction

Chef Solo is simple way to begin working with Chef. It is an open source version of the chef-client that allows using cookbooks with nodes without requiring access to a server. Chef Solo runs locally and requires that a cookbook (and any of its dependencies) be on the same physical disk as the node. It is a limited-functionality version of the chef-client and does not support the following:

  • Node data storage
  • Search indexes
  • Centralized distribution of cookbooks
  • A centralized API that interacts with and integrates infrastructure components
  • Authentication or authorization
  • Persistent attributes  
Installing chef-client  (Pre-requisite : curl )
Login to your box and run the following command to install the chef. Make sure that curl program is available on your box.
 curl -L https://www.opscode.com/chef/install.sh | bash  

cropinstall.jpg
To check if the installation was successful check the version of the installed chef-solo by:
 chef-solo -v  



version.jpg                                  
Making Chef Repository
Next step is to setup a file structure that will help organize various Chef files. Opscode, the makers of Chef provide one sample structure. They call it simply the Chef Repository.

 wget http://github.com/opscode/chef-repo/tarball/master  

structure.jpg 
 tar zxf master 
 mv opscode-chef-repo-**** chef-repo/ 

structure1.jpg

Assign cookbook's path to the newly created cookbook directory inside the Chef Repository which will hold the cookbook

  mkdir .chef  
  echo "cookbook_path ['/root/chef-repo/cookbooks' ]" > .chef/knife.rb   
  knife cookbook site download apt  

.Chef folder

For Chef Solo this directory generally contains only knife.rb file. A knife.rb file is used to specify the chef-repo-specific configuration details for Knife. This file is the default configuration file and is loaded every time this executable is run. The configuration file is located at: ~/.chef/knife.rb. If a
knife.rb file is present in the . chef/knife.rb directory in the chef-repo, the settings contained within that file will override the default configuration settings. Sample content of knife.rb file can be:

 cookbook_path [ '/root/chef-repo/cookbooks' ]  
 role_path [ '/root/chef-repo/roles' ]  
 environment_path [ ' /root/chef-repo/environments ' ]  
 data_bag_path [ ' /root/chef-repo/data_bags ' ]  

Getting Started with Chef Solo
Before we're able to run Chef Solo on our servers, we will need to add two files to our local Chef repository: solo.rb and node.json.
The solo.rb file tells Chef Solo where to find the cookbooks, roles, and data bags.
The node.json file sets the run list (and any other node-specific attributes if required).

 Create a solo.rb file inside our Chef repository with the following contents:
 current_dir = File.expand_path(File.dirname(__FILE__))  
 file_cache_path "#{current_dir}"  
 cookbook_path "#{current_dir}/cookbooks"  
 role_path "#{current_dir}/roles"  
 data_bag_path "#{current_dir}/data_bags"  

Create a file called node.json inside your Chef repository with the following contents:
 {  
      "run_list": [ "recipe[<recipe-name>]" ]  
 }  
            

Example:- 
In this example i am going to install apt cookbook and the recipe which i am going to use is apt and here is my solo.rb and node.json files looks like
solo1.jpg

Our first Chef run  

Goto chef-repo folder and execute following command

 chef-solo -c solo.rb -j node.json  

run1.jpg

run_last1.jpg


How it works:

  1. solo.rb configures Chef Solo to look for its cookbooks, roles, and data bags   inside the current directory: the Chef repository.
     2. Chef Solo takes its node configuration from a JSON file, in our example we simply        called it node.json. If we're going to manage multiple servers, we'll need a separate    &nbsp &nbsp &nbsp file.
  1. Then, Chef Solo just executes a Chef run based on the configuration data found in
           solo.rb and node.json

Comments

Popular posts from this blog

EC2 Ssh Connection Refused

When ssh: connect to host ip_address port 22 Connection refused



Unable to access server???
Exactly when you see the error - “ssh: connect to host ip_address port 22: Connection refused” while connecting your AWS EC2 Instance. In order to find solution of the problem, you will go to AWS forum and other channels where you need to answers several questions first. But it's very difficult to find the actual problem. In order to get clues what the problem is, we should provide as many details as possible about what we have tried and the results we are getting. Because there are hundreds of reason why a server or service might not be accessible, also connectivity is one of the toughest issue to diagnose, especially when you are hosting something critical on your box. I've seen several topics on this problem, but none offers a solution to it.  I was not aware for what should I look at first. So I walk through from the very basics and investigated the following thing Use of verbose while ss…

jgit-flow maven plugin to Release Java Application

Introduction As a DevOps I need a smooth way to release the java application, so I compared two maven plugin that are used to release the java application and in the end I found that Jgit-flow plugin is far better than maven-release plugin on the basis of following points: Maven-release plugin creates .backup and release.properties files to your working directory which can be committed mistakenly, when they should not be. jgit-flow maven plugin doesn't create these files or any other file in your working directory.Maven-release plugin create two tags.Maven-release plugin does a build in the prepare goal and a build in the perform goal causing tests to run 2 times but jgit-flow maven plugin builds project once so tests run only once.If something goes wrong during the maven plugin execution, It become very tough to roll it back, on the other hand jgit-flow maven plugin makes all changes into the branch and if you want to roll back just delete that branch.jgit-flow maven plugin doesn…

VPC per envrionvment versus Single VPC for all environments

This blog talks about the two possible ways of hosting your infrastructure in Cloud, though it will be more close to hosting on AWS as it is a real life example but this problem can be applied to any cloud infrastructure set-up. I'm just sharing my thoughts and pros & cons of both approaches but I would love to hear from the people reading this blog about their take as well what do they think.


Before jumping right away into the real talk I would like to give a bit of background on how I come up with this blog, I was working with a client in managing his cloud infrastructure where we had 4 environments dev, QA, Pre Production and Production and each environment had close to 20 instances, apart from applications instances there were some admin instances as well such as Icinga for monitoring, logstash for consolidating logs, Graphite Server to view the logs, VPN server to manage access of people.




At this point we got into a discussion that whether the current infrastructure set-u…