The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Централизованная настройка с помощью Puppet (puppet config)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: puppet, config,  (найти похожие документы)
Автор: Сергей Яремчук <[email protected]> Date: Mon, 9 Jan 2010 17:02:14 +0000 (UTC) Subject: Централизованная настройка с помощью Puppet Оригинал: http://www.tux.in.ua/articles/353 Статья напечатана в журнале Системный Администратор Управление большим количеством Unix систем нельзя назвать удобным. Для изменения одного параметра администратору приходится обращаться к каждой машине, скрипты лишь частично могут помочь, да и не во всех ситуациях. Следует признать, что администраторы Windows сетей находятся все-таки в более выгодном положении. Достаточно изменить настройки групповых политик и через некоторое время все компьютеры сети, в том числе и с недавно установленной операционной системой "узнают" о нововведении, если они их конечно касаются. Оглянувшись на долгий период развития Unix, можно заметить, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но дальнейшая доводка потребует значительных усилий. Коммерческие решения вроде BladeLogic http://www.bladelogic.com/ и OpsWare http://www.opsware.com/, проблему автоматизации настроек решают лишь отчасти, основное их достоинство наличие графического интерфейса, да и позволить их приобрести могут только в крупных организациях. Есть конечно и проекты предлагающие свободные решения, но за все время своего существования они так и не смогли создать большого сообщества. Например Cfengine http://www.cfengine.org/ не очень пользуется популярностью у администраторов, хотя кроме Linux, может использоваться в *BSD, Windows и Mac OS X. Возможно это связано с относительной сложностью в создании конфигураций. При описании заданий приходится учитывать особенности каждой конкретной системы, и вручную контролировать последовательность действий при выполнении команд. То есть администратор должен помнить, что для одних систем следует писать adduser для других useradd, учитывать расположение файлов в разных системах, и так далее. Это на порядок усложняет процесс написания команд, с ходу создать правильную конфигурацию очень сложно, а созданные конфигурации прочитать через некоторое время практически не реально. Не смотря на GPL лицензию Cfengine фактически проект одного человека, который контролирует все изменения и не очень заинтересован в построении открытого общества. В результате возможности cfengine вполне удовлетворяют разработчика, а для остальных администраторов это скорее лишняя головная боль. Чтобы улучшить cfengine сторонними разработчиками были созданы различные дополнения, что часто только ухудшало ситуацию. Автор нескольких таких модулей к cfengine Люке Каниес (Luke Kanies) в итоге решил разработать подобный инструмент, но лишенный многих недостатков cfengine. Возможности Puppet Puppet (http://reductivelabs.com/projects/puppet/) как и cfengine является клиент-серверной системой использующей декларативный, то есть обязательный для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически (по умолчанию 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию. Если полученные настройки не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о произведенных операциях. Сервер сообщения может сохранить в syslog или файл, создать RRD график, отослать на указанный e-mail. Дополнительные уровни абстракции Transactional и Resource обепечивают максимальную совместимость с существующими настройками и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд и форматах файлов. Администратор оперирует лишь с типом объекта, остальное Puppet берет на себя. Так тип packages знает о 17 пакетных системах, нужная автоматически будет распознана на основании информации о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно. В отличие от скриптов, которые часто не возможно использовать в других системах, конфигурации Puppet написанные сторонними администраторами будут в большинстве без проблем работать в любой другой сети. В Puppet [[http://www.reductivelabs.com/trac/puppet/tags/puppet%2CrecipeCookBook]] уже имеется три десятка готовых рецептов. В настоящее время Puppet официально поддерживает следующие операционные системы и сервисы: Debian, RedHat/Fedora, Solaris, SUSE, CentOS, Mac OS X, OpenBSD, Gentoo и MySQL, LDAP. Язык Puppet Чтобы идти дальше, вначале следует разобраться с основными элементами и возможностями языка. Язык это одна из сильных сторон Puppet. С его помощью описываются ресурсы которыми администратор планирует управлять и действия. В отличие от большинства подобных решений, в Puppet язык позволяет упростить обращение ко всем схожим ресурсам на любой системе в гетерогенной среде. Описание ресурса, как правило, состоит из названия, типа и атрибутов. Например укажем на файл /etc/passwd и установим его атрибуты: file { "/etc/passwd": owner => root, group => root, mode => 644, } Теперь клиенты, подключившись к серверу скопируют файл /etc/passwd и установят указанные аттрибуты. В одном правиле можно определять сразу несколько ресурсов, разделяя их с помощью точки с запятой. А что делать если конфигурационный файл используемый на сервере отличается от клиентских или вообще не используется? Например такая ситуация может возникнуть при настройках VPN соединений. В этом случае следует на файл можно указать директивой source. Здесь два варианта, как обычно указать путь к другому файлу, также поддерживается два URI протокола: file и puppet. В первом случае используется ссылка на внешний NFS сервер, во втором варианте на сервере Puppet, запускается NFS подобный сервис, который и экспортирует ресурсы. В последнем случае по умолчанию путь указывается относительно корневого каталога puppet - /etc/puppet. То есть ссылка puppet://server.domain.com/config/sshd_config будет соответствовать файлу /etc/puppet/config/sshd_config. Переопределить этот каталог, можно с помощью директивы filebucket, хотя более правильно использовать одноименную секцию в файле /etc/puppet/fileserver.conf. В этом случае можно ограничить доступ к сервису только с определенных адресов. Например опишем секцию config. [config] path /var/puppet/config allow *.domain.com allow 127.0.0.1 allow 192.168.0.* allow 192.168.1.0/24 deny *.wireless.domain.com А затем обращаемся к этой секции при описании ресурса. source => "puppet://server.domain.com/config/sshd_config" Перед двоеточием располагается название ресурса. В самых простых случаях в качестве имени можно просто указатьлучше использовать псевдоним или переменные. Псевдоним устанавливается с помощью директивы alias. полный путь к файлу. В более сложных конфигурациях file { "/etc/passwd": alias => passwd } Другой вариант создания псевдонима, хорошо подходит в том случае, когда приходится иметь дело с разными операционными системами. Например, создадим ресурс описывающий файл sshd_config: file { sshdconfig: name => $operatingsystem ? { solaris => "/usr/local/etc/ssh/sshd_config", default => "/etc/ssh/sshd_config" } В этом примере мы столкнулись с возможностью выбора. Отдельно указан файл для Solaris, для всех остальных будет выбран файл /etc/ssh/sshd_config. Теперь к этому ресурсу можно обращаться как к sshdconfig, в зависимости от операционной системы будет выбран нужный путь. Например укажем, что в случае если демон sshd запущен и получен новый файл, следует перезапустить сервис. service { sshd: ensure => true, subscribe => File[sshdconfig] } Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашнних каталогов пользователей: $homeroot = "/home" Теперь к файлам конкретного пользователя можно обратиться как ${homeroot}/$name В параметр $name будет подставлено учетное имя пользователя. В некоторых случаях удобно определить значение по умолчанию для некоторого типа. Например для типа exec очень часто указывают каталоги в которых он должен искать исполняемый файл: Exec { path => "/usr/bin:/bin:/usr/sbin:/sbin" } В том случе если нужно указать на несколько вложенных файлов и каталогов, можно использовать параметр recurse. file { "/etc/apache2/conf.d": source => "puppet:// puppet://server.domain.com/config/apache/conf.d", recurse => "true" } Несколько ресурсов могут быть объеденены в классы или определения. Классы являются законченным описанием системы или сервиса и используются обособленно. class linux { file { "/etc/passwd": owner => root, group => root, mode => 644; "/etc/shadow": owner => root, group => root, mode => 440 } } Как и в объектно-ориентированных языках классы могут переопределяться. Например в FreeBSD группой-владельцем этих файлов является wheel. Поэтому чтобы не переписывать ресурс полностью, создадим новый класс freebsd, который будет наследовать класс linux: class freebsd inherits linux { File["/etc/passwd"] { group => wheel }; File["/etc/shadow"] { group => wheel } } Для удобства все классы можно вынести в отдельный файл, который подключать директивой include. Определения могут принимать многочисленные параметры в качестве аргументов, но не поддерживают наследования и используются в том случае если нужно описать многократно используемые объекты. Например определим домашний каталог пользователей и команды необходимые для создания новой учетной записи. define user_homedir ($group, $fullname, $ingroups) { user { "$name": ensure => present, comment => "$fullname", gid => "$group", groups => $ingroups, membership => minimum, shell => "/bin/bash", home => "/home/$name", require => Group[$group], } exec { "$name homedir": command => "/bin/cp -R /etc/skel /home/$name; /bin/chown -R $name:$group /home/$name", creates => "/home/$name", require => User[$name], } } Теперь чтобы создать новую учетную запись достаточно обратиться к user_homedir. user_homedir { "sergej": group => "sergej", fullname => "Sergej Jaremchuk", ingroups => ["media", " admin] } Отдельно стоят описания узлов (node), которые поддерживают наследование как и классы. При подключении клиента к серверу Puppet будет произведен поиск соотетсвующей секции node и выданы специфические только для этого компьютера настройки. Для описания всех остальных систем можно использовать node default. Описание всех типов приведено в документе "Type Reference" с которым необходимо ознакомиться в любой случае, хотя бы, для того чтобы понять все возможности языка Puppet. Различные типы позволяют выполнять указанные команды, в том числе и при выполнении определенных условий (например изменение конфигурационного файла), работать с cron, учетными данными и группами пользователей, компьютерами, монтированием ресурсов, запуском и остановкой сервисов, установкой, обновлением и удалением пакетов, работой с SSH ключами, зонами Solaris и так далее. Вот так просто можно заставить обновлять список пакетов в дистрибутивах использующих apt, ежедневно между 2 и 4 часами. schedule { daily: period => daily, range => [2, 4] } exec { "/usr/bin/apt-get update": schedule => daily } Обновление за тот период каждой системой будет выполнено только один раз, после чего задание считается выполненным и будет удалено с клиентского компьютера. Язык Puppet поддерживает другие привычные структуры: условия, функции, массивы, комментарии и подобные. Установка Puppet Для работы Puppet потребуются Ruby (>= 1.8.1) с поддержкой OpenSSL и библиотеками XMLRPC, а также библиотека Faster http://reductivelabs.com/projects/facter . В репозитарии Ubuntu 7.04, который использовался при тестовой установке, уже включен пакет puppy. $ sudo apt-cache search puppet puppet - centralised configuration management for networks puppetmaster - centralised configuration manangement control daemon При инсталляции будут установлены все необходимые зависимости пакеты: facter libopenssl-ruby libxmlrpc-ruby. $ sudo apt-get install puppet puppetmaster Проверить наличие библиотек Ruby можно командой. $ ruby -ropenssl -e "puts :yep" yep ~$ ruby -rxmlrpc/client -e "puts :yep" yep Если не получено ошибок, значит все необходимое уже включено. Файлы в которых описывается желательная конфигурация систем в терминологии Puppet называются манифестами (manifests). При запуске демон пытается прочитать файл /etc/puppet/manifests/site.pp, при его отсутствии выдает предупреждающее сообщение. При тестировании можно указать демону на работу в автоновном режиме при котором манифест не требуется $ sudo /usr/bin/puppetmasterd -nonodes При необходимости к site.pp можно подключать другие файлы, например с описаниями классов. Для тестового запуска в этот файл можно занести самую простую инструкцию. class sudo { file { "/etc/sudoers": owner => root, group => root, mode => 440, } } node default { include sudo } Все конфигурационный файлы как сервера так и клиентов расположены в /etc/puppet. Файл fileserver.conf о котором мы говорили выше, не обязателен и используется только в том случае когда Puppet будет работать еще и как файл-сервер. В Ubuntu в этом файле экспортируется подкаталог /etc/puppet/files. В подкаталоге ssl расположены сертификаты и ключи, которые будут использоваться для шифрования при подключениях клиентов. Ключи создаются автоматически при первом запуске puppetmasterd, вручную их создать можно командой. $ sudo /usr/bin/puppetmasterd -mkusers. Файлы puppetd.conf и puppetmasterd.conf похожи. В них указываются некоторые параметры работы демонов на клиенской системе и сервере. Клиенский файл отличается только наличием параметра server, указывающего на компьютер на котором запущен puppetmasterd. [puppetd] server = grinder.com logdir = /var/log/puppet vardir = /var/lib/puppet rundir = /var/run # отсылаем отчет серверу report = true Чтобы не печатать все вручную, можно создать шаблон с помощью самого puppetd. $ puppetd --genconfig > /etc/puppet/puppetd.conf Аналогично можно создать и site.pp на сервере. $ puppetd --genmanifest > /etc/puppet/manifests/site.pp Еще один файл tagmail.conf, позволяет указать почтовые адреса на которые будут отсылаться отчеты. В простейшем случае можно использовать одну строку. all: [email protected] Конфигурационных файлов недостаточно, чтобы клиент мог подключаться к серверу. Для этого необходимо еще подписать сертификаты. Сначала чтобы сервер узнал о новом компьютере на клиентской системе вводим команду: $ sudo puppetd -server grinder.com -waitforcert 60 -test info: Requesting certificate warning: peer certificate won't be verified in this SSL session notice: Did not receive certificate Если будет выдана другая строка, следует проверить работу сервера. $ ps aux | grep puppet puppet 5779 0.0 1.4 27764 15404 ? Ssl 21:49 0:00 ruby /usr/sbin/puppetmasterd Межсетевой экран должен разрешать соединения на порт 8140. На сервере получаем список сертификатов нуждающихся в подписи. $ sudo puppetca -list nomad.grinder.com И подписываем сертификат клиента. $ sudo puppetca -sign nomad.grinder.com Теперь клиент может свободно подключаться к серверу и получать настройки. К сожалению все возможности Puppet в пределах статьи показать просто не возможно. Но как видите это функциональный и гибкий инструмент, позволяющий решить большую часть задач по одновременному администрированию большого числа систем. Если вам по роду работы приходится настраивать несколько систем. И самое главное проекту удалось собрать пока небольшое, но постоянно растущее сообщество. Поэтому будем надеяться, что хорошей идее не дадут умереть или уйти в сторону.

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру