configuration management

В конце прошлого года проводил осмотр решений для configuration management для одной конторы. С конторой не срослось, но из любопытства всё равно прошёлся по базару — посмотрел чего дают. Чтобы не пропадало — пишу в бложик.

Configuration management это, упрощённо говоря, нагиосовсие чеки + рецептики исполнителю как сделать, чтобы оно вот так стало. То есть не просто "на 80 порту должен быть апач", но и "для этого надо из репозитария поставить вот такой пакет, положить ему вот такой конфиг и запустить вот это вот". В результате имеем возможность на свежий хост накатить этого вот исполнителя, сказать ему какие рецепты его — и оно там всё перечисленное установит-настроит-скомпилирует и в конфиги пропишет. Экономия на времени установки, плюс возможность сложить описание машины в какую-нибудь систему контроля версий для исторических раскопок.

Рассматривал 4 варианта (вообще их больше, конечно): cfengine, chef, Puppet и salt. Проверочное задание назначил себе несложное: поставить апач, написать ему в index.html что-нибудь по шаблону с использованием переменных (например, первый ip-адрес с eth0 или название операционки).

cfengine

Сайт: http://cfengine.com/

Самый старый из вариантов — официальная история начинается ажна в 1993 году. Как ни странно, стабильности пока нету: в дистрибутиве есть ветки cfengine2 и cfengine3, и между версиями 3.2.4 и 3.3.0 запросто появляется новый формат шаблонов. Написан на православном C, сборка-установка традиционная (configure/make/make install). Рецепты называются "обещаниями" (promises). Язык обещаний странный, но видали мы и постраннее.

Ставим апача:

body common control {
  bundlesequence  => { "test004" };
  inputs => { "cfengine_stdlib.cf" };
}
bundle agent test004
{
 packages:
  ubuntu::
   "apache2"
             package_policy => "addupdate",
             package_method => apt,
             package_select => ">=",
            package_version => "2.2",
      package_architectures => { "*" };
}

Пишем файл по шаблону:

body common control
{
bundlesequence  => { "templating" };
inputs => { "cfengine_stdlib.cf" };
}

bundle agent templating
{
files:
  "/var/www/index.html"
       create => "true",
       edit_line => expand_template("/tmp/source_template"),
       edit_defaults => empty;
}

Собственно шаблон "/tmp/source_template":

<h1>Blah!</h2>
$(sys.ipv4[eth0])

Итого: за вычетом странного языка впечатление приятное — обещание можно отдельно проверить, отдельно исполнить, распространять можно любым удобным способом (есть и "официальный", разумеется — с ролями, группами машин и прочими прибамбасами). Всё маленькое-аккуратное и в голове укладывающееся.

chef

Сайт: http://www.opscode.com/chef/

К Шефу это уже второй мой подход. Первый, около полутора лет назад, закончился очень быстро: для управления одним сервером chef явно перебор, а процедура сборки была такая, что проходить её до конца не пожелал даже я. Теперь похорошело: есть репозитарии собранных пакетов для популярных вариантов. Качество сборки, впрочем не того... с первой попытки у меня не взлетело: один файлик попал сразу в два пакета. Пришлось пошурудить с dpkg --force-overwrite

Первое что про про chef надо сказать — он, ребята, большой. По сравнению со всеми конкурентами он прямо-таки огромный. Даже с no-recommends он цепляет за собой 526Мб пакетов, которые прямо поражают разнообразием: тут и java, и ruby, и qt, и gtk, и apache, и jetty, и erlang, и couchdb. Набор несколько пугающий. Причём если что-то ещё можно списать на сборщиков пакетов, которые по неопытности или по лени собрали с максимальным набором опций — то Ruby, Erlang и Java реально используются компонентами chef-а. Такие нынче компоненты пошли, да. У каждого свой язык, своя VM и своя пакетная инфраструктура. Я с трудом представляю человека, квалификации которого достаточно чтобы починить весь этот зверинец, если, не дай бог, чего сломается. Недаром разработчики первым делом предлагают hosted chef за скромные $120/mo. Это "Launch"-ценник, за Standard просят уже $300/mo.

Идём дальше. Например, у него есть не только понятие "сервера" (chef server, где лежит конфигурация всего хозяйства) и "узла" (node, chef client — управляемая машина), но ещё и "workstation" — это место где рецепты пишутся. Как-то остальные были довольны обычным текстовым редактором. Ну да бог с ним, может быть оно как-то окупается удобством работы — не знаю. В общем, нужна машина с knife.

При попытке сделать клиенту bootstrap (так у них называется установка исполняющего рецепты агента) случился следующий конфуз: оно туда идёт по ssh и пытается, реально, ставить gem-ы для Ruby. То есть мало того что нужен ruby конкретной версии (в дистрибутивах сейчас две: 1.8 и 1.9), но и компилятор с заголовками-библиотеками из dev-пакетов. На этом месте ортодоксальные администраторы уже говорят "не-е, это не для продакшена".

Рецепты собираются в кулинарные книги (cookbooks) — это хитроназванные git-репозитарии особой структуры. Пишется всё на Ruby:

package "ntp" do
    action [:install]
end

template "/etc/ntp.conf" do
    source "ntp.conf.erb"
    variables( :ntp_server => "time.nist.gov" )
    notifies :restart, "service[ntpd]"
end

service "ntpd" do
    action [:enable,:start]
end

Шаблоны — обычный erb:

# generated by Chef.
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server <%= @ntp_server %>
server  127.127.1.0     # local clock
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys

Потом эту кулинарную книгу надо ножом загрузить в шеф-повара (вот не шучу, так у них всё и называется). Потом добавить его в run list для клиента, и на следующем запуске он его таки исполнит.

Итого: Чего-то наворотили. За язык рецептов/шаблонов — зачёт, по моему мнению вместо изобретения своего надо брать какой-то общечеловеческий. Всё остальное... Ох, ну оно работает, конечно. И даже кому-то нравится. Но не мне. Слишком развесисто, слишком over-engineered. По совокупности — не рекомендую.

Puppet

Сайт: http://puppetlabs.com/

Популярный (в списке пользователей имеются гранды вроде Google, Zynga и Twitter). В дистрибутивах есть рабочие пакеты. С сайта можно скачать готовые тренировочные vm-ки "на посмотреть". Документация на офсайте вполне читаемого качества. Есть и бумажные книги (разумеется, несколько устаревшие). Написан на Ruby, но без особого хипстерства.

Рецепты называеются "манифестами", пишутся на своём декларативном языке:

package {'apache':
  ensure => latest,
  name => 'apache2',
}

service {'apache':
  ensure => running,
  name => 'apache2',
}

file {'/var/www/index.html':
  ensure  => present,
  content => template('/root/test-index.html'),
}

Язык шаблонов — снова erb:

<h1><%= @operatingsystem %></h1>

Итого: Ну, всё хорошо про него. Из минусов — всё-таки ruby (имеются завязки на версии). Наверняка дальше там есть какие-то камни, но по внешнему виду — явный лидер.

salt

Сайт: http://saltstack.org/

Ещё один молодец тестирования, про которого ничего сильно интересного и не рассказать: скачал, запустил, работает. Документация, кстати, прямая как стрела: можно подумать, что они знают, чем я его буду проверять. Написано на Python, проект относительно молодой (since 2011).

Рецепты называются "state tree", язык внутри — yaml. Заказываем пакетик с апачем:

apache2:                # ID declaration
  pkg:                  # state declaration
    - installed         # function declaration

  service:
    - running
    - require:
      - pkg: apache2

/var/www/index.html:
  file:
    - managed
    - source: salt://apache/index.html
    - template: jinja
    - context:
      custom_var: "override"

Шаблоны файлов пишутся на "jinja, mako, and wempy". Первый, кажется, популярный:

Blah, blah
{{ custom_var }}
{{ grains['fqdn'] }}
{{ salt['network.ip_addrs']('eth0')[0] }}

Итого: Хорошо. Только что молодость, но этот недостаток проходит.

Общий итог

Понятное дело, я только по верхушкам пробежался — но надо итог какой-то писать. Кто самый-самый, кого брать-то? А нету самого-самого, каждому своё. Как с системами контроля версий: кто-то нахваливает git, кто-то svn, кто-то bzr. Но что бы вы не выбрали — это лучше, чем не использовать ничего.

Кстати, необязательно брать из списка. Может быть, вам надо управлять машинами на Windows. Или вы обязательно хотите, чтобы на управляемую машину не ставить ничего, кроме ssh. Или чтобы скрипты были непременно на lua. Реально, выбор широк: очень может быть, что для вас ansible или bcfg2 окажутся тем, "что доктор прописал".

Если никак не можете определиться — начните с Puppet. Он популярный и лёгкий на подъём. Если с ним будут проблемы, то могу биться об заклад что вы будете не первыми с этой проблемой — и гугль поможет с решениями.