В Puppet модуль может быть определен как набор ресурсов, классов, файлов, определений и шаблонов. Puppet поддерживает простое перераспределение модулей, что очень полезно при модульности кода, поскольку можно написать указанный универсальный модуль и использовать его несколько раз с минимальными изменениями кода. Например, это включит конфигурацию сайта по умолчанию в / etc / puppet, а модули, поставляемые собственно Puppet, находятся в / etc / share / puppet.
Конфигурация модуля
В любом модуле Puppet у нас есть два раздела, которые помогают определить структуру кода и управлять деноминациями.
-
Путь поиска модулей настраивается с использованием разделенного двоеточиями списка каталогов в puppetmasterd или masterd , последнем разделе главного файла конфигурации Puppet с параметром modulepath .
Путь поиска модулей настраивается с использованием разделенного двоеточиями списка каталогов в puppetmasterd или masterd , последнем разделе главного файла конфигурации Puppet с параметром modulepath .
[puppetmasterd] ... modulepath = /var/lib/puppet/modules:/data/puppet/modules
-
Настройки контроля доступа для модулей файлового сервера в fileserver.conf, конфигурация пути для этого модуля всегда игнорируется, и при указании пути будет выдано предупреждение.
Путь поиска можно добавить во время выполнения, установив переменную среды PUPPETLAB, которая также должна быть разделенным двоеточиями списком переменных.
Путь поиска можно добавить во время выполнения, установив переменную среды PUPPETLAB, которая также должна быть разделенным двоеточиями списком переменных.
Настройки контроля доступа для модулей файлового сервера в fileserver.conf, конфигурация пути для этого модуля всегда игнорируется, и при указании пути будет выдано предупреждение.
Модули Источник
Puppet поддерживает другое место для хранения модулей. Любой модуль может храниться в другой файловой системе любого конкретного компьютера. Однако все пути, в которых хранятся модули, должны быть указаны в переменной конфигурации, известной как modulepath, которая в общем случае является переменной пути, где Puppet сканирует все каталоги модулей и загружает их при загрузке.
Разумный путь по умолчанию может быть настроен как —
/etc/puppet/modules:/usr/share/puppet:/var/lib/modules.
В качестве альтернативы каталог / etc / puppet может быть установлен как специальный анонимный модуль, который всегда ищется первым.
Наименование модуля
Puppet следует тем же стандартам именования конкретного модуля, где имя модуля должно быть обычными словами, соответствующими [- \\ w +] (буква, слово, число, подчеркивание и тире) и не содержащими разделитель пространства имен:: или /. Хотя это может быть разрешено в отношении иерархий модулей, для новых модулей оно не может быть вложенным.
Модуль Внутренняя Организация
Когда пользователь создает новый модуль в Puppet, он следует той же структуре и содержит манифест, распределенный файл, плагины и шаблоны, расположенные в определенной структуре каталогов, как показано в следующем коде.
MODULE_PATH/ downcased_module_name/ files/ manifests/ init.pp lib/ puppet/ parser/ functions provider/ type/ facter/ templates/ README
Всякий раз, когда модуль создается, он содержит файл манифеста init.pp в указанном месте исправления в каталоге манифестов. Этот файл манифеста является файлом по умолчанию, который выполняется первым в любом конкретном модуле и содержит коллекцию всех классов, связанных с этим конкретным модулем. Дополнительный файл .pp можно добавить прямо в папку манифестов. Если мы добавляем дополнительные файлы .pp, они должны быть названы в честь класса.
Одной из ключевых особенностей, достигаемых с помощью модулей, является совместное использование кода. Модуль по своей природе должен быть автономным, что означает, что нужно иметь возможность включать любой модуль из любого места и помещать его в путь к модулю, который загружается при загрузке Puppet. С помощью модулей можно получить модульность в кодировании инфраструктуры Puppet.
пример
Рассмотрим модуль autofs, который устанавливает фиксированную карту auto.homes и генерирует auto.master из шаблонов.
class autofs { package { autofs: ensure => latest } service { autofs: ensure => running } file { "/etc/auto.homes": source => "puppet://$servername/modules/autofs/auto.homes" } file { "/etc/auto.master": content => template("autofs/auto.master.erb") } }
Файловая система будет иметь следующие файлы.
MODULE_PATH/ autofs/ manifests/ init.pp files/ auto.homes templates/ auto.master.erb
Модуль Поиск
Puppet следует предварительно определенной структуре, в которой он содержит несколько каталогов и подкаталогов в определенной структуре. Эти каталоги содержат файлы различного типа, которые требуются модулю для выполнения определенных действий. Небольшое закулисное волшебство гарантирует, что правильный файл связан с правильным контекстом. Все поиски модуля находятся в модульном пути, разделенном двоеточиями списке каталогов.
Для ссылок на файл на файловом сервере используется аналогичная ссылка, так что ссылка на puppet: //$servername/modules/autofs/auto.homes преобразуется в файл autofs / files / auto.homes в пути модуля.
Чтобы сделать модуль пригодным для использования как с клиентом командной строки, так и с мастером марионеток, можно использовать URL-адрес пути from puppet: ///. т.е. URL без явного имени сервера. Такие URL немного различаются в Puppet и puppetd . Puppet ищет бессерверный URL в локальной файловой системе.
Поиск в файлах шаблонов осуществляется аналогично манифесту и файлам: упоминание шаблона («autofs / auto.master.erb») заставит puppetmaster сначала найти файл в $ templatedir / autofs / auto.master.erb, а затем autofs / templates / auto.master.erb в пути к модулю. С Puppet-версиями всего под Puppet он доступен для использования. Это называется автоматической загрузкой модуля. Puppet попытается автоматически загрузить классы и определения из модуля.