Chef for 21 days. Part two. Creating and using a cookbook

Hi, Hi, Habrayuzer! Still with us? CHEF is interesting! We continue our voyage to the skill of the automaton warrior, which began in the first part of this article. This article will focus on the first writing experience of a cookbook , recipes , attributes, and patterns .

Before we go further, a small digression on the infrastructure. In the future, we need a couple of computers or virtual machines. Of course, there is VirtualBox, there is Vagrant, but I strongly advise using Amazon Web Services (AWS). The main reason is that AWS is universally used by different companies, and getting to know it is an added bonus to you. There are free images on it that anyone can use. There are many different services and tools that Amazon offers. Some of them are extremely relevant. I believe that this experience is a must-have experience.

Step 5. Welcome to the kitchen, baby

Welcome to the kitchen! In our hands is the most important and indispensable tool - knife !
What will we cook? Of course, our first recipe, and in order not to forget it and use it in the future - we write it in our cookbook . This is where the knife, which can create cookbooks, will help us. Of course, you can recreate the structure of the cookbook manually, but why? Better to get acquainted with the correct structure of the standard cookbook.
The knife cookbook create directive will help us in creation. It will create a folder with our first cookbook in the / cookbooks directory (you can specify its location in the knife.rb configuration file ). Let's take a look at the main content of this folder.
')

• The / attributes directory contains files with a description of cookbook attributes that can be used on the site to overwrite the values ​​of certain default values ​​of the site. These can be variables that contain paths to working directories, network port numbers for services, any specific labels of this node (for example, its role in the working environment). The most important thing when using attributes is understanding how to apply them through a recipe. How does CHEF get the standard attribute values? It has a tool called ohai , the system attribute collector used for CHEF. These attributes are not system variables, you are unlikely to see such attribute names in your OS — these are variables with logical names, such as node [“platform”] , which stores the name of the node's OS, or node [“fqdn”] - which stores full domain name of the node. If you want to make changes to the current configuration of a service / software, you must use the attribute names provided by ohai. No less important attribute property is the identification of the node - the purpose of these "tags". I will give an example from practice.
  It was necessary to create a group of virtual machines (chef-clients), associate them with the Chef-server and distribute to them cookbook-and in accordance with their role in this group (master or slave). At the stage of registering nodes on the Chef server, it is not known which node is master and which is slave . What to do, do not hand assign each? Everything was decided simply to impossible. Each node received, depending on its purpose, the attribute env_role = master or slave, which was accessible to the Chef-server. The server, in turn, on all the nodes registered on it, conducted a search on this attribute and, depending on the value, distributed cookbooks (by means of roles, which we will discuss later).
  
• Directory / files - contains a set of files that will be used for distribution to nodes. In other words, if it is necessary to generate a file with static content on a node (it is assumed that the contents of the file do not change during the process of using it), this is the directory where you place the files. Further, in the recipe, the resource cookbook_file initializes the use of your file. It is worth noting that the name of this resource indicates the absolute path of the location of the file on the node, so be careful when specifying the name. In order to specify the source file - use the resource property called source , which indicates the name of the source file located in the / files directory. Additionally, you can specify access rights to files on nodes, a user and a group of users who “own” these files.
  Another interesting property has the file name . For it, there are templates according to which a specific file can be transferred to a specific node (using the FQDN), used on a specific platform with a specific current version. Example - a file named ubuntu-12.04 will be transferred only to nodes running Ubuntu OS 12.04.
  
• The / recipies directory is the fundamental directory of our cookbook, the directory with recipes. These are our recipes . This is where we define what and how we will configure. A recipe file is a Ruby file, which obviously uses Ruby language syntax (cap here!) Depending on the complexity of the task, it may contain a description of the functional and collection of resources (for simple tasks) or a collection of resources and calls from providers ( we will talk about them below). In the recipe, you can call other recipes, build dependencies on other recipes, place script blocks for end nodes (for example, bash or powershell commands), and use many other features available to the Ruby language. It is worth remembering that the execution of the code occurs exactly in the order specified in the recipe. As a result, we have rather massive opportunities in our hands, limited by our knowledge of the Ruby language and its capabilities.
  
• Directory / templates - contains resource templates that can be used in the recipe. Templates are described in the Embedded Ruby format, have the .erb extension , and describe dynamic content that is generated based on variables, logic, or plain text. Next, the resource template is declared in the resource. The minimum ad option is as follows:
  
  

  template “/path/to/file/on/our/node.cmd” do source “node.erb” end 

  
  
  Also, it is possible to set, for example, the access rights, owner and group of owners of this file. In this particular case, a cmd file will be created on the node with the specified absolute path, the template of which is the node.erb file. This template can be a set of commands that need to be run on a node via the command line. And it can also contain some variables and logic. Variables in the template can be, for example, attributes of your cookbook, giving the template the mentioned dynamism. It looks like this:
  <%= node['sql_server']['product_key'] %> ,
  and is the declaration of the attribute (SQL server key) present in the cookbook. Also, it is worth noting that, like the file names in the / files directory, template names have the same name property, namely, they describe the correspondence of the template to a specific OS and version, or the FQDN of the node.
  
• The / providers and / resources directories are the two directories that are organized in terms of Chef by LWRP ( light-weight resource providers ). I could compare it with the concept of class in the PLO, but such a comparison may not be very correct (the programmer brothers will forgive the administrator). In the provider, you can describe the functionality , in the resources - attributes / variables and available actions (possible actions for providers that can be called from recipes). Resources are identified and associated with the provider, forming a kind of “class”.
  The interaction between parts of the LWRP is provided by using a Resource DSL - a language containing several methods for describing attributes and actions. And given that this is a variant of Ruby DSL, then Ruby code can be part of the definition of resources and providers. In order not to go into theory for a long time, here is an example of LWRP, which sends letters (for example, upon the occurrence of any event in the system).
  
  
  /providers/default.rb

  
  

   def mailing puts "\n Sending your email..." r = chef_gem "mail" do action :install end Gem.clear_paths require 'mail' options = { :address => new_resource.server, :port => new_resource.port, :mailto => new_resource.mailto, :user_name => new_resource.user_name, :password => new_resource.password, :authentication => 'plain', :enable_starttls_auto => true } Mail.defaults do delivery_method :smtp, options end mail = Mail.deliver do from options[:user_name] to options[:mailto] subject 'Hello' body new_resource.msg end end 

  
  
  
  
  
  /resources/default.rb

   actions :create default_action :create attribute :app_name, :kind_of => String attribute :user_name, :kind_of => String, :default => "" attribute :password, :kind_of => String, :default => "" attribute :server, :kind_of => String, :default => "" attribute :port, :kind_of => Integer, :default => 465 attribute :mailto, :kind_of => [String, NilClass], :default => "" attribute :from, :kind_of => [String, NilClass], :default => "" attribute :msg, :kind_of => String, :default => "Hi there" def initialize(*args) super @ action = :create End 

  
  
  
  
  I think it’s pretty obvious, even for those who haven’t met Ruby syntax as described in this file. This is the function of sending an email. In the next part, we’ll introduce you to the cookbook , which LWRP uses to send messages about changes in the system.
  

Step 6. Tasting time

Well, let's imagine that our cookbook is ready (I will give it an example and describe its use in the next section).
What to do next? How to upload it to the server and send for execution by nodes? Knife will do it for us. In order to successfully carry out further operations, we need the Chef-admin to have a correctly configured knife (the knife.rb file) and an administrator certificate (for example, admin.pem). Next, you need to go to the / chef-repo directory (where our starter kit is, for example) and, while in it, execute commands.
The first step is to make sure that the nodes are registered on the server — the knife node list . As a result, should get the names of the active nodes.
Next, upload our cookbook to the server. It should be located in the directory specified in the knife.rb file’s cookbook_path .
We execute - knife cookbook upload name-of-cookbook . As a result, a message about successful loading and the presence of our cookbook in the list received by the knife cookbook list command.
The next step is to assign the run-list node. Here you can go 2 ways - simple or correct .
Simple - immediately add a recipe to the run-list - knife node edit name-of-node and make text changes to the run-list section, adding the line “recipe [name-of-recipe]” there . And what if there are ten such recipes? Not very comfortable.

The right way is to add a role . The role file is a description of the attributes of the run-list. Including recipes. Accordingly, one role can be assigned to multiple nodes. The role file is located at / chef-repo / roles :

 name "mailer" description "Role for host that will notify us on changes" run_list "recipe[name-of-recipe]" 

In order to upload a role to the server, use the command knife role from file name-of-role-file . After loading - the role can be assigned to the run-list of the node, which we will do.

At this simple process is completed, we are ready to run the client on the site. After that, we will get a node with ( conditionally ) the cookbook implemented on it.

With this, I will finish the second part and will announce the third - more technically-oriented (with more code), which will tell you about the example of using AWS and Chef .