architecture.tex

\chapter{Архитектура Puppet}

\section{Компоненты системы}

Чаще всего развернутая система Puppet представляет из себя один управляющий сервер puppetmaster и много управляемых систем, которые называют puppets или nodes.

Конфигурация всех систем хранится на управляющем сервере в виде текстовых файлов, которые называются manifests или recipes. Они могут быть организованы при помощи специальной структуры каталогов в модули. Обычно каждый модуль отвечает за настройку какого-то одного компонента или сервиса.
	
Управляемые системы подключаются к управляющей, которая собирает все элементы конфигурации в каталог, который передаётся подключившейся системе. Получив каталог, управляемая система начинает сравнивать своё текущее состояние с состоянием, описанным в каталоге, и принимает решения о том, какие действия нужно выполнить для приведения текущего состояния к переданному управляющей системой. При выполнении каталога учитывается, что некоторые действия необходимо выполнить раньше или позже других, что позволяет администратору не продумывать самому точный порядок выполнения задач, а только указать зависимости, если они необходимы.  

Архитектура Puppet имеет следующие особенности:

\begin{description}
\item[Идемпотентность] Многократное применение одного и того же каталога никак не изменяет состояния системы и приводит к тому же результату, что и однократное применение. При внесении изменений в каталог произойдет их применение и привод текущего состояния системы к изменённому.
\item[Декларативность] Системному администратору требуется описать не порядок действий, который нужно выполнить для решения поставленной задачи, а то, каким должна быть система.
\item[Отказоустойчивость] В случае невозможность связаться с управляющим сервером управляемая система воспользуется последним полученным от сервера каталогом и не предпримет никаких действий. В случае недоступности управляемой системы она получит произошедшие за время её отсутствия изменения позже, когда станет доступной, без вмешательства администратора.
\item[Модульность] Конфигурация Puppet обычно собирается из набора модулей, которые могут быть использованы многими системами с разными конфигурациями и может легко расширятся дополнительными модулями.
\end{description}

На управляемых системах должна быть установлена клиентская часть Puppet — агент, который выполняет как получение данных от сервера, так и применение изменений. Он может запускаться следующими способами:

\begin{enumerate}
\item Демон. Программа будет работать постоянно, обращаясь к серверу за новым каталогом через определённый период времени (по умолчанию 30 минут) и сравнивая его с текущим состоянием.
\item Cron. Программа может запускаться при помощи cron получать новый каталог, выполнять его и завершать работу.
\item Агент может запускаться вручную администратором после внесения им изменений в конфигурацию систем на управляющем сервере.
\item Агент может быть запущен при помощи другой системы управления или автоматизации.
\end{enumerate}

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

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

\section{Схема работы Puppet}

При описании конфигурации управляемых систем вся задача разбивается на небольшие части, с которыми можно работать отдельно. Они называются \emph{ресурсы}. Ресурсом может быть например файл, пакет или пользователь. Каждый ресурс должен быть уникален, например не может быть двух файлов, находящихся в одном месте, или двух пользователей с одинаковым именем.

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

Ресурсы могут объединяться в группы ресурсов, которые вместе относятся к настройке одого компонента или по другому признаку. Такие группы бывают трёх видов: \emph{классы}, \emph{параметрические классы} и \emph{определения}.

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

Конфигурация системы часто может зависеть не только от того, какую функцию она выполняет, но и от её свойств. Например на разных операционных системах может потребоваться установить пакеты с разными названиями, или принять решение, основываясь на объёме оперативной памяти, или вписать в конфигурационный файл IP этой системы. При подключении управляемая система передаёт управляющей информацию о себе, чтобы она могла её использовать при составлении конфигурации. Эта информация называется \emph{факты}. Они представляют собой набор переменных и их значений, которые собираются перед отправкой специальной программой - \emph{facter}.

\tikzstyle{block} = [
rectangle, draw, fill=blue!20, text width=6em,
text centered, rounded corners, minimum height=4em
]
\tikzstyle{line} = [draw, thick, -latex']
\tikzstyle{cloud} = [
draw, ellipse, fill=red!20,
node distance=4cm, minimum height=2em
]

\begin{figure}[!h]
\centering
\begin{tikzpicture}[node distance = 4cm, auto]
\node [block] (master) {Сборка каталога};
\node [cloud, above left of=master] (resources) {Ресурсы};
\node [cloud, left of=master] (parameters) {Параметры};
\node [cloud, above right of=master] (data) {Внешние данные};
\node [cloud, above of=master] (groups) {Группы ресурсов};
\node [cloud, right of=master] (facts) {Факты};
\node [block, below of=master] (catalog) {Применение каталога};
\node [block, right of=catalog] (getfacts) {Получение фактов};
\node [block, below right of=catalog] (from) {Начальное состояние};
\node [block, left of=catalog] (to) {Ожидаемое состояние}; 

\path [line] (resources) -- (master);
\path [line] (groups) -- (master);
\path [line] (facts) -- (master);
\path [line] (master) -- (catalog);
\path [line] (getfacts) -- (facts);
\path [line] (parameters) -- (master);
\path [line] (data) -- (master);
\path [line] (from) -- (getfacts);
\path [line] (from) -- (catalog);
\path [line] (catalog) -- (to);
\end{tikzpicture}
\caption{Cхема работы Puppet}
\label{fig:puppet_scheme}
\end{figure}

На рисунке \ref{fig:puppet_scheme} изображена схема работы Puppet в режима клиен-сервера. Рассмотрим порядок действий.
\begin{enumerate}
\item Сначала на управляемой машине при помощи facter собирается набор фактов о свойствах системы.
\item Агент на управляемой системе подключается к управляющей, используя свой SSL сертификат для авторизации, передаёт собранные факты и ожидает получения каталога.
\item Управляющая система получает имя подключившейся системы и ее набор фактов, после чего начинает собирать для неё каталог.
\item При сборке каталога учитывается какие ресурсы и их группы были назначены этой системе, а также могут использоваться заданные параметры, факты и другие дополнительные источники данных.
\item Собранный каталог содержит список ресурсов и параметров, которые они должны иметь. Каталог передаётся ожидающему его агенту.
\item При исполнении каталога агентом запрашивается состояние всех описанных в нем ресурсов. Если текущее состояние ресурса отличается от заданного, то производится его изменение. Если состояние ресурса не отличается от заданного, то он остается неизменным.
\item После исполнения каталога агент отправляет на управляющий сервер отчёт о том, какие ресурсы были изменены и, возможно, о произошедших ошибках.
\end{enumerate}

Именно благодаря атомарной обработке каждого ресурса агентом и внесении изменений только в случае несоответствия состояния ресурса требуемому достигается идемпотентность. Последующие циклы обработки не внесут изменений если первый цикл был успешен и привел систему к требуемому состоянию.

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