Я храню все свои узлы в одном файле site.pp, но по мере того, как я добавляю все больше и больше узлов, их очень сложно поддерживать.
Директива import выглядит очень многообещающе, но, насколько я понимаю, необходимо перезапускать puppermaster каждый раз, когда что-то меняется. Для меня это неприемлемо.
Есть ли другой способ сделать это? Вместо использования больших комментариев для разделения узлов / групп. Сейчас я использую только rdoc.
Буду рад любым предложениям :-)
Моя текущая структура каталогов марионетки выглядит так:
Я развертываю конфигурацию марионетки с помощью git / rsync, чтобы переопределить только измененные файлы.
у меня есть site.pp это выглядит так:
import "nodes/*.pp"
и иметь nodes/ каталог в manifests/
Итак, у меня есть набор узлов в "workstations.pp" "webservers.pp" и так далее..
Определите свои узлы вне манифестов. Я бы порекомендовал преемника extlookup, Hiera, но на самом деле любого классификатора внешнего узла будет достаточно, чтобы переместить данные вашего узла из манифестов.
В наши дни это рекомендуемый способ обработки определений узлов - из документы:
Большинству пользователей в большинстве ситуаций следует использовать объявления, похожие на include, и устанавливать значения параметров во внешних данных. Однако совместимость с более ранними версиями Puppet может потребовать компромиссов.
Hiera включен в Puppet 3.0 - в более старых версиях его нужно устанавливать отдельно. Чтобы настроить Hiera для обработки определений ваших узлов, вам нужно сделать что-то в этом роде:
site.pp (все):
hiera_include(classes)
hiera.yaml:
:backends:
- yaml
:hierarchy:
- %{clientcert}
- os-%{osfamily}
- common
:yaml:
:datadir: /etc/puppet/hieradata
# A good alternative if you want different node data based on environments:
#:datadir: /etc/puppet/environments/%{environment}/hieradata
:puppet:
:datasource: data
Теперь Puppet заглянет в /etc/puppet/hieradata для извлечения данных из ваших узлов. Скажите, что у вас есть ntp класс, который вы хотите, и apache класс, который вам нужен только на одном конкретном узле:
/etc/puppet/hieradata/common.yaml:
classes:
- ntp
/etc/puppet/hieradata/nodename.example.com.yaml:
classes:
- apache
Этот массив является агрегатным - nodename.example.com узел получит как ntp класс из общего файла и apache класс из собственного файла.
Hiera также обрабатывает параметры вашего класса за вас. Скажите, что у вас есть apache класс, ожидающий port параметр:
class apache ( $port ) {
...
Вы также можете установить это в своих файлах данных Hiera. Если вы хотите по умолчанию использовать порт 80 ..
/etc/puppet/hieradata/common.yaml:
classes:
- ntp
apache::port: 80
Но вы хотите отменить это для nodename.example.com, установив его на 8080:
/etc/puppet/hieradata/nodename.example.com.yaml:
classes:
- apache
apache::port: 8080
Или вы можете использовать это os-%{osfamily} из hiera.yaml файл для настроек на основе фактов о данном узле - osfamily факт в данном случае.
/etc/puppet/hieradata/os-debian.yaml:
apache::package_name: apache2
/etc/puppet/hieradata/os-redhat.yaml:
apache::package_name: httpd
(обратите внимание, что поведение поиска параметров немного отличается, если вы используете версию старше 3.0, подробности здесь)
Таким образом, у вас есть возможность установить включенные классы и настройки параметров / переменных в разных областях (все узлы, некоторые узлы на основе факта или один конкретный узел) в разных файлах.