Enough of setting things up now, time for some action!
Getting a node or VM to try stuff out!
We will use Vagrant, to create our nodes. To know more about Vagrant you can see some of the earlier post "
Vagrant - Simplified and mastered!" and some more in this series.
We see that within the chef-repo there is a Vagrantfile which is the config file to create a node or a VM.
So we will just bring up a VM by using the "vagrant up" command.
vagrant up
to know the details of the node
vagrant ssh-config
To connect to this server
ssh vagrant@127.0.0.1 -p 2222
and we see on how to connect to it. Or even vagrant ssh comments also helps us in connecting to our instance.
Bootstrapping a node!
Is nothing but installing the chef-client on the node, there are two ways of doing it one of them is the attended and the other unattended.
The default for this approach assumes that node can access the Chef website so that it may download the chef-client package from that location.
The omnibus installer will detect the version of the operating system, and then install the appropriate version of the chef-client using a single command to install the chef-client and all of its dependencies, including an embedded version of Ruby, RubyGems, OpenSSL, key-value stores, parsers, libraries, and command line utilities.
The omnibus installer puts everything into a unique directory (opt/opscode/) so that the chef-client will not interfere with other applications that may be running on the target machine. Once installed, the chef-client requires a few more configuration steps before it can perform its first chef-client run on a node.
knife bootstrap FQDN/IP address
--sudo
-x ssh_username
-P ssh_password
-p ssh_port
-N "nickname to refer to latter"
all of this put together
knife bootstrap 127.0.0.1 --sudo -x vagrant -P vagrant -p 22 -N "vm1"
its sheer joy to see it come up!
Troubleshooting: In case you get the error such as this on vagrant up
'require': cannot load such file -- log4r (LoadError)
this comes up when Vagrant is installed using apt-get. Hence download and install vagrant from the download page.
Going back to the Chef Enterprise server console we see that this target has been added.
We see the "vm1" added and below is the complete and detailed profile, which has come due to the system profiler called Ohai running on the node!
we can run ohai on our machine and see the amount of details its throws up on the screen.
Creating our First Cookbook
Definition from
here.
A cookbook is the fundamental unit of configuration and policy distribution. Each cookbook defines a scenario, such as everything needed to install and configure MySQL, and then it contains all of the components that are required to support that scenario, including:
- Attribute values that are set on nodes
- Definitions that allow the creation of reusable collections of resources
- Libraries that extend the chef-client and/or provide helpers to Ruby code
- Recipes that specify which resources to manage and the order in which those resources will be applied
- Custom resources and providers
- Metadata about recipes (including dependencies), version constraints, supported platforms, and so on
Let's try to write a cookbook to bring up a webserver for this, we would do the following:-
- Install Apache
- Start the service
- Make sure it boots when the machine starts
- Customise the home page.
Creating the cookbook by the name "apache" by running the below command on the workstation and in the chef-repo directory
knife cookbook create apache
This creates a new folder called apache under cookbooks and we will edit the default recipe
before we start editing this file, lets take a look at what chef "Resources" are
- A resource is a key part of a recipe.
- A resource defines the actions that can be taken, such as when a package should be installed, whether a service should be enabled or restarted, which groups, users, or groups of users should be created, where to put a collection of files, what the name of a new directory should be, and so on.
- Each resource is processed in the same order as they appear in a recipe.
- The chef-client ensures that the same actions are taken the same way everywhere and that actions produce the same result every time.
- A resource is implemented within a recipe using Ruby.
- Where a resource represents a piece of the system (and its desired state), a provider defines the steps that are needed to bring that piece of the system from its current state into the desired state. These steps are de-coupled from the request itself. The request is made in a recipe and is defined by a lightweight resource. The steps are then defined by a lightweight provider.
A resource is a Ruby block with four components: a type, a name, one (or more) attributes (with values), and one (or more) actions. The syntax for a resource is like this:
type "name" do
attribute "value"
action :type_of_action
end
For example, a resource that is used to install a tar.gz package for version 1.16.1 may look something like this:
package "tar" do
version "1.16.1-1"
action :install
end
Every resource has its own set of actions and attribute. Most attributes have default values. Some attributes are available to all resources, for example some attributes are used to send notifications to other resources, whereas others are used to set up conditional execution rules.
All actions have a default value. Only non-default behaviours of actions and attributes need to be specified. For example, the package resource’s default action is to install and the name of the package defaults to the "name" of the resource, therefore it is possible to write a resource block like this:
and the chef-client will use the default action (
:install) to install the
tar package.
refer this for more
so we will have the following now
package "apache2" do
action :install
end
now that we want this service to be enabled even in reboot.
service "apache2" do
action [:start, :enable]
end
next we will need to write the home page, so we will use the resource "cookbook_file" which is
The cookbook_file resource is used to transfer files from a sub-directory of the files/ directory in a cookbook to a specified path that is located on the host running the chef-client or chef-solo.
cookbook_file "/var/www/index.html" do
source "index.html"
mode "0644"
end
now in the above we are asking chef to take the file called index.html and push it to the node
now to push this cookbook to the node, we use the command
knife cookbook upload apache
and to take a look at what has been uploaded
Now about the recipes
A recipe: Must be added to a run-list before it can be used by the chef-client
Is always executed in the same order as listed in a run-list
What's a RunList now!
Again by definition:-
A run-list is an ordered list of recipes and/or roles that are run in an exact order.
A run-list is always specific to the node on which it runs, though it is possible for many nodes to have run-lists that are similar or even identical.
The items within a run-list are maintained using Knife and are uploaded to the server and stored as part of the node object for each node.
The chef-client always configures a node in the exact order specified by its run-list and will never run the same recipe twice.
A recipe is the most fundamental configuration element within the organization.
So we see that a recipe in itself is of now use unless we've added it to the runlist.
and now log into the VM or the node and run the command
sudo chef-client
yes, it will give an error, as the apt-get cache is outdated and we would need to update it, but let's automate that, instead of having a manual process to do this and at the same time see how order matters in runlists. We will create one more recipe in a new cookbook for apt.
We create the cookbook called apt_cache_update, then add a recipe and upload it.
and go into the Chef management console and add the newly created recipe and add it to being the first one in the order.
save and now lets run the chef-client on the node to see what happens!
and finally when we try to access use a browser to get this webpage on port 8080 we get the home page that we created!
