Master of puppets: Установка и настройка системы удаленного управления конфигурацией Puppet. Устанавливаем puppet и создаем свой первый манифест

Для более эффективного использования Puppet нужно понимать, как строятся модули и манифесты. Данное руководство ознакомит вас с работой этих компонентов Puppet на примере настройки стека LAMP на сервере Ubuntu 14.04.

Требования

  • Установка Puppet (мастер и агент). Больше об этом – .
  • Возможность создать хотя бы один виртуальный сервер Ubuntu 14.04 для обслуживания агентской ноды Puppet.

Основы кода Puppet

Ресурсы

Код Puppet в основном состоит из ресурсов. Ресурс – это фрагмент кода, который описывает состояние системы и определяет необходимые ей изменения. Например:

user { "mitchell":
ensure => present,
uid => "1000",
gid => "1000",
shell => "/bin/bash",
home => "/home/mitchell"
}

Объявление ресурса имеет такой формат:

resource_type { "resource_name"
attribute => value
...
}

Чтобы просмотреть все типы ресурсов Puppet, введите команду:

puppet resource --types

Больше о типах ресурсов вы узнаете в этом руководстве.

Манифесты

Манифест – это сценарий оркестровки. Программы Puppet с расширением.pp называются манифестами. Манифест Puppet по умолчанию – /etc/puppet/manifests/site.pp.

Классы

Как и в любом обычном языке программирования, классы отвечают за организацию и повторное использование частей оркестровки.

В определении класса находится блок кода, который описывает, как работает класс. Определив класс, вы можете использовать его в манифестах.

Определение класса имеет такой формат:

class example_class {
...
code
...
}

Этот код определяет класс example_class. Код Puppet будет находиться в фигурных скобках.

Объявление класса – это то место в коде, где вызывается тот или иной класс. С помощью объявления класса Puppet обрабатывает его код.

Объявление класса бывает обычным и по типу ресурса.

Обычное объявление класса добавляется в код с помощью ключевого слова include.

include example_class

При объявлении по типу ресурса класс объявляется в формате ресурса:

class { "example_class": }

Такое объявление позволяет добавлять в код параметры класса, которые переопределяют стандартные значения атрибутов класса. Например:

node "host2" {
class { "apache": } # use apache module
apache::vhost { "example.com": # define vhost resource
port => "80",
docroot => "/var/www/html"
}
}

Модули

Модуль – это группа манифестов и других файлов, организованная заранее определенным образом, которая позволяет облегчить совместное и повторное использование отдельных частей оркестровки. Модули помогают систематизировать код Puppet, поскольку с их помощью код можно разделить на несколько манифестов.

Модули Puppet хранятся в каталоге /etc/puppet/modules.

Написание манифеста

Потренироваться писать манифесты, модули и классы Puppet можно на примере установки стека LAMP на сервер Ubuntu (в результате получится ).

Итак, чтобы выполнить оркестровку сервера Ubuntu 14.04 и установить на него стек LAMP, нужны ресурсы для таких действий:

  • установка пакета apache2.
  • запуск сервиса apache2.
  • установка пакета сервера MySQL, mysql-server.
  • запуск сервиса mysql.
  • установка пакета php5
  • создание тестового сценария PHP, info.php.
  • обновление индекса apt перед установкой каждого пакета.

Ниже вы найдете три примера кода Puppet, с помощью которого можно получить такую установку стека LAMP.

Первый пример научит писать базовые манифесты в одном файле. Второй пример поможет собрать и использовать класс и модуль на основе ранее написанных манифестов. В третьем примере вы узнаете, как пользоваться предварительно собранными общедоступными модулями для установки стека LAMP.

Примечание : Для тестирования лучше использовать свежий виртуальный сервер.

Пример 1: Установка LAMP с помощью одного манифеста

Манифест Puppet можно написать на агентской ноде, а затем выполнить его с помощью команды puppet apply (для этого не нужно иметь установку из мастера и агента).

В данном разделе вы научитесь писать манифесты, которые будут использовать такие типы объявления ресурсов:

  • exec: выполнение команд.
  • package: установка пакетов.
  • service: управление сервисами.
  • file: управление файлами.

Создание манифеста

Создайте новый манифест:

sudo vi /etc/puppet/manifests/lamp.pp

Добавьте в него следующий код, чтобы объявить необходимые ресурсы.

# запуск команды "apt-get update"
exec { "apt-update": # ресурс exec "apt-update"
command => "/usr/bin/apt-get update" # команда, которую запустит этот ресурс
}
# установка пакета apache2
package { "apache2":
require => Exec["apt-update"], # запрос "apt-update" перед установкой пакета
ensure => installed,
}
# запуск сервиса apache2
service { "apache2":
ensure => running,
}
# установка mysql-server
package { "mysql-server":
require => Exec["apt-update"], # запрос "apt-update" передустановкой
ensure => installed,
}
# запуск сервиса mysql
service { "mysql":
ensure => running,
}
# установка пакета php5
package { "php5":
require => Exec["apt-update"], # запрос "apt-update" перед установкой
ensure => installed,
}
# запуск сервиса info.php
file { "/var/www/html/info.php":
ensure => file,
content => "", # код phpinfo
require => Package["apache2"], # запрос пакета "apache2"
}

Применение манифеста

Чтобы использовать новый манифест, введите команду:

sudo puppet apply --test

Она выведет объёмный результат, который отображает все изменения состояния среды. Если в выводе нет ошибок, вы сможете открыть свой внешний IP-адрес или доменное имя в браузере. На экране появится тестовая страница PHP с информацией о стеке. Это значит, что Apache и PHP работают.

Теперь стек LAMP установлен на сервер с помощью Puppet.

Это довольно простой манифест, поскольку его можно выполнить на агенте. Если у вас нет мастера Puppet, другие агентские ноды не смогут использовать этот манифест.

Мастер-сервер Puppet проверяет изменения состояния сервера каждые 30 минут.

Пример 2: Установка стека LAMP с помощью модуля

Теперь попробуйте создать простой модуль, основанный на манифесте LAMP, который вы написали в предыдущем разделе.

Чтобы создать модуль, создайте в каталоге modules новый каталог (его имя должно совпадать с именем модуля). В этом каталоге должны находиться каталог manifests и файл init.pp. В файле init.pp указывается класс Puppet (его имятакже должно совпадать с именем модуля).

Создание модуля

Перейдите на мастер-сервер Puppet и создайте структуру каталогов для модуля:

cd /etc/puppet/modules
sudo mkdir -p lamp/manifests

Создайте и откройте в редакторе файл init.pp:

sudo vi lamp/manifests/init.pp

В файл вставьте класс lamp:

class lamp {
}

Скопируйте содержимое манифеста из раздела 1 и вставьте его в блок класса lamp. Теперь у вас есть определение класса lamp. Другие манифесты смогут использовать этот класс в качестве модуля.

Сохраните и закройте файл.

Использование модуля в главном манифесте

Теперь можно настроить главный манифест и с помощью модуля lamp установить на сервер стек LAMP.

На мастер-сервере Puppet отредактируйте такой файл:

sudo vi /etc/puppet/manifests/site.pp

Скорее всего, на данный момент файл пуст. Добавьте в него следующие строки:

node default { }
node "lamp-1" {
}

Примечание : Вместо lamp-1 укажите имя хоста своего агента Puppet, на который нужно установить стек.

Блок node позволяет указать код Puppet, который будет применяться только к некоторым нодам.

Блок default применяется ко всем агентским нодам, у которых нет индивидуального блока (оставьте его пустым). Блок lamp-1 будет применяться к агентской ноде lamp-1.

Добавьте в этот блок следующую строку, которая использует модуль lamp:

Сохраните и закройте файл.

Теперь агентская нода Puppet сможет загрузить настройки с мастер-сервера и установить стек LAMP. Если вы хотите внести изменения прямо сейчас, запустите на агенте команду:

sudo puppet agent --test

Модули – это самый удобный способ повторного использования кода Puppet. Кроме того, модули помогают логически организовать код.

Пример 3: Установка LAMP с помощью общедоступных модулей

Модуль MySQL используется аналогичным образом. Добавьте в блок ноды такие строки:

class { "mysql::server":
root_password => "password",
}

Также можно передать параметры модуля MySQL.

Добавьте ресурс, который скопирует info.php в нужное место. Используйте параметр source. Добавьте в блок node следующие строки:

file { "info.php": # имя файла ресурса
path => "/var/www/html/info.php", # целевой путь
ensure => file,
require => Class["apache"], # класс apache, который нужно использовать
source => "puppet:///modules/apache/info.php", # место, куда нужно скопировать файл
}

В этом объявлении класса используется параметр source вместо content. Этот параметр не только использует содержимое файла, но и копирует его.

Файл puppet:///modules/apache/info.php Puppet скопирует в /etc/puppet/modules/apache/files/info.php.

Сохраните и закройте файл.

Создайте файл info.php.

sudo sh -c "echo "" > /etc/puppet/modules/apache/files/info.php"

Теперь агентская нода Puppet сможет загрузить настройки с мастер-сервера и установить стек LAMP. Если вы хотите внести изменения в среду агента прямо сейчас, запустите на этой ноде команду:

sudo puppet agent --test

Эта команда загрузит все обновления для текущей ноды и установит на неё стек. Чтобы убедиться, что Apache и PHP работают, откройте IP-адрес или домен ноды в браузере:

http://lamp_1_public_IP/info.php

Заключение

Теперь вы имеете базовые навыки работы с модулями и манифестами Puppet. Попробуйте самостоятельно создать простой манифест и модуль.

Puppet отлично подходит для управления конфигурационными файлами приложений.

Tags: ,

Когда число серверов, которыми вы управляете меньше десяти — редко кто задумывается об их централизованном управлении, этого может и не требоваться. Когда серверов десятки — централизованное управление ПО и конфигурациями крайне полезно. Когда серверов сотни и тысячи — это жизненно необходимо. Программ такого рода много, например: Chef, CFEngine, … Вот о последнем и пойдет речь в этой записи.

Puppet по достоинству считается одним из лучших решений в этом роде. Его используют такие компании как Google, Citrix и Red Hat. Это собой клиент-серверное приложение написанное на языке программирования Ruby, которое распространяется в двух вариантах:

  • Puppet Open Source — полностью бесплатная версия
  • Puppet Enterprise — бесплатная в конфигурации до 10 серверов, далее требуется приобретение лицензий

Рассмотрим установку сервера и агента Puppet Open Source, которые присутствует в пакетах большинства современных дистрибутивов. Далее речь пойдет о Ubuntu 12.04 Precise Pangolin.

Серверная часть Puppet называется puppetmaster , начнем установку с нее:

:~# apt-get install puppetmaster

А теперь клиент:

:~# apt-get install puppet

В конфигурационном файле клиента /etc/puppet/puppet.conf необходимо рассказать о сервере, добавив следующую секцию:

Server=puppet.local report=true pluginsync=false

На первоначальном этапе pluginsync лучше выключить.

Запустим клиент puppet чтобы он создал запрос на получение сертификата:

:~# puppetd --verbose --test info: Creating a new SSL key for linux.local info: Caching certificate for ca info: Creating a new SSL certificate request for linux.local info: Certificate Request fingerprint (md5): E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51 Exiting; no certificate found and waitforcert is disabled

На сервере необходимо проверить что запрос сертификата получен и, если это так, выписываем сертификат:

:~# puppetca --list "linux.local" (E5:EA:AC:5B:22:9A:BA:42:B8:A1:63:9E:1F:1F:23:51) :~# puppetca --sign linux.local notice: Signed certificate request for linux.local notice: Removing file Puppet::SSL::CertificateRequest linux.local at "/var/lib/puppet/ssl/ca/requests/linux.local.pem"

Повторяем предыдущий шаг на клиенте:

:~# puppetd --verbose --test info: Caching certificate for linux.local info: Retrieving plugin info: Caching certificate_revocation_list for ca info: Caching catalog for linux.local info: Applying configuration version "1356278451" info: Creating state file /var/lib/puppet/state/state.yaml notice: Finished catalog run in 0.02 seconds

Отлично, все работает. Переходим к созданию первого манифеста. Манифесты, они же конфигурации описываются на специальном декларативном языке. Будем сразу приучаться к хорошему, использовать модульную структуру и классы. Для примера напишем модуль который будет поддерживать в актуальном виде файл /etc/hosts на всех наших серверах.

Проверим, где puppet ищет модули:

:~# puppet apply --configprint modulepath /etc/puppet/modules:/usr/share/puppet/modules

Создаем каталоги для своего модуля

:~# cd /etc/puppet/modules :~# mkdir hosts; cd hosts; mkdir manifests; cd manifests

Первый манифест, он же основной файл модуля — должен называться init.pp

Class hosts { # puppet.local host { "puppet.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.1", host_aliases => "puppet", } # linux.local host { "linux.local": ensure => "present", target => "/etc/hosts", ip => "192.168.0.2", host_aliases => "linux", } }

По-умолчанию puppet ищет файл /etc/puppet/manifests/site.pp чтобы загрузить конфигурацию, приведем его к следующему виду:

Node default { include hosts }

Проверяем манифест на сервере:

:~# puppet apply --verbose /etc/puppet/manifests/site.pp info: Applying configuration version "1356281036" notice: /Stage//Host/ensure: created info: FileBucket adding {md5}notice: /Stage//Host/ensure: created notice: Finished catalog run in 0.03 seconds

На клиенте:

:~# ll /etc/hosts rw-r--r-- 1 root root 290 Dec 16 19:10 /etc/hosts :~# puppetd --verbose --test info: Caching catalog for linux.local info: Applying configuration version "1356283380" info: FileBucket adding {md5}notice: /Stage/Hosts/Host/ensure: created notice: /Stage/Hosts/Host/ensure: created notice: Finished catalog run in 0.04 seconds :~# ll /etc/hosts -rw-r--r-- 1 root root 551 Dec 23 20:43 /etc/hosts

После того как мы убедились что все работает, разрешаем запуск службы, в /etc/default/puppet меняем:

# Start puppet on boot? START=yes

Запускаем службу

:~# service puppet start

Puppet будет каждые 30 минут опрашивать сервер puppetmaster на предмет изменения конфигурации и, при необходимости, производить соответствующую настройку системы.

Представьте себя в роли системного администратора, ответственного за поддержание работоспособности сотни-другой машин, работающих под управлением операционных систем типа UNIX. Каждая из них требует настройки, периодического обновления и мониторинга, но предполагается, что многие из них выполняют сходные функции. Две трети это - рабочие станции, еще несколько - маршрутизаторы, остальные - несколько web-серверов и хранилищ данных. Вопрос: как всем этим хозяйством управлять?

Самый простой ответ - это просто подключаться к каждой из них с помощью SSH и вносить необходимые изменения. Однако, такой способ имеет две проблемы. Во-первых, он очень трудозатратный. Во-вторых, админу постоянно придется выполнять множество однообразных действий (например, чтобы обновить OpenOffice.org на всех рабочих станциях придется выполнить одни и те же команды несколько десятков раз). Можно попытаться избежать этой проблемы написав несколько скриптов, которые будут сами подключаться к каждой машине и выполнять заранее прописанные команды. Но и здесь нас ожидают проблемы. Скрипты придется постоянно видоизменять, чтобы подстроить их под каждую задачу, в скриптах придется учитывать различие в операционных системах и версиях, их придется долго отлаживать перед тем как применить к работающим машинам. В общем не камильфо.

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

Puppet?

Puppet была разработана Люком Каниесом (Luke Kanies), который устал от ограничений Cfengine и решил создать ее более совершенный аналог с нуля. Если вы уже использовали Cfenfine, то наверняка найдете Puppet более удобной и мощной системой. Язык описания состояний Puppet более высокоуровневый и гибкий, благодаря чему администратору не нужно заботится о таких вещах, как написание отдельных правил для каждого типа ОС или подробное описание выполнения тривиальных действий. Puppet позволяет сосредоточится на том, что он хочет сделать, вместо того как это делать (например, чтобы установить определенный пакет в любую из поддерживаемых системой ОС, достаточно написать буквально несколько строк, говорящих "Установи эту программу", вместо описания команд, необходимых для ее установки). Puppet написан на простом языке Ruby, благодаря чему его достаточно просто подогнать под конкретную задачу и расширить функционал (предусмотрена гибкая система плагинов). Кроме того, в отличие от модели развития Cfengine, которая фактически вращается вокруг одного человека, вокруг Puppet сформировалось большое сообщество энтузиастов, которые вносят доработки в код, делятся примерами конфигурации и пишут документацию.

В целом Puppet производит впечатление более современной и продуманной системы с хорошим дизайном. Как и Cfengine она поддерживает почти все современные UNIX-подобные ОС (в том числе MacOS X), а также может работать в среде Cygwin, поверх Windows. Список ее зависимостей включает только интерпретатор Ruby и инструмент Factor, так что проблем с установкой возникнуть не должно (справедливости ради стоит сказать, что список зависимостей Cfengine и того короче).



Файл-сервер

Многие задачи удаленного администрирования не могут быть решены без копирования на машины дополнительных файлов. Это могут быть заранее подготовленные конфиги, web-страницы для Apache, пакеты, отсутствующие в официальном репозитории и многое другое. Чтобы облегчить процесс переноса этих файлов на удаленные узлы Puppet включает в себя файловый сервер.

Настройки файлового сервера хранятся в файле /etc/puppet/fileserver.conf. Чтобы заставить Puppet отдавать клиентам содержимое определенного каталога, необходимо поместить в него несколько строк:

Path = /var/puppet/files allow *.server.com

Эти две строки указывают на то, что каталог /var/puppet/files должен быть доступен всем хостам домена server.com. Так же мы можем указать полное доменное имя разрешенной машины или ее IP-адрес, а также отрезать неугодных с помощью директивы deny. После этого любой файл этого каталога можно переместить на клиент с помощью ресурса file. Например:

File { "/etc/httpd/conf/httpd.conf": source => "puppet://httpd/httpd.conf", mode => 644, }

Файл httpd.conf, расположенный на сервере в каталоге /var/puppet/files/httpd будет скопирован на целевую машину по пути, указанном в имени ресурса.

Выводы

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

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

World Revolution

Управление множеством Unix систем нельзя называть комфортабельным. Для конфигурации 1-го параметра администратору приходится обращаться к каждой машине, скрипты только частично могут помочь, ну и не во всех ситуациях.

Следует признать, что администраторы Windows сетей находятся все-таки в более успешном положении. Достаточно поменять функции групповых политик и через некоторое время все компютеры сети, в том числе и с не так издавна установленной операционной системой “выяснят” о нововведении, если они их естественно касаются.

Оглянувшись на длиннющий период развития Unix, можно узреть, что ничего подобного так и не прижилось. Есть решения вроде kickstart, которые помогают при первичной установке операционной системы, но грядущая доводка потребует важных усилий.

Коммерческие решения вроде BladeLogic и OpsWare , делему автоматизации опций решают только отчасти, основное их достоинство наличие графического интерфейса, ну и позволить их приобрести могут только в огромных организациях. Есть естественно и проекты предлагающие свободные решения, но за всегда собственного существования они так и не смогли сделать большого общества.

Например Cfengine не очень пользуется популярностью у администраторов, хотя не считая Linux, может употребляться в *BSD, Windows и Mac OS X. Может быть это связано с относительной сложностью в разработке конфигураций. При описании заданий приходится учитывать особенности каждой определенной системы, и вручную контролировать последовательность действий при выполнении команд.

Другими словами администратор должен держать в голове, что для одних систем следует писать adduser для других useradd, учитывать размещение файлов в разных системах, и т.д.. Это на порядок усложняет процесс написания команд, с ходу сделать правильную конфигурацию очень тяжело, а изготовленные конфигурации прочитать через некоторое время практически не реально.

Не смотря на GPL лицензию Cfengine фактически проект 1-го человека, который контролирует все конфигурации и не очень заинтересован в построении открытого общества. В конечном итоге возможности cfengine вполне удовлетворяют разработчика, а для других администраторов это резвее лишняя боль в голове.

Чтобы улучшить cfengine сторонними разработчиками были изготовлены различные дополнения, что часто только ухудшало ситуацию. Создатель нескольких таких модулей к cfengine Люке Каниес (Luke Kanies) в итоге решил сделать похожий инструмент, но лишенный многих недостатков cfengine.

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

Puppet как и cfengine является клиент-серверной системой использующей декларативный, другими словами неотклонимый для выполнения язык для описания задач и библиотеки для их реализации. Клиенты периодически (по умолчанию 30 минут) соединяются с центральным сервером и получают последнюю конфигурацию.

Если обретенные функции не совпадают с системным состоянием, они будут выполнены, при необходимости серверу отсылается отчет о изготовленных операциях. Сервер сообщения может сохранить в syslog или файл, сделать RRD график, отослать на обозначенный e-mail.

Дополнительные уровни абстракции Transactional и Resource обепечивают наивысшую сопоставимость с существующими опциями и приложениями, позволяя сфокусироваться на системных объектах, не заботясь о различиях в реализации и описании подробных команд и форматах файлов. Администратор оперирует только с типом объекта, остальное Puppet берет на себя. Так тип packages знает о Семнадцать пакетных системах, подходящая автоматом будет распознана на основании инфы о версии дистрибутива или системы, хотя при необходимости пакетный менеджер можно задать принудительно.

В отличие от скриптов, которые часто не может быть использовать в других системах, конфигурации Puppet написанные сторонними администраторами будут в большинстве без заморочек работать в хоть какой другой сети. В Puppet CookBook уже имеется три 10-ка готовых рецептов. В настоящее время 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,

На данный момент клиенты, подключившись к серверу скопируют файл /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.

path /var/puppet/config

allow *.domain.com

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 запущен и получен новый файл, следует перезапустить сервис.

ensure => true,

subscribe => File

Переменные часто используются при работе с пользовательскими данными. Например описываем месторасположение домашнних каталогов юзеров:

$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»

Несколько ресурсов могут быть объеденены в классы или определения. Классы являются законченным описанием системы или сервиса и употребляются обособленно.

«/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»,

  • Ruby
    • Tutorial

    Здравствуйте.

    Этот топик открывает цикл статей по использованию системы управления конфигурацией Puppet .

    Что такое система управления конфигурацией?

    Предположим, что у вас есть парк серверов, выполняющих различные задачи. Пока серверов мало и вы не растёте, вы легко настраиваете каждый сервер вручную. Устанавливаете ОС (может быть, автоматизированно), добавляете пользователей, устанавливаете софт, вводя команды в консоль, настраиваете сервисы, правите конфиги ваших любимых текстовых редакторов (nanorc, vimrc), выставляете на них одинаковые настройки DNS-сервера, устанавливаете агент системы мониторинга, настраиваете syslog для централизованного сбора логов… Словом, работы довольно много и она не особенно интересна.

    Я искренне верю, что хороший админ - ленивый админ. Он не любит делать что-то несколько раз. Первая мысль - написать пару скриптов, в котором будет что-то наподобие:

    Servers.sh
    servers="server00 server01 server02 server03 server04" for server in $servers ; do scp /path/to/job/file/job.sh $server:/tmp/job.sh ssh $server sh /tmp/job.sh done

    Job.sh
    #!/bin/bash apt-get update apt-get install nginx service nginx start

    Вроде всё стало легко и хорошо. Нужно что-то сделать - пишем новый скрипт, запускаем. Изменения приходят на все серверы последовательно. Если скрипт хорошо отлажен - всё станет хорошо. До поры.

    Теперь представьте, что серверов стало больше. Например, сотня. А изменение долгое - например, сборка чего-нибудь большого и страшного (например, ядра) из исходников. Скрипт будет выполняться сто лет, но это полбеды.

    Представьте, что вам нужно сделать это только на определенной группе из этой сотни серверов. А через два дня нужно сделать другую большую задачу на другом срезе серверов. Вам придётся каждый раз переписывать скрипты и много раз проверять, нет ли в них каких-нибудь ошибок, не вызовет ли это какой-нибудь проблемы при запуске.

    Самое плохое - это то, что в подобных скриптах вы описываете действия , которые необходимо выполнить для приведения системы в определенное состояние, а не само это состояние. Значит, если система изначально находилась не в том состоянии, что вы предполагали, то всё обязательно пойдет не так. Манифесты Puppet декларативно описывают необходимое состояние системы, а вычисление, как к нему прийти из текущего состояния - задача самой системы управления конфигурацией.

    Для сравнения: манифест puppet, выполняющий ту же работу, что и пара скриптов из начала топика:

    Nginx.pp
    class nginx { package { "nginx": ensure => latest } service { "nginx": ensure => running, enable => true, require => Package["nginx"] } } node /^server(\d+)$/ { include nginx }
    Если правильно использовать серверы и потратить некоторое время на первичную настройку системы управления конфигурацией, можно добиться такого состояния парка серверов, что вам не потребуется логиниться на них для выполнения работы. Все необходимые изменения будут приходить к ним автоматически.

    Что такое Puppet?

    Puppet - система управления конфигурацией. Архитектура - клиент-серверная, на сервере хранятся конфиги (в терминах puppet они называются манифесты ), клиенты обращаются к серверу, получают их и применяют. Puppet написан на языке Ruby, сами манифесты пишутся на особом DSL, очень похожем на сам Ruby.

    Первые шаги

    Давайте забудем о клиентах, серверах, их взаимодействии и т.п. Пусть у нас есть только один сервер, на котором установлена голая ОС (здесь и далее я работаю в Ubuntu 12.04, для других систем действия будут несколько отличаться).

    Сначала установим puppet последней версии.

    Wget http://apt.puppetlabs.com/puppetlabs-release-precise.deb dpkg -i puppetlabs-release-precise.deb apt-get update apt-get install puppet puppetmaster

    Замечательно. Теперь у нас в системе установлен puppet и с ним можно играть.

    Hello, world!
    Создадим первый манифест:

    /tmp/helloworld.pp
    file { "/tmp/helloworld": ensure => present, content => "Hello, world!", mode => 0644, owner => "root", group => "root" }
    И применим его:

    $ puppet apply helloworld.pp /Stage//File/ensure: created Finished catalog run in 0.06 seconds

    Немного о запуске

    Манифесты, приведённые в этом топике можно применять вручную с помощью puppet apply. Тем не менее, в последующих топиках для работы будет использоваться master-slave конфигурация (стандартная для Puppet).


    Теперь посмотрите на содержимое файла /tmp/helloworld. В нём окажется (удивительно!) строка «Hello, world!», которую мы задали в манифесте.

    Вы можете сказать, что можно было сделать echo "Hello, world!" > /tmp/helloworld , это было бы быстрее, проще, не пришлось бы думать, писать какие-то страшные манифесты и вообще это нафиг никому не нужно это как-то слишком сложно, но задумайтесь серьезнее. На самом деле, необходимо было бы написать touch /tmp/helloworld && echo "Hello, world!" > /tmp/helloworld && chmod 644 /tmp/helloworld && chown root /tmp/helloworld && chgrp root /tmp/helloworld , чтобы гарантированно добиться того же результата.

    Давайте по строкам разберём, что именно содержится в нашем манифесте:

    /tmp/helloworld.pp
    file { "/tmp/helloworld": ensure => present, # файл должен существовать content => "Hello, world!", # содержимым файла должна являться строка "Hello, world!" mode => 0644, # права на файл - 0644 owner => "root", # владелец файла - root group => "root" # группа файла - root }

    В терминах Puppet здесь описан ресурс типа файл с названием (title) /tmp/helloworld .

    Ресурсы
    Ресурс - это самая мелкая единица абстракции в Puppet. Ресурсами могут быть:
    • файлы;
    • пакеты (Puppet поддерживает пакетные системы многих дистрибутивов);
    • сервисы;
    • пользователи;
    • группы;
    • задачи cron;
    • и т. д.
    Синтаксис ресурсов вы можете невозбранно подсмотреть .

    В Puppet есть возможность добавлять свои ресурсы. Поэтому если хорошенько заморочиться, можно докатиться до манифестов наподобие:

    Webserver.pp
    include webserver; webserver::vhost { "example.com": ensure => present, size => "1G", php => false, https => true }
    Puppet при этом будет создавать logical volume размером в 1 ГиБ на сервере, монтировать его куда положено (например в /var/www/example.com), добавлять нужные записи в fstab, создавать нужные виртуальные хосты в nginx и apache, рестартовать оба демона, добавлять в ftp и sftp пользователя example.com с паролем mySuperSecretPassWord с доступом на запись в этот виртуальный хост.

    Вкусно? Не то слово!

    Причем, самое вкусное, на мой взгляд - это не автоматизация рутины. Если вы например, идиот, и постоянно пересетапливаете ваши серверы в продакшне, Puppet позволит подхватить старый любовно созданный набор пакетов и конфигов с нуля в полностью автоматическом режиме. Вы просто устанавливаете Puppet-агент, подключаете его к вашему Puppet-мастеру и ждёте. Всё придёт само. На сервере волшебным (нет, правда волшебным!) образом появятся пакеты, разложатся ваши ssh-ключи, установится фаервол, придут индивидуальные настройки bash, сети, установится и настроится весь софт, который вы предусмотрительно ставили с помощью Puppet.
    Кроме того, Puppet при старании позволяет получить самодокументируемую систему, ибо конфигурация (манифесты) сами же являются костяком документации. Они всегда актуальны (они же работают уже), в них нет ошибок (вы же проверяете свои настройки перед запуском), они минимально подробны (работает же).

    Ещё немного магии

    Немного о кроссдистрибутивности

    В Puppet есть возможность использовать кроссдистрибутивные манифесты, это одна из целей, для которых он создавался. Я намеренно никогда не пользовался этим и вам не рекомендую. Парк серверов должен быть максимально гомогенным в плане системного ПО, это позволяет не думать в критические моменты «айблин, тут
    rc.d, а не init.d» (реверанс в сторону ArchLinux) и вообще позволяет меньше думать на рутинных задачах.

    Многие ресурсы зависят от других ресурсов. Например, для ресурса «сервис sshd» необходим ресурс «пакет sshd» и опционально «конфиг sshd»
    Посмотрим, как это реализуется: file { "sshd_config": path => "/etc/ssh/sshd_config", ensure => file, content => "Port 22 Protocol 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key HostKey /etc/ssh/ssh_host_ecdsa_key UsePrivilegeSeparation yes KeyRegenerationInterval 3600 ServerKeyBits 768 SyslogFacility AUTH LogLevel INFO LoginGraceTime 120 PermitRootLogin yes StrictModes yes RSAAuthentication yes PubkeyAuthentication yes IgnoreRhosts yes RhostsRSAAuthentication no HostbasedAuthentication no PermitEmptyPasswords no ChallengeResponseAuthentication no X11Forwarding yes X11DisplayOffset 10 PrintMotd no PrintLastLog yes TCPKeepAlive yes AcceptEnv LANG LC_* Subsystem sftp /usr/lib/openssh/sftp-server UsePAM yes", mode => 0644, owner => root, group => root, require => Package["sshd"] } package { "sshd": ensure => latest, name => "openssh-server" } service { "sshd": ensure => running, enable => true, name => "ssh" subscribe => File["sshd_config"], require => Package["sshd"] }

    Здесь используется инлайн-конфиг, который делает манифест некрасивым. На самом деле так почти никогда не делается, существует механизм шаблонов, основанный на ERB, и возможность просто использовать внешние файлы. Но нас не это интересует.

    Самые вкусные строчки здесь - это строчки зависимостей - require и subscribe.

    Puppet поддерживает много вариантов описания зависимостей. Подробно, как всегда, можно прочитать в