Puppet сервер встановлення та налаштування. Встановлюємо puppet та створюємо свій перший маніфест Повний список параметрів Bash скрипта ініціалізації клієнта Puppet

Нещодавно на сторінках журналу ми розглядали систему віддаленого керуванняконфігурацією UNIX-машин Cfengine, яка значно полегшує життя системного адміністратораза рахунок автоматизації дій щодо настроювання безлічі мережевих вузлів. Але, як би не був зручний Cfengine, він має безліч недоліків, яких позбавлена ​​система під назвою Puppet.

Уяви себе у ролі системного адміністратора, відповідального за підтримку працездатності сотні-другої машин, що працюють під управлінням операційних систем типу UNIX. Кожна з них потребує налаштування, періодичного оновлення та моніторингу, при цьому передбачається, що багато з них виконують подібні функції.

Дві третини – це робочі станції, ще кілька – маршрутизатори, решта – кілька веб-серверів та сховищ даних. Запитання: як усім цим господарством керувати? Найпростіша відповідь – це просто підключатися до кожної з них за допомогою SSH та вносити необхідні зміни. Однак такий спосіб має дві проблеми. По-перше, він дуже трудомісткий. По-друге, адміну постійно доведеться виконувати безліч одноманітних дій (наприклад, щоб оновити OpenOffice.org на всіх робочих станціях, доведеться виконати ті самі команди кілька десятків разів). Можна спробувати уникнути цієї проблеми, написавши кілька скриптів, які самі підключатимуться до кожної машини і виконуватимуть заздалегідь прописані команди. Але й тут на тебе чекають проблеми.

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

Puppet?

Ми вже присвятили цілу статтю системі Cfengine, тому сьогодні ми зупинимося на системі Puppet, яку можна назвати її ідеологічним послідовником. Puppet була розроблена Люком Канієсом (Luke Kanies), який втомився від обмежень Cfengine і вирішив створити її досконаліший аналог з нуля. Якщо ти вже використовував Cfenfine, то, напевно, знайдеш Puppet більш зручною та потужною системою. Мова опису станів Puppet більш високорівнева та гнучкий, завдяки чому адміністратору не потрібно дбати про такі речі, як написання окремих правил для кожного типу ОС або докладний описвиконання очевидних процесів. Puppet дозволяє своєму панові зосередитися на тому, що він хоче зробити, замість того, як це робити (наприклад, щоб встановити певний пакет в будь-яку з підтримуваних системою ОС, достатньо написати буквально кілька рядків, які говорять «Встанови цю програму», замість опису команд, необхідні її встановлення). Puppet написаний на простою мовою Ruby, завдяки чому його досить просто підігнати під конкретне завдання та розширити функціонал (передбачена гнучка система плагінів).

Крім того, на відміну від моделі розвитку Cfengine, яка фактично обертається навколо однієї людини, навколо Puppet сформувалося велике співтовариство ентузіастів, які вносять доробки до коду, діляться прикладами конфігурації та пишуть документацію.

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

Встановлення

Як і Cfengne, Puppet – клієнт-серверна система, яка складається з керуючого сервера та підлеглих вузлів. Сервер зберігає опис кінцевих станів вузлів (який у термінах Puppet називається маніфестом) і чекає на їх підключення. Кожні півгодини (за замовчуванням) клієнт підключається до сервера, отримує від нього опис кінцевого стану, звіряє його з поточним і, якщо він та/або описаний стан змінився, переконфігурує систему, після чого йде в сон. Комунікація проводиться через зашифрований канал, тому атаки, засновані на підміні опису стану, виключені (але якщо хакер захопить сервер, то всі вузли будуть під його контролем).

Puppet включений до репозиторії всіх популярних дистрибутивів, тому його установка не повинна викликати труднощів. Наприклад, у Debian/Ubuntu клієнт Puppet можна встановити так:

$ sudo apt-get install puppet

А сервер – так:

$ sudo apt-get install puppet puppetmaster

Конфігураційні файли клієнта та сервера зберігаються у каталозі /etc/puppet. Найважливіший із них - файл /etc/puppet/manifests/site.pp, що містить маніфест.

Він зберігає опис станів і має існувати тільки сервері. Для зручності налагодження додамо до нього найпростішу конфігурацію:

class passwd (
file ("/etc/passwd":
owner => root,
group => root,
mode => 644,
}
}
node default (
include passwd
}

Ці рядки описують стан, при якому власником файлу /etc/passwd повинен бути root, а права доступу до нього встановлені значення 644. У наступному розділі ми докладніше розглянемо формат файлу маніфесту. Другий за важливістю файл має ім'я /etc/puppet/puppet.conf. Він задає конфігурацію сервера та клієнтів, тому має бути присутнім на всіх машинах, організованих у мережу Puppet. У Ubuntu цей файл містить мінімально необхідні та здебільшого достатні налаштування. Нижче вони наведені з коментарями:

# vi /etc/puppet/puppet.conf
# Стандартні шляхи до каталогів
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
# Розташування інструменту Facter,
# використовуваного отримання інформації про ОС
factpath=$vardir/lib/facter
# Синхронізувати плагіни
# (встановив плагіни на сервер - вони копіюються на клієнтів)
pluginsync=true
# Каталог із шаблонами (про них читай нижче)
templatedir=$confdir/templates
# Синхронізація з etckeeper
# (хто знає - зрозуміє, іншим не потрібно)
prerun_command=/etc/puppet/etckeeper-commitpre
postrun_command=/etc/puppet/etckeeper-commitpost

Конфігураційний файл може включати велику кількість різних опцій, інформацію про які можна отримати, згенерувавши дефолтовий конфіг:

$ sudo puppetmasterd -genconfig > /etc/puppet/
puppetd.conf.default

Дефолтовий конфіг клієнта генерується за допомогою іншої команди:

$ sudo puppet -genconfig > /etc/puppet/puppetd.conf.default

Файли fileserver.conf та auth.conf використовуються для налаштування файлового сервера(про це читай у розділі «Файловий сервер») та аутентифікації. Поки що їх чіпати немає сенсу. Після завершення конфігурації сервер Puppet необхідно перезапустити:

$ sudo /etc/init.d/puppetmaster restart

Після цього він буде готовий приймати запити клієнтів. Однак без підписаного сертифіката жоден клієнт не зможе отримати маніфест від сервера та конфігурувати машину.

Тому ми повинні запустити клієнти Puppet у тестовому режимі, щоб вони змогли передати свої сертифікати серверу на підпис (до речі, одночасно на всіх машинах це можна зробити за допомогою shmux):

$ sudo puppetd -server puppet-сервер.com -verbose -test

Повертаємось на сервер та отримуємо список сертифікатів, готових до підпису:

$ sudo puppetca --list

Вибираємо хост зі списку та підписуємо його сертифікат:

$ sudo puppetca --sign nomad.grinder.com

Або ж підписуємо відразу все:

$ sudo puppetca --sign --all

Тепер можна запустити клієнтів у бойовому режимі. Але спочатку необхідно прописати ім'я Puppet-сервера в конфігураційному файлі (за замовчуванням його ім'я просто puppet):

$ sudo su
# echo "" >> /etc/puppet/puppet.conf
# echo "server=puppet-сервер.com" >> /etc/puppet/puppet.conf
# exit

Запускаємо клієнти:

$ sudo /etc/init.d/puppet start

Мова опису стану

Як вже було сказано вище, Puppet використовує власну мову опису кінцевого стану операційної системи, за допомогою якого сисадмін вказує на те, до якого виду повинні бути наведені компоненти ОС, щоб вона досягла бажаного стану. Це досить складна мова, яка, проте, набагато простіше будь-якої мови програмування. Якщо ти хоч поверхово знайомий з мовою сценаріїв bash, то легко розберешся в мові Puppet. Ключовим елементом мови є ресурси, за допомогою яких відбувається опис того, до якого виду має бути наведено один із компонентів ОС. Наприклад, наступний найпростіший ресурсописує бажаний стан файлу /etc/passwd:

# vi /etc/puppet/manifests/site.pp
file ("/etc/passwd":
owner => "root"
}

Тут file – це тип ресурсу. Усього їх є кілька десятків, починаючи від ресурсів, управляючих файлами, як і прикладі, і закінчуючи пакетами і сервісами. Рядок /etc/passwd - ім'я ресурсу.

У випадку типу file ім'я збігається з шляхом до файлу, проте в деяких інших типах ім'я може бути довільним. Рядок owner => "root" визначає установку атрибута owner на значення root, тобто говорить, що власником (owner) вказаного файлумає бути адміністратор.

Кожен тип ресурсів має власний набір доступних для модифікації атрибутів, плюс є спеціальні мета-атрибути, які можна використовувати в будь-якому ресурсі. Однією з важливих якостей ресурсів є можливість посилання на них. Це можна використовувати для формування ланцюжків залежностей. Наступний запис створює ресурс /etc/group, який залежить від ресурсу /etc/passwd (залежно вказуються за допомогою мета-атрибута require):

# vi /etc/puppet/manifests/site.pp
file ("/etc/group":
require => File["/etc/passwd"],
owner => "root",
}

Це означає, що ресурс /etc/group може бути налаштований (наведений до описаного виду) тільки тоді, коли буде налаштований ресурс /etc/passwd. Ресурси можуть бути згруповані в колекції ресурсів, які називають класами. Це потрібно для того, щоб об'єднати схожі за змістом і типом завдання, що виконується, ресурси в один абстрактний ресурс. Наприклад, для зручності ми могли б об'єднати інсталяцію та запуск веб-сервера nginx в один абстрактний однойменний ресурс:

# vi /etc/puppet/manifests/site.pp
class nginx (
package ("nginx":
ensure => installed
}
service ("nginx":
ensure => running,
require => Package["nginx"],
}
}

Тут тип ресурсу package використовується встановлення пакета nginx в систему, а service - для запуску однойменного сервісу. За допомогою require ми змушуємо систему запускати сервіс тільки в тому випадку, якщо пакет успішно встановлено. Зручність класів у тому, що їх також можна включати в залежності:

# vi /etc/puppet/manifests/site.pp
service ("squid":
ensure => running,
require => Class["nginx"],
}

Як і в цих ООП-мовах, класи можуть успадковувати один одного і перевизначати атрибути:

# vi /etc/puppet/manifests/site.pp
class passwd (
file ("/etc/passwd":
owner => "root",
group => "root",
}
}
class passwd-bsd inherits passwd (
File["/etc/passwd"] ( group => "wheel" )
}

Тут клас passwd-bsd успадковується від passwd для того, щоб перевизначити атрибут group ресурсу /etc/passwd (у BSD-системах /etc/passwd належить групі wheel, тому ми створили окремий клас для таких систем). Пізніше ми розглянемо правильніший і очевидніший спосіб вибору альтернативних значень атрибутів за допомогою умов.

Змінні – один із невід'ємних компонентів будь-якої мови програмування, і в мові Puppet вони теж є. Змінні починаються зі знака $ і можуть містити будь-яке число, рядок або булеве значення (true, false):

$want_apache = true
$apache_version = "2.2.14"

Однією з найпотужніших властивостей мови Puppet, пов'язаних із змінними, є інтеграція з інструментом отримання інформації про машину facter. Ця утиліта повертає всю інформацію, специфічну для машини, у вигляді пар «ключ-значення», які Puppet перетворюються на однойменні змінні. Разом з умовними інструкціями мови Puppet можуть бути використані для альтерації атрибутів ресурсу залежно від властивостей машини.

Наприклад, описаний вище клас passwd може бути легко переписаний для автоматичного вибору атрибута в залежності від типу ОС (при цьому сам клас більше не потрібен):

# vi /etc/puppet/manifests/site.pp
file ("/etc/passwd":
owner => "root",
group => $kernel? (
Linux => "root",
FreeBSD => "wheel",
},
}

Залежно від того, на якій ОС буде проаналізовано цей фрагмент маніфесту, значенням атрибуту group стане або root, або wheel. Окрім умовного оператора, мова Puppet підтримує і оператор вибору case, який можна використовувати для створення того чи іншого ресурсу залежно від змінної:

# vi /etc/puppet/manifests/site.pp
case $operatingsystem (
redhat: (service ("httpd": ensure => running))
debian: (service ("apache": ensure => running))
default: (service ("apache2": ensure =>
running ))
}

Цей код визначає різні варіантиресурсу типу service в залежності від операційної системи (імена сервісів у різних дистрибутивах Linux можуть відрізнятися, тому те, який сервіс повинен запустити Puppet, необхідно вказувати індивідуально для кожного з них).

Варіант default використовується у тому випадку, якщо значення змінної не відповідає жодному з попередніх варіантів. Крім вже розглянутих раніше типів ресурсів file, package та service, Puppet підтримує велику кількість інших, зокрема створених сторонніми розробниками типів ресурсів. Їх докладний опис, включаючи приклади, що підтримуються атрибутами та особливостями, ти можеш знайти в офіційній документації - http://docs.puppetlabs.com/references/stable/type.html . Нижче наведено список та короткий описнайбільш використовуваних із них:

Популярні типи ресурсів Puppet

• cron - керування завданнями cron
• exec - запуск скриптів та команд
• file - керування файлами
• filebucket - резервне копіюванняфайлів
• group - управління групами
• host - керування записами у файлі /etc/hosts
• interface - конфігурація мережевих інтерфейсів
• mount - монтування файлових систем
• notify - надсилання повідомлення до лог-файлу Puppet
• package - керування пакетами
• service - керування сервісами
• sshkey - керування ключами SSH
• tidy - видалення файлів в залежності від умов
• user - керування користувачами
• zones - управління зонами Solaris

Другий після ресурсів за важливістю елемент мови Puppet – це вузли (nodes). З їхньою допомогою адміністратор може описати те, до яких машин повинні бути застосовані ті чи інші ресурси та класи. Інакше кажучи, це спосіб вказати індивідуальну конфігурацію кожної з машин, що у мережі Puppet. Найпростіший приклад вузла наведено на початку статті у розділі «Установка»:

# vi /etc/puppet/manifests/site.pp
node default (
include passwd
}

Це визначення вузла default, що включає ресурс/клас passwd. Ім'я default означає «всі інші вузли», тому ресурс/ клас passwd, визначений десь вище, буде налаштовано кожному з них. Ключове слово include тут використано для зручності, насправді всі класи та ресурси можна описати прямо в описі вузла, але робити це не рекомендується. Крім default в імені вузла можна вказувати мережеве ім'ямашини (тоді всі описані у вузлі ресурси будуть налаштовані тільки на цій машині), або довільне ім'я (тоді цей вузол може бути успадкований іншим вузлом). Щоб зрозуміти, як все це працює спільно з класами та ресурсами, розглянемо приклад готового маніфесту Puppet, який використовується для конфігурування двох мережевих машин (веб-сервера та NTP-сервера):

# vi /etc/puppet/manifests/site.pp
# Встановлення та запуск SSH-сервера
class sshd (
package (openssh-server: ensure => installed)
service (sshd:
name => $operatingsystem ? (
fedora => "sshd",
debian => "ssh",
default => "sshd",
},
enable => true,
ensure => running,
}
}
# Встановлення та запуск Apache
class httpd (
package ( httpd: ensure => installed )
service ( httpd:
enable => true,
ensure => running,
}
}
# Встановлення та запуск NTP-сервера
class ntpd (
package ( ntp-server: ensure => installed )
service (
ntp-server:
enable => true,
ensure => running,
}
}
Базовий вузол, використовується тільки як батько всіх інших
node base (
include sshd
}
# Вузол, на якому буде розміщено веб-сервер
node web.server.com inherits base (
inlude httpd
}
# Вузол NTP-сервера
node ntp.server.com inherits base (
include ntpd
}

Ця проста на вигляд конфігурація робить досить багато: вона призводить до встановлення та запуску Apache на машині з адресою web.server.com і до встановлення та запуску NTP-сервера на машині ntp.server.com. Додатково обидві машини встановлюють SSH-сервер. Така конфігурація навряд чи влаштує хоч одного адміністратора; її доведеться серйозно доопрацювати, щоб навчити правильно налаштовувати сервери, отримувати нові конфіги та інші файли з головного сервера Puppet.

Однак вона наочно показує міць Puppet. За допомогою простого конфігу ми зробили так, щоб машини самі встановили і запустили необхідне ПЗ і підтримували його в робочому стані (якщо сервер впаде, Puppet сам переконфігурує, щоб привести системи до необхідного стану).

Файл-сервер

Багато завдань віддаленого адміністрування не можуть бути вирішені без копіювання на машини додаткових файлів. Це можуть бути заздалегідь підготовлені конфіги, веб-сторінки для Apache, пакети, які відсутні в офіційному репозиторії та багато іншого. Щоб полегшити процес перенесення цих файлів на віддалені вузли, Puppet включає файловий сервер.

Установки файлового сервера зберігаються у файлі /etc/puppet/fileserver.conf. Щоб змусити Puppet віддавати клієнтам вміст певного каталогу, необхідно помістити кілька рядків:

# vi /etc/puppet/fileserver.conf
path = /var/puppet/files
allow *.server.com

Ці два рядки вказують на те, що каталог /var/puppet/files повинен бути доступний для всіх хостів домену server.com. Крім того, ми можемо вказати повне доменне ім'ядозволеної машини або її IP-адресу, а також відрізати неугодних за допомогою директиви deny. Після цього будь-який файл цього каталогу можна перемістити на клієнт за допомогою ресурсу файлу. Наприклад:

# vi /etc/puppet/manifests/site.pp
file ("/etc/httpd/conf/httpd.conf":
source => "puppet://httpd/httpd.conf",
mode => 644,
}

Файл httpd.conf, розташований на сервері в каталозі /var/puppet/ files/httpd, буде скопійовано на цільову машину на шляху, вказаному в імені ресурсу.

Висновки

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

Info

• Puppet використовує протокол HTTP, тому для збільшення продуктивності можна запустити під керуванням веб-сервера.
• Puppet можна використовувати для автоконфігурування та супроводу однієї локальної машини.
• Об'єднавши Puppet, мережеву установкуОС (pxe-install) і самозбірні настановні образи, можна створити мережу машин, що повністю самоконфігурується, для розгортання якої достатньо виконати одну команду.
• Puppet використовують у своїй роботі багато великі компанії, такі як Google, Fedora Project, Stanford University, Red Hat, Siemens IT Solution та SugarCRM.

Links

• http://docs.puppetlabs.com - Документація Puppet
• http://docs.puppetlabs.com/guides/language_tutorial.html - Повний описмови Puppet
• http://docs.puppetlabs.com/references/stable/type.html - Типи ресурсів

Сергій Яремчук

Централізоване налаштування UNIX-систем за допомогою Puppet

Управління великою кількістю UNIX-систем не можна назвати зручним. Для зміни одного параметра адміністратору доводиться звертатися до кожної машини, скрипти лише частково можуть допомогти та й не у всіх ситуаціях.

Слід визнати, що адміністратори Windows-Мереж знаходяться все-таки в більш вигідному становищі. Достатньо змінити налаштування групових політик, і через деякий час усі комп'ютери мережі, у тому числі і з нещодавно встановленою операційною системою, «дізнаються» про нововведення, якщо вони їх, звичайно, стосуються. Озирнувшись на тривалий період розвитку UNIX, можна побачити, що нічого подібного не прижилося. Є рішення на кшталт kickstart, які допомагають при первинній установці операційної системи, але подальше доведення вимагатиме значних зусиль. Комерційні рішення, на кшталт BladeLogic і OpsWare, проблему автоматизації налаштувань вирішують лише частково, основна їхня перевага – наявність графічного інтерфейсу, та й дозволити їх придбати можуть лише великі організації. Є, звісно, ​​і проекти, які пропонують вільні рішення, але за весь час свого існування вони так і не змогли створити велику спільноту. Наприклад, Cfengine не дуже користується популярністю адміністраторів, хоча, крім Linux, може використовуватися в *BSD, Windows і Mac OS X. Можливо, це пов'язано з відносною складністю у створенні конфігурацій. При описі завдань доводиться враховувати особливості кожної конкретної системи та вручну контролювати послідовність дій під час виконання команд. Тобто адміністратор повинен пам'ятати, що для одних систем слід писати adduser для інших - useradd, враховувати розташування файлів різних системахі так далі. Це на порядок ускладнює процес написання команд, відразу створити правильну конфігурацію дуже складно, а створені зміни прочитати через деякий час практично нереально. Незважаючи на GPL-ліцензію Cfengine, фактично проект однієї людини, яка контролює всі зміни та не дуже зацікавлений у побудові відкритого суспільства. В результаті можливості Cfengine цілком задовольняють розробника, а для решти адміністраторів це швидше зайвий біль голови. Щоб покращити Cfengine, сторонніми розробниками було створено різні доповнення, що часто лише погіршувало ситуацію. Автор кількох таких модулів до Cfengine Люке Канієс (Luke Kanies) в результаті вирішив розробити подібний інструмент, але позбавлений багатьох недоліків Cfengine.

Можливості Puppet

Puppet, як і Cfengine, є клієнт-серверною системою, яка використовує декларативну, тобто обов'язкову для виконання мову для опису завдань та бібліотеки для їх реалізації. Клієнти періодично (за замовчуванням кожні 30 хвилин) з'єднуються з центральним сервером та отримують останню конфігурацію. Якщо отримані настройки не співпадають із системним станом, вони будуть виконані, при необхідності серверу надсилається звіт про здійснені операції. Сервер повідомлення може зберегти вsyslog або файл, створити RRD-графік, надіслати на вказаний e-mail. Додаткові рівні абстракції Transactional та Resource забезпечують максимальну сумісність з наявними налаштуваннями та додатками, дозволяючи сфокусуватися на системних об'єктах, не дбаючи про відмінності у реалізації та описі докладних командіформатах файлів. Адміністратор оперує лише з типом об'єкта, інше Puppet бере на себе. Так, тип packages знає про 17 пакетних систем, потрібну автоматично буде розпізнано на підставі інформації про версію дистрибутива або системи, хоча при необхідності пакетний менеджер можна задати примусово.

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

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"

Перед двокрапкою розташовується назва ресурсу. У найпростіших випадках як ім'я можна просто вказати повний шлях до файлу. У складніших конфігураціях краще використовувати псевдонім чи змінні. Псевдонім встановлюється за допомогою директиви:

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

Змінні часто використовуються при роботі з даними користувача. Наприклад описуємо місце розташування домашніх каталогів користувачів:

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

exec ( "/usr/bin/apt-get update":

Schedule => daily

Оновлення за той період кожною системою буде виконано лише один раз, після чого завдання вважається виконаним та буде видалено з клієнтського комп'ютера. Мова Puppet підтримує інші звичні структури: умови, функції, масиви, коментарі та подібні.

Установка Puppet

Для роботи Puppet будуть потрібні Ruby (починаючи з версії 1.8.1 і вище) з підтримкою OpenSSL та бібліотеками XMLRPC, а також бібліотека Faster. У репозитарії Ubuntu 7.04, який використовувався при тестовій установці, вже включено пакет puppy:

$ sudo apt-cache search puppet

~$ ruby ​​-rxmlrpc/client -e "puts: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:

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

Міжмережевий екран повинен дозволяти з'єднання порту 8140.

На сервері отримуємо список сертифікатів, які потребують підпису:

$ sudo puppetca –list

І підписуємо сертифікат клієнта:

$ sudo puppetca -sign nomad.grinder.com

Тепер клієнт може вільно підключатися до сервера та отримувати налаштування.

На жаль, усі можливості Puppet у межах статті показати неможливо. Але, як бачите, це функціональний і гнучкий інструмент, що дозволяє вирішити більшу частину завдань одночасного адміністрування великої кількості систем. І найголовніше, проекту вдалося зібрати поки невелике, але постійно зростаюче співтовариство. Тому сподіватимемося, що хорошій ідеї не дадуть померти чи піти убік.

Успіхів!

1. Сайт проекту BladeLogic - http://www.bladelogic.com.
2. Сайт проекту OpsWare - http://www.opsware.com.
3. Сайт проекту Cfengine - http://www.cfengine.org.
4. Сайт проекту Puppet - http://reductivelabs.com/projects/puppet.
5. Puppet CookBook – http://www.reductivelabs.com/trac/puppet/tagspuppet%2Crecipe.
6. Бібліотека Faster –

Керування великою кількістю Unix систем не можна назвати зручним. Для зміни одного параметра адміністратору доводиться звертатися до кожної машини, скрипти лише частково можуть допомогти та й не у всіх ситуаціях.

Слід визнати, що адміністратори Windows мережзнаходяться все-таки у вигіднішому становищі. Достатньо змінити налаштування групових політик і через деякий час усі комп'ютери мережі, у тому числі і з нещодавно встановленою операційною системою “дізнаються” про нововведення, якщо вони їх звичайно стосуються. Озирнувшись на тривалий період розвитку Unix, можна побачити, що нічого подібного так і не прижилося. Є рішення на кшталт kickstart, які допомагають при первинній установці операційної системи, але подальше доведення вимагатиме значних зусиль. Комерційні рішення на кшталт BladeLogic і OpsWare, проблему автоматизації налаштувань вирішують лише частково, основна їхня гідність – наявність графічного інтерфейсу, та й дозволити їх придбати можуть лише у великих організаціях. Є, звісно, ​​і проекти, які пропонують вільні рішення, але за весь час свого існування вони так і не змогли створити великої спільноти. Наприклад, Cfengine не дуже користується популярністю у адміністраторів, хоча крім Linux, може використовуватися в *BSD, Windows і Mac OS X. Можливо це пов'язано з відносною складністю у створенні конфігурацій. При описі завдань доводиться враховувати особливості кожної конкретної системи і вручну контролювати послідовність дій під час виконання команд. Тобто адміністратор повинен пам'ятати, що для одних систем слід писати adduser для інших useradd, враховувати розташування файлів у різних системах і так далі. Це на порядок ускладнює процес написання команд, відразу створити правильну конфігурацію дуже складно, а створені конфігурації прочитати через деякий час практично не реально. Не дивлячись на GPL ліцензію Cfengine фактично є проектом однієї людини, яка контролює всі зміни і не дуже зацікавлений у побудові відкритого суспільства. В результаті можливості cfengine цілком задовольняють розробника, а для інших адміністраторів це швидше зайвий біль голови. Щоб поліпшити cfengine сторонніми розробниками, були створені різні доповнення, що часто тільки погіршувало ситуацію. Автор кількох таких модулів до cfengine Люке Канієс (Luke Kanies) у результаті вирішив розробити подібний інструмент, але позбавлений багатьох недоліків cfengine.

Можливості Puppet

Puppet як і cfengine є клієнт-серверною системою, яка використовує декларативну, тобто обов'язкову для виконання мову для опису завдань та бібліотеки для їх реалізації. Клієнти періодично (за замовчуванням 30 хвилин) з'єднуються з центральним сервером та отримують останню конфігурацію. Якщо отримані настройки не співпадають із системним станом, вони будуть виконані, при необхідності серверу надсилається звіт про здійснені операції. Сервер повідомлення може зберегти в syslog або файл, створити RRD графік, надіслати на вказаний e-mail. Додаткові рівні абстракції Transactional та Resource забезпечують максимальну сумісність з існуючими налаштуваннями та додатками, дозволяючи сфокусуватися на системних об'єктах, не переймаючись відмінностями у реалізації та описі докладних команд та форматів файлів. Адміністратор оперує лише з типом об'єкта, інше Puppet бере на себе. Так тип packages знає про 17 пакетних систем, потрібна автоматично буде розпізнана на підставі інформації про версію дистрибутива або системи, хоча за необхідності пакетний менеджер можна задати примусово.

На відміну від скриптів, які часто неможливо використовувати в інших системах, конфігурації Puppet написані сторонніми адміністраторами будуть здебільшого без проблем працювати в будь-якій іншій мережі. У Puppet CookBook [ http://www.reductivelabs.com/trac/puppet/tags/puppet%2Crecipe] вже є три десятки готових рецептів. В даний час 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"

Перед двокрапкою розташовується назва ресурсу. У найпростіших випадках як ім'я можна просто вказати краще використовувати псевдонім або змінні. Псевдонім встановлюється за допомогою директиви або. повний шлях до файлу. У складніших конфігураціях

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

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 =>

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»

~$ ruby ​​-rxmlrpc/client -e «puts:yep»

Якщо не отримано помилок, то все необхідне вже включено. Файли у яких описується бажана конфігурація систем у термінології Puppet називаються маніфестами (manifests). При запуску демон намагається прочитати файл /etc/puppet/manifests/site.pp, за його відсутності видає попереджувальне повідомлення. При тестуванні можна вказати демону на роботу в автоновому режимі, при якому маніфест не потрібен

$ sudo /usr/bin/puppetmasterd -nonodes

При необхідності до site.pp можна підключати інші файли, наприклад, з описами класів. Для тестового запуску в файл можна занести найпростішу інструкцію.

file ( "/etc/sudoers":

owner => root,

group => root,

Всі файли конфігурації як сервера так і клієнтів розташовані в /etc/puppet. Файл fileserver.conf про який ми говорили вище, не є обов'язковим і використовується тільки в тому випадку коли Puppet працюватиме ще й як файл-сервер. У Ubuntu експортується підкаталог /etc/puppet/files. У підкаталозі SSL розташовані сертифікати та ключі, які будуть використовуватися для шифрування при підключеннях клієнтів. Ключі створюються автоматично при першому запуску puppetmasterd, вручну створити їх можна командою.

$ sudo /usr/bin/ puppetmasterd -mkusers.

Файли puppetd.conf та puppetmasterd.conf схожі. Вони вказуються деякі параметри роботи демонів на клієнській системі та сервері. Клієнський файл відрізняється лише наявністю параметра server, що вказує на комп'ютер, на якому запущено puppetmasterd.

server = grinder.com

logdir = /var/log/puppet

vardir = /var/lib/puppet

rundir = /var/run

# надсилаємо звіт серверу

Щоб не друкувати все вручну, можна створити шаблон за допомогою 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 в межах статті показати просто не можливо. Але як бачите це функціональний і гнучкий інструмент, що дозволяє вирішити більшу частину завдань одночасного адміністрування великої кількості систем. Якщо вам за родом роботи доводиться налаштовувати кілька систем. І найголовніше проекту вдалося зібрати поки що невелике, але постійно зростаюче співтовариство. Тому сподіватимемося, що хорошій ідеї не дадуть померти чи піти убік.

Коли число серверів, якими ви керуєте менше десяти - рідко хто замислюється про їхнє централізоване управління, цього може і не потрібно. Коли серверів десятки — централізоване управління та конфігураціями вкрай корисно. Коли серверів сотні та тисячі – це життєво необхідно. Програм такого роду багато, наприклад: Chef, CFEngine, Puppet ... Ось про останній і йтиметься в цьому записі.

Puppet гідно вважається одним з найкращих рішеньу цьому роді. Його використовують такі компанії як Google, Citrix та Red Hat. Це клієнт-серверний додаток написаний мовою програмування Ruby, який поширюється у двох варіантах:

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

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

Серверна частина Puppet називається puppetmaster, почнемо встановлення з неї:

А тепер клієнт:

У конфігураційному файлі клієнта /etc/puppet/puppet.confнеобхідно розповісти про сервер, додавши таку секцію:

Server=puppet.local report=true pluginsync=false

На початковому етапі pluginsync краще вимкнути.

Запустимо клієнт puppet щоб він створив запит на отримання сертифіката:

На сервері необхідно перевірити, що запит сертифіката отримано і, якщо це так, виписуємо сертифікат:

Повторюємо попередній крок на клієнта:

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

Перевіримо, де puppet шукає модулі:

Створюємо каталоги для свого модуля

Перший маніфест, він же основний файл модуля повинен називатися 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)

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

На клієнті:

Після того як ми переконалися що все працює, дозволяємо запуск служби, /etc/default/puppetзмінюємо:

# Start puppet on boot? START=yes

Запускаємо службу

Puppet кожні 30 хвилин опитуватиме сервер puppetmaster на предмет зміни конфігурації і, при необхідності, проводити відповідне налаштування системи.