Puppet встановлення та налаштування. Puppet сервер установка і настройка. Повний список параметрів Bash скрипта початкової установки

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

вимоги

Установка Puppet (майстер і агент). Більше про це -.
Можливість створити хоча б один віртуальний сервер Ubuntu 14.04 для обслуговування агентської Ноди Puppet.

Основи коду Puppet

ресурси

Код Puppet в основному складається з ресурсів. Ресурс - це фрагмент коду, який описує стан системи і визначає необхідні їй зміни. наприклад:

user ( "mitchell":
ensure \u003d\u003e present,
uid \u003d\u003e "1000",
gid \u003d\u003e "1000",
shell \u003d\u003e "/ bin / bash",
home \u003d\u003e "/ home / mitchell"
}

Оголошення ресурсу має такий формат:

resource_type ( "resource_name"
attribute \u003d\u003e 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 \u003d\u003e "80",
docroot \u003d\u003e "/ 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 \u003d\u003e "/ usr / bin / apt-get update" # команда, яку запустить цей ресурс
}
# Установка пакета apache2
package ( "apache2":
require \u003d\u003e Exec [ "apt-update"], # запит "apt-update" перед установкою пакета
ensure \u003d\u003e installed,
}
# Запуск сервісу apache2
service ( "apache2":
ensure \u003d\u003e running,
}
# Установка mysql-server
package ( "mysql-server":
require \u003d\u003e Exec [ "apt-update"], # запит "apt-update" передустановкой
ensure \u003d\u003e installed,
}
# Запуск сервісу mysql
service ( "mysql":
ensure \u003d\u003e running,
}
# Установка пакета php5
package ( "php5":
require \u003d\u003e Exec [ "apt-update"], # запит "apt-update" перед установкою
ensure \u003d\u003e installed,
}
# Запуск сервісу info.php
file ( "/var/www/html/info.php":
ensure \u003d\u003e file,
content \u003d\u003e "", # Код phpinfo
require \u003d\u003e 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 \u003d\u003e "password",
}

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

Додайте ресурс, який скопіює info.php в потрібне місце. Використовуйте параметр source. Додайте в блок node наступні рядки:

file ( "info.php": # ім'я файлу ресурсу
path \u003d\u003e "/var/www/html/info.php", # цільової шлях
ensure \u003d\u003e file,
require \u003d\u003e Class [ "apache"], # клас apache, який потрібно використовувати
source \u003d\u003e "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""\u003e /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:,

Управління великою кількістю 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 \u003d\u003e root,

group \u003d\u003e 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 \u003d\u003e «puppet: //server.domain.com/config/sshd_config»

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

file ( «/ etc / passwd»:

alias \u003d\u003e passwd

Інший варіант створення псевдоніма, добре підходить в тому випадку, коли доводиться мати справу з різними операційними системами. Наприклад, створимо ресурс описує файл sshd_config:

file (sshdconfig:

name \u003d\u003e $ operatingsystem? (

solaris \u003d\u003e «/ usr / local / etc / ssh / sshd_config»,

default \u003d\u003e «/ etc / ssh / sshd_config»

У цьому прикладі ми зіткнулися з можливістю вибору. Окремо вказано файл для Solaris, для всіх інших буде обраний файл / etc / ssh / sshd_config. Тепер до цього ресурсу можна звертатися як до sshdconfig, в залежності від операційної системи буде обраний потрібний шлях. Наприклад вкажемо, що в разі якщо демон sshd запущений і отримано новий файл, слід перезапустити сервіс.

ensure \u003d\u003e true,

subscribe \u003d\u003e File

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

$ Homeroot \u003d «/ home»

Тепер до файлів конкретного користувача можна звернутися як

$ (Homeroot) / $ name

У параметр $ name буде підставлена \u200b\u200bоблікове ім'я користувача. У деяких випадках зручно визначити значення за замовчуванням для деякого типу. Наприклад для типу exec дуже часто вказують каталоги в яких він повинен шукати виконуваний файл:

Exec (path \u003d\u003e «/ usr / bin: / bin: / usr / sbin: / sbin»)

У тому случе якщо потрібно вказати на кілька вкладених файлів і каталогів, можна використовувати параметр recurse.

file ( «/etc/apache2/conf.d»:

source \u003d\u003e «puppet: // puppet: //server.domain.com/config/apache/conf.d»,

recurse \u003d\u003e «true»

Кілька ресурсів можуть бути об'єднані в класи або визначення. Класи є закінченим описом системи або сервісу і використовуються відокремлено.

«/ Etc / passwd»: owner \u003d\u003e root, group \u003d\u003e root, mode \u003d\u003e 644;

«/ Etc / shadow»: owner \u003d\u003e root, group \u003d\u003e root, mode \u003d\u003e 440

Як і в об'єктно-орієнтованих мовах класи можуть перевизначатися. Наприклад в FreeBSD групою-власником цих файлів є wheel. Тому щоб не переписувати ресурс повністю, створимо новий клас freebsd, який буде наслідувати клас linux:

class freebsd inherits linux (

File [ «/ etc / passwd»] (group \u003d\u003e wheel);

File [ «/ etc / shadow»] (group \u003d\u003e wheel)

Для зручності всі класи можна винести в окремий файл, який підключати директивою include. Визначення можуть приймати численні параметри в якості аргументів, але не підтримують успадкування і використовуються в тому випадку якщо потрібно описати багаторазово використовувані об'єкти. Наприклад визначимо домашній каталог користувачів і команди необхідні для створення нового облікового запису.

define user_homedir ($ group, $ fullname, $ ingroups) (

user ( «$ name»:

ensure \u003d\u003e present,

comment \u003d\u003e «$ fullname»,

gid \u003d\u003e «$ group»,

groups \u003d\u003e $ ingroups,

membership \u003d\u003e minimum,

shell \u003d\u003e «/ bin / bash»,

home \u003d\u003e «/ home / $ name»,

require \u003d\u003e Group [$ group],

exec ( «$ name homedir»:

command \u003d\u003e «/ bin / cp -R / etc / skel / home / $ name; / Bin / chown -R $ name: $ group / home / $ name »,

creates \u003d\u003e «/ home / $ name»,

require \u003d\u003e User [$ name],

Тепер щоб створити нову обліковий запис досить звернутися до user_homedir.

user_homedir ( «sergej»:

group \u003d\u003e «sergej»,

fullname \u003d\u003e «Sergej Jaremchuk»,

ingroups \u003d\u003e [ «media», »admin]

Окремо стоять опису вузлів (node), які підтримують успадкування як і класи. При підключенні клієнта до сервера Puppet буде проведений пошук соотетсвующей секції node і видані специфічні тільки для цього комп'ютера настройки. Для опису всіх інших систем можна використовувати node default. Опис усіх типів наведено в документі "Type Reference" з яким необхідно ознайомитися в будь-якій випадку, хоча б, для того щоб зрозуміти всі можливості мови Puppet. різні типи дозволяють виконувати зазначені команди, в тому числі і при виконанні певних умов (наприклад зміна конфігураційного файлу), працювати з cron, обліковими даними і групами користувачів, комп'ютерами, монтуванням ресурсів, запуском і зупинкою сервісів, установкою, оновленням і видаленням пакетів, роботою з SSH ключами, зонами Solaris і так далі. Ось так просто можна змусити оновлювати список пакетів в дистрибутивах використовують apt, щодня між 2 і 4 годинами.

schedule (daily:

period \u003d\u003e daily,

range \u003d\u003e

exec ( «/ usr / bin / apt-get update»:

schedule \u003d\u003e daily

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

установка Puppet

Для роботи Puppet будуть потрібні Ruby (\u003e \u003d 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 \u003d\u003e root,

group \u003d\u003e root,

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

$ Sudo / usr / bin / puppetmasterd -mkusers.

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

server \u003d grinder.com

logdir \u003d / var / log / puppet

vardir \u003d / var / lib / puppet

rundir \u003d / var / run

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

Щоб не друкувати все вручну, можна створити шаблон за допомогою самого puppetd.

$ Puppetd -genconfig\u003e /etc/puppet/puppetd.conf

Аналогічно можна створити і site.pp на сервері.

$ Puppetd -genmanifest\u003e /etc/puppet/manifests/site.pp

Ще один файл tagmail.conf, дозволяє вказати поштові адреси на які будуть надсилатися звіти. У найпростішому випадку можна використовувати один рядок.

all: [Email protected]

Конфігураційних файлів недостатньо, щоб клієнт міг підключатися до сервера. Для цього необхідно ще підписати сертифікати. Спочатку щоб сервер дізнався про новий комп'ютер на клієнтській системі вводимо команду:

$ Sudo puppetd -server grinder.com -waitforcert 60 -test

info: Requesting certificate

warning: peer certificate will not 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 \u200b\u200b/ usr / sbin / puppetmasterd

Брандмауер повинен дозволяти з'єднання на порт 8140.

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

$ Sudo puppetca -list

nomad.grinder.com

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

$ Sudo puppetca -sign nomad.grinder.com

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

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

Не так давно на сторінках журналу ми розглядали систему віддаленого управління конфігурацією UNIX-машин Cfengine, яка істотно полегшує життя системного адміністратора за рахунок автоматизації процесів з налаштування безлічі мережевих вузлів. Але, як би не був зручний Cfengine, у нього є безліч недоліків, яких позбавлена \u200b\u200bсистема під назвою 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 \u003d\u003e root,
group \u003d\u003e root,
mode \u003d\u003e 644,
}
}
node default (
include passwd
}

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

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

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

$ Sudo puppetmasterd -genconfig\u003e / etc / puppet /
puppetd.conf.default

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

$ Sudo puppet -genconfig\u003e /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 "" \u003e\u003e /etc/puppet/puppet.conf
# Echo "server \u003d puppet-сервер.com" \u003e\u003e /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 \u003d\u003e "root"
}

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

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

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

# Vi /etc/puppet/manifests/site.pp
file ( "/ etc / group":
require \u003d\u003e File [ "/ etc / passwd"],
owner \u003d\u003e "root",
}

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

# Vi /etc/puppet/manifests/site.pp
class nginx (
package ( "nginx":
ensure \u003d\u003e installed
}
service ( "nginx":
ensure \u003d\u003e running,
require \u003d\u003e Package [ "nginx"],
}
}

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

# Vi /etc/puppet/manifests/site.pp
service ( "squid":
ensure \u003d\u003e running,
require \u003d\u003e Class [ "nginx"],
}

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

# Vi /etc/puppet/manifests/site.pp
class passwd (
file ( "/ etc / passwd":
owner \u003d\u003e "root",
group \u003d\u003e "root",
}
}
class passwd-bsd inherits passwd (
File [ "/ etc / passwd"] (group \u003d\u003e "wheel")
}

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

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

$ Want_apache \u003d true
$ Apache_version \u003d "2.2.14"

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

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

# Vi /etc/puppet/manifests/site.pp
file ( "/ etc / passwd":
owner \u003d\u003e "root",
group \u003d\u003e $ kernel? (
Linux \u003d\u003e "root",
FreeBSD \u003d\u003e "wheel",
},
}

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

# Vi /etc/puppet/manifests/site.pp
case $ operatingsystem (
redhat: (service ( "httpd": ensure \u003d\u003e running))
debian: (service ( "apache": ensure \u003d\u003e running))
default: (service ( "apache2": ensure \u003d\u003e
running))
}

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

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

Файл-сервер

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

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

# Vi /etc/puppet/fileserver.conf
path \u003d / var / puppet / files
allow * .server.com

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

# Vi /etc/puppet/manifests/site.pp
file ( "/etc/httpd/conf/httpd.conf":
source \u003d\u003e "puppet: //httpd/httpd.conf",
mode \u003d\u003e 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 - Типи ресурсів

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

: ~ # Apt-get install puppetmaster

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

: ~ # Apt-get install puppet

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

Server \u003d puppet.local report \u003d true pluginsync \u003d 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 \u003d\u003e "present", target \u003d\u003e "/ etc / hosts", ip \u003d\u003e "192.168.0.1", host_aliases \u003d\u003e "puppet",) # linux.local host ( "linux.local": ensure \u003d\u003e "present", target \u003d\u003e "/ etc / hosts", ip \u003d\u003e "192.168.0.2", host_aliases \u003d\u003e "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 \u003d yes

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

: ~ # Service puppet start

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

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

Централізована настройка 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 \u003d\u003e root,

Group \u003d\u003e root,

Mode \u003d\u003e 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 \u003d\u003e "puppet: //server.domain.com/config/sshd_config"

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

file ( "/ etc / passwd":

Alias \u200b\u200b\u003d\u003e passwd

Інший варіант створення псевдоніма добре підходить в тому випадку, коли доводиться мати справу з різними операційними системами. Наприклад, створимо ресурс, що описує файл sshd_config:

file (sshdconfig:

Name \u003d\u003e $ operatingsystem? (

Solaris \u003d\u003e "/ usr / local / etc / ssh / sshd_config",

Default \u003d\u003e "/ etc / ssh / sshd_config"

У цьому прикладі ми зіткнулися з можливістю вибору. Окремо вказано файл для Solaris, для всіх інших буде обраний файл / etc / ssh / sshd_config. Тепер до цього ресурсу можна звертатися як до sshdconfig, в залежності від операційної системи буде обраний потрібний шлях. Наприклад, вкажемо, що в разі, якщо демон sshd запущений і отримано новий файл, слід перезапустити сервіс:

service (sshd:

Ensure \u003d\u003e true,

Subscribe \u003d\u003e File

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

$ Homeroot \u003d "/ home"

Тепер до файлів конкретного користувача можна звернутися як:

$ (Homeroot) / $ name

У параметр $ name буде підставлена \u200b\u200bоблікове ім'я користувача. У деяких випадках зручно визначити значення за замовчуванням для деякого типу. Наприклад, для типу exec дуже часто вказують каталоги, в яких він повинен шукати виконуваний файл:

Exec (path \u003d\u003e "/ usr / bin: / bin: / usr / sbin: / sbin")

У тому випадку, якщо потрібно вказати на кілька вкладених файлів і каталогів, можна використовувати параметр recurse:

file ( "/etc/apache2/conf.d":

Source \u003d\u003e "puppet: // puppet: //server.domain.com/config/apache/conf.d",

Recurse \u003d\u003e "true"

Кілька ресурсів можуть бути об'єднані в класи або визначення. Класи є закінченим описом системи або сервісу і використовуються відокремлено:

class linux (

File (

"/ Etc / passwd": owner \u003d\u003e root, group \u003d\u003e root, mode \u003d\u003e 644;

"/ Etc / shadow": owner \u003d\u003e root, group \u003d\u003e root, mode \u003d\u003e 440

Як і в об'єктно-орієнтованих мовах, класи можуть перевизначатися. Наприклад, в FreeBSD групою-власником цих файлів є wheel. Тому, щоб не переписувати ресурс повністю, створимо новий клас freebsd, який буде наслідувати клас linux:

class freebsd inherits linux (

File [ "/ etc / passwd"] (group \u003d\u003e wheel);

File [ "/ etc / shadow"] (group \u003d\u003e wheel)

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

define user_homedir ($ group, $ fullname, $ ingroups) (

User ( "$ name":

Ensure \u003d\u003e present,

Comment \u003d\u003e "$ fullname",

Gid \u003d\u003e "$ group",

Groups \u003d\u003e $ ingroups,

Membership \u003d\u003e minimum,

Shell \u003d\u003e "/ bin / bash",

Home \u003d\u003e "/ home / $ name",

Require \u003d\u003e Group [$ group],

Exec ( "$ name homedir":

Command \u003d\u003e "/ bin / cp -R / etc / skel / home / $ name; / bin / chown -R $ name: $ group / home / $ name",

Creates \u003d\u003e "/ home / $ name",

Require \u003d\u003e User [$ name],

Тепер, щоб створити новий обліковий запис, достатньо звернутися до user_homedir:

user_homedir ( "sergej":

Group \u003d\u003e "sergej",

Fullname \u003d\u003e "Sergej Jaremchuk",

Ingroups \u003d\u003e [ "media", "admin]

Окремо стоять опису вузлів (node), які підтримують успадкування, як і класи. При підключенні клієнта до сервера Puppet буде проведений пошук відповідної секції node і видані специфічні тільки для цього комп'ютера настройки. Для опису всіх інших систем можна використовувати node default. Опис усіх типів наведено в документі «Type Reference», з яким необхідно ознайомитися в будь-якому випадку, хоча б для того, щоб зрозуміти всі можливості мови Puppet. Різні типи дозволяють виконувати зазначені команди, в тому числі і при виконанні певних умов (наприклад, зміна конфігураційного файлу), працювати з cron, обліковими даними і групами користувачів, комп'ютерами, монтуванням ресурсів, запуском і зупинкою сервісів, установкою, оновленням і видаленням пакетів, роботою з SSH-ключами, зонами Solaris і так далі. Ось так просто можна змусити оновлювати список пакетів в дистрибутивах, які використовують apt, щодня між 2 і 4 годинами:

schedule (daily:

Period \u003d\u003e daily,

Range \u003d\u003e

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

Schedule \u003d\u003e 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"

yep

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

$ Sudo / usr / bin / puppetmasterd --nonodes

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

class sudo (

File ( "/ etc / sudoers":

Owner \u003d\u003e root,

Group \u003d\u003e root,

Mode \u003d\u003e 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 \u003d grinder.com

logdir \u003d / var / log / puppet

vardir \u003d / var / lib / puppet

rundir \u003d / var / run

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

report \u003d true

Щоб не друкувати все вручну, можна створити шаблон за допомогою самого puppetd:

$ Puppetd --genconfig\u003e /etc/puppet/puppetd.conf

Аналогічно можна створити і site.pp на сервері:

$ Puppetd --genmanifest\u003e /etc/puppet/manifests/site.pp

Ще один файл tagmail.conf, дозволяє вказати поштові адреси, на які будуть надсилатися звіти. У найпростішому випадку можна використовувати один рядок:

all: [Email protected]

Конфігураційних файлів недостатньо, щоб клієнт міг підключатися до сервера. Для цього необхідно ще підписати сертифікати.

Спочатку, щоб сервер дізнався про новий комп'ютер, на клієнтській системі вводимо команду:

$ Sudo puppetd --server grinder.com --waitforcert 60 -test

Брандмауер повинен дозволяти з'єднання на порт 8140.

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

$ Sudo puppetca -list

nomad.grinder.com

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

$ Sudo puppetca -sign nomad.grinder.com

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

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

Успіхів!