First experience as a chef, or configuration management

Introduction

Automated configuration management of your computers is necessary for any company with a large fleet of computers.

Now among administrators, Puppet is very popular, but, in my opinion, products with self-defined DSL (domain-specific programming language) are limited in nature.

Chef uses Ruby-based DSL, which gives it elegance and unlimited extensibility.
')
Update: spanasik corrected me, Puppet also has, in addition to an external DSL, also an internal DSL based on Ruby .

Architecture

This application consists of a server (chef server) and client (chef-client) parts. In addition, there is a client that works without server support (chef-solo). The server is responsible for collecting and providing information about the nodes (computers running Chef) and the required actions.

From the administrator's point of view, we simply add new nodes to Chef (by running a standard script on a new node), and using the drag and drop of the necessary roles and recipes, we set up a node. The rest in the standard scenario happens automatically and without your participation.

Knots

Computers registered in Chef are called nodes. We can always view and change the list of applied recipes,
find out the different characteristics of the node (ip, fqdn, number of processors, many other parameters, your attributes), both added by you and collected by the chef itself (using ohai).

For authors of recipes, it is very important that we can always find the nodes that we need, by its attributes, and also use these attributes as we prefer in the recipe code.

For example,

template "/etc/my-software.conf" do source "my-software.conf.erb" variables :trackers => search(:node, "recipe:tracker") notifies :restart, resources(:service => "my-software"), :delayed end 

Cookbooks

To manage a fleet of cars, a set of cookbooks is used, many of which have already been written ( Opscode , 37 Signals , Engine Yard ), and some we can write ourselves (for our applications).

Cookbooks consist of metadata (define dependencies between books, and so on), recipes (actions on the target node), resource definitions (services, etc.), function libraries (just code that you can write in Ruby), templates (files, generated on the node using the embedded ruby ​​pattern engine, files (which are copied unchanged), and attributes (JSON data associated with the node).

By the way, it is important to know that such basic resources as a template, file / directory / link (copied remotely or created in place, interpreter command, package for your OS (rpm, deb etc.), init.d service, Unix user, repository VCS, and more, are already in the basic Chef distribution.

If something is missing, you can always find it or write it yourself.

Examples

Runit

Installing your product as a runit service can be done, for example, as follows:

 include_recipe "runit" # It setups runit. package "tar" do version "1.16.1-1" action :install end gem "rails" do version "2.3.5" end git "our-code" do destination "/opt/our-code" repository "git://our-code.local/our-code.git" reference "HEAD" action :export end runit_service "our-service" do restart_on(:deploy => "our-code") end 

By default, the service is created as allowed to start, your startup and logging templates will appear where needed, and then your service will always be available for management (up, down etc.).

You can also customize the scripts God or Monit.