Содержание


Администрирование виртуальных серверов с использованием Puppet

Часть 1. Установка и настройка Puppet

Comments

Серия контента:

Этот контент является частью # из серии # статей: Администрирование виртуальных серверов с использованием Puppet

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Администрирование виртуальных серверов с использованием Puppet

Следите за выходом новых статей этой серии.

В процессе организации серверной среды с использованием средств виртуализации или облачных сервисов быстро растет количество отдельных серверов. Каждый раз при создании нового сервера возникает необходимость установки и конфигурации соответствующего программного обеспечения. Более того, синхронизация серверных конфигураций требует дополнительных усилий, таких, например, как написание cценариев на языке командной оболочки shell.

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

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

История Puppet

Проект Puppet является разработкой компании Puppet Labs и распространяется как ПО с открытым исходным кодом (Open Source Software). Программа имеет гибкую модульную структуру: в настоящее время для Puppet написано уже более 200 модулей расширения.

Puppet поддерживается не только компанией-разработчиком, но и весьма активным сообществом пользователей.

Установка и подготовка Puppet к работе

Функционирование Puppet организовано по схеме "клиент-сервер". Каждый клиент периодически устанавливает связь с главным управляющим сервером (или несколькими такими серверами) и выполняет синхронизацию конфигурации. По умолчанию такие сеансы связи происходят каждые полчаса. Поэтому для обеспечения нормальной работы Puppet потребуются как минимум два установленных сервера: один будет выполнять функции главного управляющего сервера (master server), а другой (или другие) выступать в роли подчинённых ему серверов, то есть, в данном контексте можно назвать их серверами-"клиентами".

Для того, чтобы установить Puppet на хосте, который будет управлять другими серверами в качестве главного управляющего сервера, необходимо выполнить команды, показанные в листинге 1. Следует отметить, что эти команды выполняются от имени суперпользователя root.

Листинг 1. Установка пакета puppet-server на главный управляющий сервер
# yum -y install puppet-server
# chkconfig puppetmaster on
# service puppetmaster start

Пакеты для подчинённых серверов устанавливаются на клиентских хостах, как показано в листинге 2 (команды выполняются также от имени суперпользователя root).

Листинг 2. Установка пакета puppet на хосте-клиенте
# yum -y install puppet
# chkconfig puppet on
# service puppet start

Если хост главного управляющего сервера защищён сетевым экраном, а хосты-клиенты расположены "снаружи" относительно этого сетевого экрана (например, компьютеры в локальной сети), то на главном сервере необходимо открыть TCP-порт с номером 8140 и, по возможности, сделать его доступным только для клиентских хостов. Если все операции будут выполняться на одном компьютере (localhost), то никаких манипуляций с сетевым экраном не требуется.

Основы использования Puppet

С точки зрения Puppet все конфигурации определяются и описываются как ресурсы (resources), которые можно назвать основными структурными компонентами управляющей среды. Ресурсами могут быть файлы, сервисы (server services), программные пакеты (software packages) и т.д. Более того, ресурсом может быть даже одиночный вызов команды оболочки shell. Например, описываемый в листинге 3 ресурс типа file представляет известный всем файл /etc/passwd, владельцем которого является root.

Листинг 3. Описание ресурса - файла /etc/passwd
file { '/etc/passwd':
    owner => root,
    mode  => 644,
}

Ресурсы можно группировать по определённым характеристикам: так, например, любой файл имеет владельца и расположен по конкретному адресу (path) в файловой системе, у каждого пользователя есть регистрационное имя (login), личный идентификатор (UID) и идентификатор группы (GID). В соответствии с этими характеристиками формируются типы ресурсов. Кроме того, самые важные характеристики типа ресурса в общем смысле одинаковы для любых операционных систем, независимо от незначительных деталей реализации. То есть описание ресурса вполне можно абстрагировать от его реализации в той или иной операционной системе.

На основе вышеописанных предпосылок сформирован уровень абстракции ресурсов (resource abstraction layer - RAL) программы Puppet. RAL разделяет ресурсы на типы (types), являющиеся моделями высокого уровня, и провайдеры (providers), которые представляют более низкий уровень, то есть реализации ресурсов, зависящие от конкретной платформы. Такая организация RAL позволяет составлять описания ресурсов способом, применимым практически на любой системе.

Цикл синхронизации RAL

Puppet использует RAL как для чтения, так и для изменения состояния ресурсов системы. Являясь декларативной системой контроля и управления, Puppet начинает рабочий цикл с получения информации о том, в каком состоянии должен находиться тот или иной ресурс. При синхронизации ресурса используется RAL для запроса текущего состояния, сравнения его с требуемым и внесения всех необходимых изменений при обнаружении каких-либо различий.

Структура описания ресурса

Как было сказано выше, в Puppet каждый ресурс является экземпляром некоторого типа (resource type), с указания которого начинается собственно описание. Ресурс идентифицируется именем (title), которое записывается в одиночных кавычках после открывающей фигурной скобки и сопровождается символом двоеточия. Далее с новой строки определяются атрибуты типа (attributes), причём некоторые атрибуты являются общими для всех типов, другие же присущи только данному конкретному типу ресурса. Каждый атрибут имеет значение (value), таким образом, записи атрибутов с соответствующими значениями имеют общую форму attribute => value.

Общее представление о синтаксисе языка описания ресурсов Puppet можно получить из листинга 4, в котором показан самый простой случай - описание ресурса типа "пользователь" (user).

Листинг 4. Синтаксис языка описания ресурсов Puppet на примере пользователя
user { 'alex':
  ensure     => present,
  uid        => '501',
  gid        => 'admin',
  shell      => '/bin/bash',
  home       => '/home/alex',
  managehome => true,
}

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

Следующая конфигурация, демонстрируемая в листинге 5, позволяет установить пакет openssh-server, разрешить использование сервиса sshd по умолчанию и выполнить проверку, чтобы убедиться в том, что этот сервис действительно активизирован и работает.

Листинг 5. Описание ресурса - сервиса sshd (установка, запуск, проверка)
package { 'openssh-server':
    ensure => installed,
}

service { 'sshd':
    enable => true,
    ensure => running,
    require => Package['openssh-server'],
}

Теперь необходимо применить описанные выше конфигурации к соответствующим серверам. В пакет Puppet по умолчанию включён специальный файл конфигурирования ресурсов site.pp, который располагается в каталоге /etc/puppet/manifests. Если параметры конфигурации ресурсов не очень сложны, то их можно добавить в этот файл вручную: например, содержимое вышеприведённых листингов 3 и 4.

После того, как все требуемые программы установлены и активированы, а файлы конфигурации сформированы, обязательно нужно зарегистрировать все подчинённые серверы (клиенты) на главном управляющем сервере и подтвердить достоверность регистрации (sign), то есть пройти своеобразную сертификацию. На подчинённых серверах регистрация выполняется следующей командой (также требуются права суперпользователя root):

puppetd --test --waitforcert 30 --server MASTER_SERVER_ADDRESS

Вместо MASTER_SERVER_ADDRESS следует указать реальный адрес главного управляющего сервера.

После регистрации всех необходимых клиентов на главном управляющем сервере выполняются команды, показанные в листинге 6.

Листинг 6. Сертификация зарегистрированных клиентов на главном управляющем сервере
puppetca --list
# выводится список адресов зарегистрированных клиентов
puppetca --sign CLIENT_SERVER_ADDRESS
# вместо CLIENT_SERVER_ADDRESS следует указать реальный адрес клиента
# команда повторяется для адреса каждого клиента

После завершения операций регистрации и сертификации Puppet автоматически применит описанные выше конфигурации ресурсов на зарегистрированных клиентах.

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

[main]
  # здесь также записывается реальный адрес сервера
  server = MASTER_SERVER_ADDRESS

Теперь Puppet полностью настроен и работает. Автоматическая синхронизация конфигураций ресурсов подчинённых серверов будет производиться каждые 30 минут. Пронаблюдать процесс можно выполнив команду:

tail -f /var/log/messages

Заключение

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux, Open source
ArticleID=824024
ArticleTitle=Администрирование виртуальных серверов с использованием Puppet: Часть 1. Установка и настройка Puppet
publish-date=07032012