Головна › Поради › Master of puppets: Встановлення та налаштування системи віддаленого керування конфігурацією Puppet. Master of puppets: Встановлення та налаштування системи віддаленого керування конфігурацією Puppet Встановлення puppet

Master of puppets: Встановлення та налаштування системи віддаленого керування конфігурацією Puppet. Master of puppets: Встановлення та налаштування системи віддаленого керування конфігурацією Puppet Встановлення puppet

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

Вимоги

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

Основи коду Puppet

Ресурси

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

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

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

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

Щоб переглянути всі типи ресурсів Puppet, введіть:

puppet resource --types

Більше про типи ресурсів ви дізнаєтесь у цьому посібнику.

Маніфести

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

Класи

Як і у будь-якій звичайній мові програмування, класи відповідають за організацію та повторне використання частин оркестрування.

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

Визначення класу має такий формат:

class example_class (
...
code
...
}

Цей код визначає клас example_class. Код Puppet перебуватиме у фігурних дужках.

Оголошення класу – це місце у коді, де викликається той чи інший клас. За допомогою оголошення класу Puppet обробляє його код.

Оголошення класу буває типовим і за типом ресурсу.

Звичайне оголошення класу додається до коду за допомогою ключового слова include.

include example_class

При оголошенні типу ресурсу клас оголошується у форматі ресурсу:

class ( "example_class": )

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

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

Модулі

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

Модулі Puppet зберігаються у каталозі /etc/puppet/modules.

Написання маніфесту

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

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

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

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

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

Примітка: Для тестування краще використовувати свіжий віртуальний сервер

Приклад 1: Встановлення LAMP за допомогою одного маніфесту

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

У цьому розділі ви навчитеся писати маніфести, які будуть використовувати такі типи об'яв ресурсів:

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

Створення маніфесту

Створіть новий маніфест:

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

Додайте наступний код, щоб оголосити необхідні ресурси.

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

Застосування маніфесту

Щоб використати новий маніфест, введіть команду:

sudo puppet apply --test

Вона виведе об'ємний результат, який відображає зміни стану середовища. Якщо у виведенні немає помилок, ви зможете відкрити свою зовнішню IP-адресу або доменне ім'я у браузері. На екрані з'явиться тестова сторінка PHPз інформацією про стек. Це означає, що Apache та PHP працюють.

Тепер стек LAMP встановлений на сервер за допомогою Puppet.

Це досить простий маніфест, оскільки його можна виконати агентом. Якщо ви не маєте майстра Puppet, інші агентські ноди не зможуть використовувати цей маніфест.

Майстер-сервер Puppet перевіряє зміни стану сервера кожні 30 хвилин.

Приклад 2: Встановлення стека LAMP за допомогою модуля

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

Щоб створити модуль, створіть у каталозі modules новий каталог (його ім'я має збігатися з ім'ям модуля). У цьому каталозі повинні бути каталоги manifests і файл init.pp. У файлі init.pp вказується клас Puppet (його ім'я також має збігатися з ім'ям модуля).

Створення модуля

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

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

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

sudo vi lamp/manifests/init.pp

У файл вставте клас lamp:

class lamp (
}

Скопіюйте вміст маніфесту з розділу 1 і вставте його в блок класу лампи. Тепер у вас є визначення класу lamp. Інші маніфести зможуть використовувати цей клас як модуль.

Збережіть та закрийте файл.

Використання модуля у головному маніфесті

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

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

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

Швидше за все, на Наразіфайл порожній. Додайте до нього наступні рядки:

node default ( )
node "lamp-1" (
}

Примітка: Замість lamp-1 вкажіть ім'я хоста свого агента Puppet, на який потрібно встановити стек.

Блок node дозволяє вказати код Puppet, який застосовуватиметься лише до деяких нодів.

Блок default застосовується до всіх агентських нодів, які не мають індивідуального блоку (залишіть його порожнім). Блок lamp-1 застосовуватиметься до агентської ноди lamp-1.

Додайте до цього блоку наступний рядок, який використовує модуль lamp:

Збережіть та закрийте файл.

Тепер агентська нода Puppet зможе завантажити налаштування з майстер-сервера та встановити стек LAMP. Якщо ви бажаєте внести зміни прямо зараз, запустіть на агенті команду:

sudo puppet agent --test

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

Приклад 3: Встановлення LAMP за допомогою загальнодоступних модулів

Модуль MySQL використовується так само. Додайте в блок ноди такі рядки:

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

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

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

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

У цьому оголошенні класу використовується параметр source замість content. Цей параметр використовує не лише вміст файлу, але й копіює його.

Файл puppet:///modules/apache/info.php Puppet скопіює у /etc/puppet/modules/apache/files/info.php.

Збережіть та закрийте файл.

Створити файл info.php.

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

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

sudo puppet agent --test

Ця команда завантажить всі оновлення для поточної ноди і встановить стек. Щоб переконатися, що Apache та PHP працюють, відкрийте IP-адресу або домен ноди у браузері:

http://lamp_1_public_IP/info.php

Висновок

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

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

Tags: ,
Небагато лірики.З цієї статті слід розпочинати весь цикл, але все ж цільовою аудиторією є досвідченіші користувачі Open Source продуктів Puppet Labs, яких не влаштовують окремі малоінтегровані модулі з Puppet Forge. Як і з будь-яким випадком "library vs. framework", розплатою є дотримання світогляду автора інтегрованого рішення.

Трохи про принцип роботи Puppet

Puppet – це насамперед специфічна мова декларативного завдання кінцевого стану системи. Для порівняння вкрай підійде GNU Makefile, де, крім безпосереднього опису залежностей, є можливість начудити на повну котушку.

Абстракція Puppet приблизно наступна ( зрив шаблонів – забудьте все, що ви знали про терміни у програмуванні!).

Вузол (node)- це сукупність зміни для конкретної цільової системи. Насправді це окремий випадок класу.
Клас (class)- це набір декларативної логіки, яка входить у конфігурацію вузла чи інші класи. Клас не має ні екземплярів, ні методів, зате є параметри і змінні, визначені всередині логіки. Насправді це швидше процедура, яка може успадковувати іншу процедуру банальним нарощуванням коду і не зовсім банальною областю видимості змінних.
Тип (type)- а ось це вже більше скидається на класичний клас - у нього передбачаються екземпляри з ім'ям і безперечно заданими параметрамиале нічого більше. Конкретна реалізація типу може бути написана у вигляді Puppet скрипта через define , який створює екземпляри інших типів або у вигляді розширення на Ruby з польотом фантазії.
Ресурс (resource)- Саме це і є іменовані екземпляри Типів. Ім'я кожного ресурсу унікальне у межах конкретного типу межах конфігурації вузла (каталога).
Змінні (variable)- Ну, коротше це константи ... До версії Puppet 4 з їх областю видимості було все ще гірше. Тепер вона адекватна: для використання ззовні місця визначення потрібно задавати повністю кваліфікований ідентифікатор, за винятком наслідування класів.

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

В ідеологічно правильному ключі інфраструктура Puppet складається з агента - привілейованого сервісу на цільовій системі та сервера, що роздає цінні вказівки у вигляді декларативних каталогів ресурсів на запит від агентів. Безпека реалізована лише на рівні приватної інфраструктури громадського ключа (X.509). Простіше кажучи, тих же механізмів, що і в HTTPS, але з власним CA і обов'язковою перевіркою клієнтського сертифіката.

У спрощеному вигляді процедура розгортання виглядає приблизно так:

Обробка по TLS та X.509 (установка з'єднання, оновлення CRL, перевірка обмежень сертифіката тощо)
Агент отримує генератори фактів із сервера з кешуванням та всіма справами (точніше витягується все з папок lib/ у модулях). Не складає ніяких труднощів додати свій Ruby скрипт для збору інформації, що цікавить.
Агент збирає факти про цільову систему та відправляє на сервер. Всі факти легко переглянути вручну через виклик puppet facts. Ці факти доступні як глобальні змінні.
Сервер складає каталог ресурсів та відправляє агенту. Під цим ховається цілий пласт різних концепцій.
Агент витягує все необхідне з сервера та наводить систему до зазначеного виду. Сам агент при цьому не знає як чинити з ресурсами, він покладається на реалізацію provider"ів (смисловий переклад буде "втільник", а не постачальник) конкретних типів ресурсів. Частина provider"ів є стандартними і входять до пакетів Puppet, а інші витягуються з модулів.

Для смакування всіх принад, існує додаткові плюшки у вигляді:

Модуль- сукупність декларативних скриптів Puppet, Ruby розширень для Puppet, файлів, шаблонів файлів, Hiera даних та багато іншого. Більш правильний термін був би "пакет".
Середовище (Environment)- сукупність скриптів, модулів та Hiera даних. З ускладненням інфраструктури неминуче знадобилося розділяти конфігурацію далі стандартного поділу по вузлам. В основному це потрібно для пілотних нововведень та банального контролю доступу (коли не всі адміни мають доступ до всіх вузлів IT інфраструктури).
Hiera- Ієрархічна база даних. Таке формулювання може сильно відлякувати. Саме тому її й змінили в документації пізніших версій. Насправді це дуже простий і зручний механізм витягувати конфігурацію з YAML або JSON файлів. Ієрархія полягає у можливості встановити порядок читання безлічі конфігураційних файлів - тобто. ієрархію/пріоритет цих файлів.
- Крім витягування даних на виклик функції, Puppet витягує параметри класів за замовчуванням, що є головною родзинкою.
- Очевидно, Hiera підтримує інтерполяцію фактів і навіть виклик особливих функцій.
- У Puppet 4.3 реалізували цей же функціонал ще раз для підтримки не тільки глобальної бази даних, але й локальної для Середовища та Модуля, правда автор вже знайшов кілька проблем у їх реалізації (PUP-5983, PUP-5952 та PUP-5899), які були миттєво виправлено Puppet Labs.
- Підтримуються кілька стратегій витягування значення з усіх файлів з ієрархії:
  - first - видається перше що по пріоритету значення
  - unique - збирає всі значення в одновимірний масив і прибирає дублікати
  - hash - поєднує всі знайдені YAML Hash. Дублікати ключів вибираються за пріоритетом.
  - deep - по суті, рекурсивний варіант hash
- Принадність у цьому, що стратегія вибірки може задаватися як із виклику функції lookup() , т.к. і в будь-якому файлі ієрархії через спеціальний ключ lookup_options, що активно використовується в модулі cfnetwork.
PuppetDB- по суті шар бізнес логіки навколо реляційної бази даних (PostgreSQL), який дозволяє зберігати звіти про факти та зроблені розгортання та експортувати ресурси для подальшого імпорту в каталоги на інших вузлах або вибірки через спеціальні функції. Ще є і веб-морда у вигляді Puppet Dashboard.
X.509 PKI- вже згадана інфраструктура сертифікатів, яку вкрай зручно використовуватиме інших сервісів без необхідності управління окремою інфраструктурою.
MCollective- начебто корисна річ для подійного запуску завдань на серверній фермі, але автор має певну недовіру до безпеки конкретного рішення.
Puppet Forge- відкритий майданчик для публікації та завантаження Модулей.
деякі інші фічі у вигляді управління зовнішніми пристроямитипу обладнання Cisco та розгортання на голому залозі, але це вже окрема історія

Нотатки з безпеки та доступності

Потрібно розуміти, що Puppet Server стає вразливим місцем IT інфраструктури, т.к. визначає кінцеву конфігурацію всіх систем. В особливих випадках має сенс робити поділ - окремий сервер для критичних елементів інфраструктури з вкрай обмеженим доступіві ручним оновленням і другий для решти.

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

У жодному разі, не слід встановлювати інші послуги на системі, де буде розгорнутий Puppet Server з прибамбасами. Віртуалізація та контейнеризація вам на допомогу.

Мульти-майстер (кілька відокремлених Puppet Server)

У разі лише один сервер виступає ролі CA (Certificate Authority) - його недоступність означає неможливість додати нові вузли.
- Puppet дозволяє використовувати сторонню інфраструктуру X.509, якщо вбудована не влаштовує.
Вся конфігурація (Середовище) повинна зберігатися в системі контролю версій та розгортатися на кожному сервері одночасно.
Єдине загальне - це база PostgreSQL, організація високої доступності якої виходить за межі цієї статті.
Модуль cfpuppetserver підтримує установки як основний (з CA) і як другорядний сервер.

Що значуще змінилося з старіших версій

Повний опис є у виробника.

Усі сервіси переїхали на JVM, JRuby та Jetty. За очевидними достоїнствами інтегрованості є і мінуси з витрат пам'яті.
Додалися лямбда-функції для обробки колекцій - тепер не потрібно пиляти милиці на Ruby або перекручуватися через create_resources()
З'явився інструмент обробки шаблонів EPP - по суті той же ERB, але з Puppet DSL замість Ruby,
Сильно змінилося структура каталогів конфігураційних файлів за промовчанням
З'явилася підтримка Data Providers для Середовищ і Модулей (більше не потрібні хакі).
Приниження ролі глобальної Hiera. Нова пов'язана з цим команда puppet lookup.

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

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

Три основні компоненти сервера - це Puppet Server, PuppetDB і PostgreSQL. Їх усіх можна запхати на один вузол або розбити на дві-три системи. Puppet Server і Puppet DB можуть бути запущені багато разів, а ось PostgeSQL є єдиним вузлом відмови. Є різноманітні підхід до реплікації і кластеризації PostgeSQL. входить у модуль cfpuppetserver.

Конфігурацію можна просто зберігати хоч на файловій системіразом з Puppet Server, але це як писати скрипти на бойовому веб-сервері. Найкраще рішення - це git репозиторій. Утиліта r10k вміє витягувати всі гілки репозиторію та розгортати їх на Puppet Server як окремі середовища. У r10k досить погано з витягуванням залежностей, тому поверх використовується librarian-puppet. Варто відразу помітити, що основним канонічним середовищем Puppet є "production". Тому в репозиторії конфігурації слід використовувати гілку під назвою "production", а не "master".

Системні вимоги

Залізом описано самим виробником. Модуль cfpuppetserver поки що підтримує тільки Debian Jessie+ та Ubuntu Trusty+.

Конфігурація у Git

Для самого r10k розміщення репозиторію немає великого значення - головне його доступність. Наприклад, з метою тестування репозиторій можна розмістити на тій системі з доступом через file:// . Хорошим стартом буде приклад конфігурації codingfuture/puppet-exampleenv.

Клонуємо репозиторій: git clone https://github.com/codingfuture/puppet-exampleenv my-puppet-conf && cd my-puppet-conf
Встановлюємо Загальні налаштуванняадмінського доступу, використовуючи підказки у коментарях:
- $EDITOR data/common.yaml
Створимо конфігурацію вузлів:
- $MY_DOMAIN - кореневе доменне ім'я (наприклад, example.org)
- $HOST_NAME - ім'я клієнтського вузла без домену
- mkdir data/$MY_DOMAIN
- cp data/example.com/puppet.yaml data/$(MY_DOMAIN)/puppet.yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/puppet.yaml - налаштування вузла з Puppet Server за підказками у коментарях
- cp data/example.com/host.yaml data/$(MY_DOMAIN)/$(HOST_NAME).yaml
- $EDITOR nano -w data/$(MY_DOMAIN)/$(HOST_NAME).yaml - налаштування довільного вузла за підказками у коментарях
Пушаємо на свій Git сервер або робимо доступним локально на вузлі з Puppet Server через rsync або scp. Локальний репозиторій зручний як проміжний крок доки Git сервер не розгорнуть з самого Puppet. В якомусь сенсі це нагадує збирання компілятора в кілька етапів.

Ставимо з нуля на чистій системі

Модуль cfpuppetserver дозволяє встановити все засобами самого Puppet, але для початкового встановлення базові операції продубльовані скриптом Bash.

На цільовій системі:

Завантажуємо скрипт установки: wget https://raw.githubusercontent.com/codingfuture/puppet-cfpuppetserver/master/setup_puppetserver.sh
Переглядаємо скрипт та хмуримо брівки: less setup_puppetserver.sh
Запускаємо: bash setup_puppetserver.sh
puppet.$(MY_DOMAIN) .
- Приклад із віддаленим репозиторієм: bash setup_puppetserver.sh ssh:// [email protected]/puppet-conf
- Приклад локального: bash setup_puppetserver.sh file:///root/puppetconf/
Дивимося як пишається система і не дуже швидко все встановлює.
Якщо віддалений репозиторій:
- Створюємо SSH ключ у root"а: ssh-keygen -t rsa -b 2048
- Прописуємо публічний ключ /root/.ssh/id_rsa.pub дистанційному сервері Git...
- … і там же надсилаємо Git hook з викликом наступної команди: /usr/bin/ssh -T deploypuppet@puppet.$(MY_DOMAIN) ./puppetdeploy.sh
Запускаємо розгортання конфігурації вручну: /etc/puppetlabs/deploy.sh
Пробуємо як працює на сервері: /opt/puppetlabs/bin/puppet agent --test
Перевірте налаштування мережі, мережевого фільтрата SSH-доступу

Додаємо керовані вузли

Повне ім'я Puppet Server має бути доступне через DNS на керованому вузлі або слід "зашити" в /etc/hosts.
- Наприклад: echo "128.1.1.1 puppet.example.com" >> /etc/hosts
На вузлі з Puppet Server запускаємо наступний скрипт /root/genclientinit.sh $(HOST_NAME).$(MY_DOMAIN) .
Результат копіюємо повністю і вставляємо в командний рядокна цільовій системі.
Чекаємо на закінчення виконання і запускаємо /opt/puppetlabs/bin/puppet agent --test . Під час першого запуску буде згенеровано запит на підпис сертифіката.
Ідемо на вузол Puppet Server, щоб підписати сертифікат.
- puppet cert list - звіряємо сигнатуру сертифікату для більшої параноїдальності.
- puppet cert sign $(HOST_NAME).$(MY_DOMAIN) - власне, підписуємо сертифікат.
Повертаємось на керований вузол і запускаємо: /opt/puppetlabs/bin/puppet agent --test` ще раз. Це примусово запустить процедуру розгортання.
Чекаємо поки закінчиться виконання розгортання через Puppet Agent.
Все, у вас готова мінімальна інфраструктура Puppet!

Приклад виводу /root/genclientinit.sh

bash</etc/cflocation fi if test! -z ""; then echo -n >/etc/cflocationpool fi if test! -z "\$http_proxy"; then export http_proxy export https_proxy="\$http_proxy" export HTTP_PROXY="\$http_proxy" export HTTPS_PROXY="\$http_proxy" fi echo host.example.com > /etc/hostname hostname host.example.com if ! які lsb-release | read; apt-get install lsb-release fi codename=\$(lsb_release -cs) if test -z "\$codename"; then echo "Допустити помилку правильного codename" exit 1 fi wget https://apt.puppetlabs.com/puppetlabs-release-pc1-\$(codename).deb dpkg -i puppetlabs-release-pc1-\$(codename) .deb mkdir -p /etc/puppetlabs/puppet cat > /etc/puppetlabs/puppet/puppet.conf<puppet cert sign host.example.com" echo "Увімкніть CTRL+C для перемикання cycle, якщо не вдається до різних умов" sleep 5 done EOT

Опис модуля

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

~# ./setup_puppetserver.sh Usage: ./setup_puppetserver.sh [ [ [ [] ] ] ]

r10k_repo_url - URI Git репозиторія
certname - повне доменне ім'я вузла
cflocation – ініціалізація факту cf_location
cflocationpool – ініціалізація факту cf_location_pool
http_proxy - проксі сервер для HTTP та HTTPS запитів

Повний перелік параметрів Bash скрипта ініціалізації клієнта Puppet

~# /root/genclientinit.sh Usage: ./genclientinit.sh [ [ []]]
Значення параметрів таке саме, як у попереднього скрипта.

клас cfpuppetserver

deployuser = "deploypuppet" - ім'я користувача для автоматичного розгортання оновлень конфігурації
deployuser_auth_keys = undef - список ключів для $deployuser
repo_url = undef - URI репозиторія (приклад: ssh://user@host/repo або file:///some/path)
puppetserver = true - чи встановлювати компонент Puppet Server на цей вузол
puppetdb = true - чи встановлювати компонент PuppetDB на цей вузол
puppetdb_port = 8081 - порт для PuppetDB
setup_postgresql = true - чи встановлювати компонент PostgreSQL на даний вузол (тільки якщо увімкнена установка PuppetDB)
service_face = "any" - назва ресурсу cfnetwork::iface для прийняття вхідних з'єднань
puppetserver_mem = auto – оперативна пам'ять під Puppet Server у мегайбатах (мінімум 192MB)
puppetdb_mem = auto – оперативна пам'ять під PuppetDB у мегайбатах (мінімум 192MB)
postgresql_mem = auto - оперативна пам'ять під PostgreSQL у мегайбатах (мінімум 128MB)

клас cfpuppetserver::puppetdb

postgresql_host = "localhost" - адреса бази даних
postgresql_listen = $postgresql_host - значення йде прямо у директиву listen_addresses PostgreSQL
postgresql_port = 5432 - порт бази даних
postgresql_user = "puppetdb" - користувач PuppetDB у базі даних
postgresql_pass = "puppetdb" - пароль користувача PuppetDB у базі даних
postgresql_ssl=false – включення шифрування з'єднання на основі сертифікатів Puppet PKI

клас cfpuppetserver::puppetserver

autosign = false - НЕ ВАРТО використовувати в бойовому середовищі, хіба що в DMZ. Існує виключно для автоматизації тестування.
global_hiera_config = "cfpuppetserver/hiera.yaml" - шлях до файлу конфігурації Hiera за замовчуванням за канонами Puppet (перший компонент - назва модуля, решта - шлях під папкою files/ у модулі)

Ви можете допомогти і переказати трохи коштів на розвиток сайту

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

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

Цей розділ показує встановлення та налаштування Puppetу конфігурації клієнт/сервер. Цей простий приклад демонструє, як встановити Apacheз використанням Puppet.

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

Для установки Puppetвведіть у терміналі:

Sudo apt-get install puppetmaster

На клієнтській машині (або машинах) введіть:

Sudo apt-get install puppet

Налаштування

Перш ніж налаштовувати puppet вам можливо захочеться додати запис DNS CNAMEдля puppet.example.com, де example.com– це ваш домен. За замовчуванням клієнти Puppetперевіряють DNS на наявність puppet.example.com як ім'я puppet сервера ( Puppet Master). Додаткові відомості про використання DNS див. у розділі Служба доменних імен.

Якщо ви не маєте на увазі використовувати DNS, ви можете додати записи до файлу /etc/hosts на сервері та клієнті. Наприклад, файл /etc/hosts Puppetсервера додайте:

127.0.0.1 localhost.localdomain localhost puppet 192.168.1.17 meercat02.example.com meercat02

На кожному Puppetклієнту додайте запис для сервера:

192.168.1.16 meercat.example.com meercat puppet

Замініть IP-адреси та доменні іменаз прикладу на ваші актуальні адреси та імена сервера та клієнтів.

Тепер налаштуємо деякі ресурси для apache2. Створіть файл /etc/puppet/manifests/site.pp, Що містить наступне:

Package ( "apache2": ensure => installed ) service ( "apache2": ensure => true, enable => true, require => Package["apache2"] )

Node "meercat02.example.com" (include apache2)

Замініть meercat02.example.comна актуальне ім'я вашого Puppetклієнта.

Фінальним кроком для цього простого Puppetсервер є перезапуск сервісу:

Sudo /etc/init.d/puppetmaster restart

Тепер на Puppetсервер все налаштовано і час налаштувати клієнта.

Спочатку налаштуємо сервіс Puppetагент для запуску. Відредагуйте /etc/default/puppet, замінивши значення STARTна yes:

Sudo /etc/init.d/puppet start

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

Sudo puppetca --sign meercat02.example.com

Перевірте /var/log/syslogбудь-які помилки конфігурації. Якщо все пройшло добре, пакет apache2та його залежності будуть встановлені на Puppetклієнта.

Цей приклад дуже простий і не показує багато можливостей та переваг. Puppet. Для додаткової інформаціїдивіться

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

Централізоване налаштування 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 будуть потрібні 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 => 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

nomad.grinder.com

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

$ sudo puppetca -sign nomad.grinder.com

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

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

Успіхів!