Puppet: различия между версиями

Содержимое удалено Содержимое добавлено
Строка 254:
Модули - это возможность использовать классы и функции в puppet. Модуль - это всего лишь директория с предопреденённой структурой каталогов и файлов. Выглядит структура модуля примерно так:
<code>{имя_модуля}/
files/ - содержит различные файлы
files/
lib/ - содержит плагины, например, особые переменные (facts) или типы ресурсов (может вы создадите свой file_yours тип)
lib/
manifests/ - хранит все манифесты
init.pp - должен быть обязательно
{класс1}.pp
{определяемый_тип}.pp
Строка 263:
{под_класс1}.pp
{под_класс2}.pp
templates/ - содержит используемые шаблоны "*.erb"
templates/
tests/</code>
Обращение в коде puppet к классам будет выглядеть как:
Строка 269:
имя_модуля::класс1 { ... }
имя_модуля::класс1::под_класс1 { ... }</source>
Для того, чтобы модуль вообще заработал достаточно иметь папку с именем модуля, папку с манифесты и начальный манифест ''init.pp''.<br />
По аналогии выстраиваем под_под_классы и под_под_...под_классы, пока не надоест. <br />
Требуется, чтобы в каждом из файлов "''класс1''" ... "''под_класс1''" был только один класс с соответствующим именем: "''имя_модуля::класс1''" ... "''имя_модуля::класс1::под_класс1''". При этом файл ''init.pp'' должен содержать класс с именем "''имя_модуля''". <br />
Получить доступ к файлам модуля можно, например, по адресу '''puppet:///modules/имя_модуля/'''.
 
The main directory should be named after the module. All of the manifests go in the manifests directory. Each manifest contains only one class (or defined type). There’s a special manifest called init.pp that holds the module’s main class, which should have the same name as the module. That’s your barest-bones module: main folder, manifests folder, init.pp, just like we used in the ntp module above.
 
But if that was all a module was, it’d make more sense to just load your classes from one flat folder. Modules really come into their own with namespacing and grouping of classes.
Manifests, Namespacing, and Autoloading
 
The manifests directory can hold any number of other classes and even folders of classes, and Puppet uses namespacing to find them. Say we have a manifests folder that looks like this:
 
foo/
manifests/
init.pp
bar.pp
bar/
baz.pp
 
The init.pp file should contain class foo { ... }, bar.pp should contain class foo::bar { ... }, and baz.pp should contain class foo::bar::baz { ... }.
 
This can be a little disorienting at first, but I promise you’ll get used to it. Basically, init.pp is special, and all of the other classes (each in its own manifest) should be under the main class’s namespace. If you add more levels of directory hierarchy, they get interpreted as more levels of namespace hierarchy. This lets you group related classes together, or split the implementation of a complex resource collection out into conceptually separate bits.
Files
 
Puppet can serve files from modules, and it works identically regardless of whether you’re doing serverless or agent/master Puppet. Everything in the files directory in the ntp module is available under the puppet:///modules/ntp/ URL. Likewise, a test.txt file in the testing module’s files could be retrieved as puppet:///modules/testing/test.txt.
Lib
 
Puppet modules can also serve executable Ruby code from their lib directories, to extend Puppet and Facter. (Remember how I mentioned extending Facter with custom facts? This is where they live.) It’ll be a while before we cover any of that.