Статья из журнала Системный Администратор

В эпоху виртуальных машин на первый план выходит быстрота развертывания и гибкость управления большим количеством систем. Chef с указанными задачами справится очень просто.

По мере увеличения количества информационных систем все более острой становится проблема их развертывания и последующего сопровождения. Ведь, чтобы в ручную справится с десятком серверов уже необходимы средства, позволяющие как то систематизировать и автоматизировать установочные настройки и дальнейшие их изменения. Поэтому необходимость в приложениях помогающих автоматизировать процесс изменения конфигурации систем, и контроля управления очевидна. Традиционный подход, который описан в многочисленной документации нам не дает самого главного преимущества – повторяемости. Каждый раз администратор выполняет одну и ту последовательность действий – установка и конфигурирование ОС и приложений, которая отбирает много времени, в случае перестройки эту операцию следует выполнить на каждой системе. Но с ростом популярности виртуальных систем количество серверов даже в небольшой сети может вырасти пропорционально и работы в любом случае добавится. Наверное поэтому проекты Puppet, Cfengine, Symbolic которые тихо и мирно развивались несколько лет, усилиями энтузиастов вдруг получили новый толчок и выросшее сообщество. Опыт их эксплуатации дал жизнь новым проектам.

Возможности Chef

Молодой в этом списке проект Chef (http://wiki.opscode.com/display/chef/Home) возник как внутренняя разработка компании Opscode. При создании Chef основной целью было обеспечить построение полностью автоматизированной инфраструктуры, в которой все компоненты могли бы общаться друг с другом и в будущем, максимально исключить вмешательство администратора. Не все цели на данный момент достигнуты, но проект не стоит на месте. Входе многолетней эксплуатации Unix систем, разработчики сформировали ряд требований к подобного рода решениям, но ни один из доступных инструментов по разным причинам не подошел. Поэтому и было принято решение вместо поддержки старых, создать свой вариант, естественно учтя опыт других решений развивающихся уже несколько лет. По своему принципу Chef относится к декларативным системам аналогичным Cfengine и Puppet. C последним кстати чаще всего и сравнивают Chef в тех немногочисленных обзорах, которые можно найти поиском в Интернет. Некоторые разработчики Chef участвовали в поддержке Puppet, но Chef не является его ответвлением, а полностью самостоятельный продукт, хотя ни кто не против их возможной их интеграции в будущем.
Написан Chef на языке высокого уровня Ruby, этот же язык и используется при создании конфигураций. Собственно использование языка общего назначения, которым является Ruby, считается и силой и слабостью Chef, по сравнению с тем же Puppet. Такой подход не требует переучиваться для тех кто уже изучил этот язык, а разработчик конфигураций получает всю мощь Ruby. Для тех, кто не знаком с Ruby возможно это минус, но для составления и редактирования правил достаточно прочитать небольшое руководство “Just Enough Ruby for Chef”, в котором описаны базовые возможности. Кроме Ruby в правила Chef можно включать и другие языки – Python, Perl, Erlang и shell, хотя анализ уже доступных правил показывает, что такая возможность пока не очень популярна.
В Puppet, который сам написан на Ruby для описания правил используется собственный язык, который более адаптирован для выполнения задач управления, у него убрано все лишнее, поэтому он прост и не требует долгого изучения. Хотя в Puppet также возможно использование шаблонов на Ruby.
У Puppet за несколько лет уже сформировано большое сообщество, доступны многочисленные шаблоны для большинства приложений и задач, плюс добавим сюда многочисленную документацию, описывающую основные нюансы установки и эксплуатации, наличие понятных видеоруководств, сами разработчики уже получили опыт в платной поддержке. К слову со времени первой статьи, Puppet шагнул далеко вперед и может похвастаться фронтендами – Foreman или Symbolic.
Всем этим похвастаться Chef пока не может, документация на сайте есть, но написана она как говорят «под себя». Все тонкости в ней не отражены, поэтому стороннему человеку придется некоторое время потратить чтобы разобраться что к чему. А это не просто, так как проект очень активно развивается. В каждой появляются новые возможности, которые требуют наличия сторонних компонентов или определенных версий библиотек. Поэтому процесс первоначального знакомства может чуть затянуться. Хотя именно динамичность проекта и гибкость в создании правил привлекает администраторов в Chef.
Лицензируется Chef по условиям Apache License Version 2.0, что позволяет другим проектам включать его в свои решения. Собственно Chef и разрабатывался с учетом простой и быстрой интеграции. К Chef также доступны фронтэнды свой и коммерческий Engine Yard AppCloud. Месячная стоимость лицензии последнего рассчитывается на основании ряда факторов (количество приложений, серверов, их тип, наличие поддержки и другие). На сайте Engine Yard доступна веб-форма при помощи которой можно ее рассчитать (рис.1).

На сайте Chef нет четкого списка поддерживаемых ОС, на котором можно развернуть клиентскую и серверную часть только в документации сказано, что установка протестирована на Ubuntu 8.04 +, Debian 5.0, CentOS 5.3, Fedora 10, OpenBSD 4.6, FreeBSD 7.1 и Gentoo. Хотя очевидно, что Chef будет работать на всех платформах для которых доступен Ruby, в том числе и Windows.
Chef как и другие подобные решения, построен по клиент-серверной схеме, предусмотрено использование клиента без сервера в автономном узле (shef-solo). После запуска клиент (shef-client) собирает данные об операционной системе при помощи специального приложения Ohai, написанного в рамках проекта. Далее проверяются данные полученные с сервера в предыдущий сеанс, добавляются все атрибуты в результате строится узел (Node). Теперь клиент подключается к серверу, для аутентификации с сервером используется OpenID. В случае успеха производится синхронизация данных Cookbooks (Libraries, Attributes, Definitions, Recipes), сохранение их в локальном кэше и затем компиляция коллекций ресурсов. После клиент отбирает все, что относится к нему, сохраняет состояние на сервер (для возможности отката), перестраивает узел и опять отправляет данные о состоянии на сервер. В Chef используют некоторые сторонние разработки. Так для обслуживания очередей обновлений используется платформа мгновенных сообщений RabbitMQ (rabbitmq.com), который работает в связке с Solr (lucene.apache.org/solr, сервис chef-solr) предоставляя ему очереди сообщений, обработка очередей производится при помощи stompserver (stompserver.rubyforge.org), обмен данными происходит в текстовом формата JSON (JavaScript Object Notation, json.org), результат и некоторые установки сохраняются в базу CouchDB (couchdb.apache.org).
К слову использование shef-solo также имеет смысл. Создав один раз настройку, мы затем можем ее быстро применить на любом количестве компьютеров, автоматизировав процесс, избегая не нужной монотонной работы, но не прибегая к развертыванию всей структуры.

Поваренная книга Chef

Фундаментом Chef является Cookbooks, которые содержат все необходимые установки для автоматизации развертывания приложений. Как правило, для каждого приложения создается отдельный Cookbook, который располагается в отдельном каталоге. Хотя ни кто не мешает самостоятельно создать свой Cookbooks под определенную задачу, в котором собрать ссылки на другие Cookbooks. Проект предоставляет GIT репозитарий (http://github.com/opscode/cookbooks/tree/master/) в котором можно найти самые свежие “рецепты”, кроме этого доступны репозитарии сообщества и отдельных разработчиков, которые можно использовать в качестве шаблона.

$ sudo apt-get install git-core
$ git clone git://github.com/opscode/cookbooks.git 

Для создании новой Cookboks используется команда “rake new_cookbook”, с указанием ее названия.

$ rake new_cookbook COOKBOOK=nginx

В результате будет создана вся необходимая структура. Внутри каталога Cookbooks содержится несколько файлов и подкаталогов имеющих определенное назначение. Все тонкости Cookbooks разбирать не будем, именно этот вопрос в документации освещено более менее хорошо. Основной файл называется metadata.rb содержит описание, данные мантайнера, лицензию, список поддерживаемых ОС, зависимости, конфликты и атрибуты. Например:

# список поддерживаемых ОС
%w{ ubuntu debian }.each do |os|
  supports os
end

# зависимости

%w{ build-essential runit }.each do |cb|
  depends cb
end

Даже если вы ни разу не писали в Ruby, смысл должен быть понятен. Параметр %w описывает строковый массив, а свойство .each перебирает элементы этого массива, do-end для каждого элемента выполняет выбранное действие. То есть в первом примере мы «получаем»:

support ubuntu
support debian

Поддерживаются все возможные элементы языка Ruby (группы, массивы, сравнения и так далее), например, очень просто можно задать версию дистрибутива — ‘ubuntu’, «>= 8.04».
Далее обычно идут описания атрибутов, которые необходимо сконфигурировать:

attribute "nginx/dir",
  :display_name => "Nginx Directory",
  :description => "Location of nginx configuration files",
  :default => "/etc/nginx"

attribute "nginx/worker_connections",
  :display_name => "Nginx Worker Connections",
  :description => "Number of connections per worker",
  :default => "1024"

Принцип думаю понятен.
Каталог recipes содержит собственно рецепты, которые инкапсулируют коллекции ресурсов. В таком файле можно указать какой пакет требуется установить, создать нужные файлы и каталоги, установить разрешения и так далее. Важное отличие Chef от Puppet, это то, что рецепты выполняются в порядке их объявления, какой либо технологии отслеживания зависимостей в Chef пока нет. Но можно использовать другие рецепты на которые указать командой include_recipe. Кроме этого Chef содержит систему индексов поиска позволяющую хранить данные на сервере и использовать их в рецептах. По умолчанию в каталоге recipes всегда должен находиться файл default.rb, к которому файлу затем можно обратиться в других рецептах по имени Cookbooks. Например, файл nginx/recipes/default.rb, соответствует – ngnix, а файлу — nginx/recipes/ssl.rb – ngnix::ssl. Переопределить значения в default.rb или указать специфические настройки можно в отдельных *.rb файлах, которые находятся в этом же подкаталоге. В них же можно хранить шаблоны конфигурационных файлов, которые затем подключаться при помощи параметра source. Например, чтобы установить пакет ngnix, достаточно прописать в default.rb одну строку:

package "nginx"

Для обновления пакета добавляем такую конструкцию:

do 
action :upgrade
end

Подключим шаблон конфигурационного файла (templates/nginx.conf.erb) и установим права:

template "nginx.conf" do
  path "/etc/ngnix/nginx.conf"
  source "nginx.conf.erb"
  owner "root"
  group "root"
  mode "0644"
end

В настоящее время все рецепты ограничены одним уровнем, то есть создавать подкаталоги в recipes пока нельзя.
В таком виде как описано выше о кроссплатформенности и говорить нечего, ведь мы жестко вбили имя файла в рецепт. Но Chef предоставляет нам возможность описать независимую конфигурацию, установив в каталоге attributes параметры специфические для различных систем. Меняем строку в примере:

path "/etc/ngnix/nginx.conf"

На

path "#{node[:nginx][:dir]}/nginx.conf"

Открываем файл attributes/default.rb и указываем атрибуты:

case platform
when "debian","ubuntu"
  set[:nginx][:dir]     = "/etc/nginx"
  set[:nginx][:log_dir] = "/var/log/nginx"
  set[:nginx][:user]    = "www-data"
  set[:nginx][:binary]  = "/usr/sbin/nginx"
else
…
end

И так далее. В каталоге templates размещаются шаблоны файлов. В принципе это может быть готовый конфигурационный файл, но как правило все параметры в нем также заменены attributes. Теперь при компиляции коллекции для конкретного узла будут произведены соответствующие подстановки из attributes в recipes и templates. Причем атрибуты для конкретного узла автоматически сохраняются и при последующей перестройке будут использованы повторно.
Кроме set в файле могут быть использованы параметры set_unless и default, которые устанавливают значение по умолчанию (default это псевдоним set_unless)

set_unless[:nginx][:gzip] = "on"

Так же как и для рецептов можно включать атрибуты других приложений, для этого используется инструкция include_attribute. Определения в каталоге definitions собственно и предназначены для создания ресурсов, здесь могут быть описаны любые команды, например, здесь обычно запускают сервис и добавляют его в автозагрузку. Файлы в libraries также имеют расширение rb и являются привычными для программистов библиотеками Ruby, которые доступны из Recipes, Attribute и Definitions. Это очень удобно, так как можно собрать все часто используемые параметры в одном месте. Хотя во многих Cookbooks этот каталог пустует или вообще отсутствует. Каталог files полностью соответствует названию, в нем находятся файлы, которые копируются без изменений.

Установка Chef

Установка Chef производится в две стадии – собственно установка приложения и зависимостей и обеспечение загрузки/работы (bootstrap). Этап bootstrap будет отличаться для сервера и клиентов. Причем если Cookbooks расписан в документации достаточно основательно, то процесс установки и bootstrap я бы сказал очень поверхностно. Человеку не знакомому с Ruby придется немного поискать наиболее удобный для себя вариант. Кроме этого как я говорил ранее, проект очень быстро развивается, и в новых версиях появляются тонкости, которые не описаны ни где. В репозитариях некоторых дистрибутивов Chef уже доступен, но как правило версия далека до актуальной. Для CentOS 5.5 следует подключить репозитарий ELFF. Так в Ubuntu 10.4 пока лишь:

$ sudo aptitude show chef
Версия: 0.7.10-0ubuntu1.1

Разработчики Chef предлагают свой репозитарий, который можно подключить прописав в /etc/apt/source.list:

deb http://apt.opscode.com/ lucid main universe

Обновляют его не часто, но на момент написания статьи как раз и произошло обновление версии пакета. Пакет отсюда, через некоторое время появляется в репозитарии Ubuntu. Далее как обычно:

$ sudo aptitude update
$ sudo aptitude show chef

Если установка производится на сервер, то:

$ sudo aptitude install rubygems ohai chef chef-server chef-server-webui

В этом случае будут установлены все зависимости, созданы все необходимые файлы настроек и запуска при загрузке ОС. Запускается CouchDB и Stompserver (порт 61613). Стартует chef-server в настройках по умолчанию (порт 4000 и 4001), веб-интерфейс (4040), а также демоны chef-solr и клиент.

Установка на клиенте:

$ sudo aptitude install rubygems ohai chef

В документации особо подчеркнуто, что следует использовать именно aptitude который по умолчанию устанавливает мягкие зависимости.
Но версия как видите, запаздывает и мы не получим возможности доступные в актуальном релизе. Поэтому для подготовленного администратора наиболее правильной будет самостоятельная сборка и bootstrap. Минимальное требование к установке Chef — Ruby и Rubygems. В Ubuntu их можно установить из репозитария:

$ sudo aptitude install ruby ruby1.8-dev libopenssl-ruby1.8 rdoc ri irb build-essential wget ssl-cert libxml-ruby libxml2-dev libxslt-dev

В документации предлагают устанавливать Rubygems при помощи исходных текстов, в случае с Ubuntu 10.4 можно использовать доступную в репозитарии. Если же версия Rubygems сильно запаздывает, либо разработчики Chef акцентируют внимание на ее версии, устанавливаем из исходных текстов.

Также нам понадобится CouchDB и stompserver.

$ sudo aptitude install rubygems1.9.1 couchdb stompserver

Создадим локальные копии Git репозитариев Chef и Cookbooks, в последующем мы будем использовать некоторые файлы:

$ git clone http://github.com/opscode/chef.git
$ git clone http://github.com/opscode/cookbooks.git

Нужно проследить, чтобы для RubyGems был установлен параметр «EXECUTABLE DIRECTORY»:

$ gem env
RubyGems Environment:
  - INSTALLATION DIRECTORY: /var/lib/gems/1.8
  - RUBY EXECUTABLE: /usr/bin/ruby1.8
  - EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin
  - GEM PATHS:
     - /var/lib/gems/1.8
     - /home/grinder/.gem/ruby/1.8
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - :sources => ["http://gems.rubyforge.org/", " http://gems.rubyforge.org/"]
  - REMOTE SOURCES:
     - http://gems.rubyforge.org/
     - http://gems.rubyforge.org/

Теперь можно собрать Chef при помощи rake (нужен одноименный пакет) или лучше установить используя gem. Но Chef находится в http://rubygems.org/, поэтому меняем источник:

$ sudo gem sources -r http://gems.rubyforge.org/
http://gems.rubyforge.org/ removed from sources
$ sudo gem sources -a http://rubygems.org/
http://rubygems.org/ added to sources

Устанавливаем Chef и компоненты:

$ sudo gem install ohai chef json –no-ri –no-rdoc
Successfully installed chef-0.9.4

Вот и вся установка, теперь очередь bootstrap.
В своей работе различные составляющие Chef используют конфигурационные файлы.

• /etc/chef/client.rb – клиент Chef;
• /etc/chef/solo.rb (~/solo.rb) –при запуске в режиме chef-solo;
• /etc/chef/server.rb – сервер;
• /etc/chef/webui.rb — веб-панель настроек
• /etc/chef/solr.rb – сервис работы с индексами.

В Git репозитарии доступен готовый шаблон, который копируем в /etc/chef.

$ cd ~/chef
$ sudo cp –v  chef/config/server.rb /etc/chef/

Почему-то из репозитария Chef исчезли шаблоны для client.rb или solo.rb и json, в принципе эти файлы просты. В качестве примера можно использовать шаблоны из Git Cookbooks (~/cookbooks/chef/templates/default). Сам Chef будет установлен в /var/lib/gems/1.8/gems/chef-0.9.4, в подкаталоге bin находятся исполняемые файлы (скрипты Ruby). Загрузочные init.d скрипты для Debian и RehHat /var/lib/gems/1.8/gems/chef-0.9.4/distro. Копируем их на свое место:

$ sudo cp -v /var/lib/gems/1.8/gems/chef-0.9.4/distro/debian/etc/init/* /etc/init/
$ sudo cp -v /var/lib/gems/1.8/gems/chef-0.9.4/distro/debian/etc/init.d/* /etc/init.d/

Но они требуют правки, так как например путь к исполняемому файлу внутри указан как /usr/bin. Конфигурируем сервер и веб-интерфейс:

$ cd /var/lib/gems/1.8/gems/chef-0.9.4/bin/
$ sudo knife configure –i

Скрипт задаст ряд вопросов
При запуске сервера Chef создается сертификат /etc/chef/validation.pem, который следует скопировать на все клиенты, чтобы они смогли подключиться к серверу и получить свой сертификат /etc/chef/client.pem.

Chef в режиме Solo

Для примера запустим Chef в режиме solo, как самый простой вариант, удобный для тех кому часто приходится разворачивать однотипные конфигурации. Cоздадим файл ~/solo.rb такого содержания:

$ nano ~/solo.rb
cookbook_path     "/etc/chef/recipes/cookbooks" 
log_level         :info
file_store_path  "/etc/chef/recipes/" 
file_cache_path  "/etc/chef/recipes/"

Параметры внутри должны быть понятны. Создаем каталоги:

$ sudo mkdir –p /etc/chef/recipes/cookbooks

Теперь файл для JSON:

$ nano ~/chef.json
{
  "bootstrap": {
    "chef": {
      "url_type": "http",
      "init_style": "runit",
      "path": "/srv/chef",
      "serve_path": "/srv/chef",
      "server_fqdn": "localhost"
    }
  },
  "recipes": "bootstrap::server"
}

Пробуем запустить.

$ cd /var/lib/gems/1.8/gems/chef-0.9.4/bin/
$ sudo ./chef-solo -l debug -c ~/solo.rb -j ~/chef.json

И проверяем сообщения об ошибках. Если все нормально, копируем в /etc/chef/recipes/cookbooks и запускаем. Теперь можно переходить к клиент-серверной конфигурации, если в таковой есть необходимость.