Статья из журнала Системный Администратор
В эпоху виртуальных машин на первый план выходит быстрота развертывания и гибкость управления большим количеством систем. 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 и запускаем. Теперь можно переходить к клиент-серверной конфигурации, если в таковой есть необходимость.
//
Chef с указанными задачами справиться очень просто. —>> ТСЯ
//
Статья очень сырая, да еще и много ошибок.
shef-solo, shef-client — нет таких утилит, есть «shef» — что-то похожее на «ruby-irb» для отлаживания, «chef-solo», «chef-client» — это есть
«Для аутентификации с сервером используется OpenID.» — это неверно, сертификаты используются. OpenID — только для веб-морды, и то, если это нужно
«какой либо технологии отслеживания зависимостей в Chef пока нет.» — есть
not_if
only_if
notifies
текущая версия Chef — 0.10.4, в статье — непонятно (то ли 0.7, то ли 0.9.4)
//
Статье как минимум уже год.