Puppet：Could не находят узел по умолчанию или по имени с узлом test2
ganeti от google http://code.google.com/p/ganeti/
Хорошая часть программного обеспечения для управления кластерами KVM
Я бы рекомендовал перейти от определений узлов манифеста к Hiera. Вам нужно будет немного настроить вещи, чтобы отказаться от вызова этого определенного типа непосредственно из вашего узла, но похоже, что он все равно не используется несколько раз в каталоге, поэтому преобразование в класс должно работать нормально.
Итак, с hiera.yaml как это ..
---
:backends:
- yaml
:hierarchy:
- '%{::clientcert}'
- 'os-%{::osfamily}'
- common
:yaml:
:datadir: /etc/puppet/hieradata
И site.pp только с:
hiera_include(classes)
.. ваши узлы будут считываться из файлов YAML в / etc / puppet / hieradata . Например, мы скажем, что вы хотите tmp :: params на каждом узле, сообщающем Puppet, но, возможно, вы хотите tmp :: gtp только на определенных узлах. И вы хотите централизованно определить параметр версия , но оставьте другие параметры для каждого узла. Итак, мы Я помещаю tmp :: params и версию параметр /etc/puppet/hieradata/common.yaml :
classes:
- tmp::params
tmp::gtp::version: 6.0.0.0
Тогда у вас будет файл для каждый узел.
/etc/puppet/hieradata/test1.yaml :
classes:
- tmp::gtp
tmp::gtp::name : node1
tmp::gtp::ip : 168.1.193.97
tmp::gtp::port : 1255
/etc/puppet/hieradata/test2.yaml :
classes:
- tmp::gtp
tmp::gtp::name : node2
tmp::gtp::ip : 168.1.193.98
tmp::gtp::port : 1255
И да, он улавливает изменения в файлы Hiera без перезапуска службы. Кажется, что вам нужно?
Правка : чтобы использовать Hiera для настройки нескольких экземпляров определенного типа, вам нужно сделать что-то вроде этого:
/ etc / puppet / hieradata / test1. yaml :
classes:
- gtpsetup
gtp_instances:
- node1_instance1
- node1_instance2
gtp_instanceconfig:
node1_instance1:
ip : 168.1.193.97
port : 1255
version : 5.3.2.1
node1_instance2:
ip : 168.1.193.97
port : 1268
version : 6.0.0.0
/etc/puppet/modules/gtpsetup/manifests/init.pp :
class gtpsetup {
gtp_instances = hiera('gtp_instances')
gtp_instanceconfig = hiera('gtp_instanceconfig')
define gtp_instance {
# this is using your existing defined type, but you can just move the stuff it's doing to here.
tmp::gtp { $title:
name => $title,
version => gtp_instanceconfig[$title]['version'],
ip => gtp_instanceconfig[$title]['ip'],
port => gtp_instanceconfig[$title]['port'],
}
}
gtp_instance { $gtp_instances: }
}
Шейн дал отличный ответ с лучшим способом решения вашей проблемы, но я хочу сказать: «Итак, я думаю, что Puppet не будет динамически импортировать новый файл pp после того, как мастер марионетки был началось "
Это отчасти правда. Когда Puppet запускается, он читает все свои файлы конфигурации, а затем начинает отслеживать их изменения. Когда содержимое одного из этих файлов обновляется, Puppet повторно прочитает файл. Puppet также имеет набор стандартных расположений для файлов, с которыми он будет обращаться в случае необходимости, поэтому, если вы добавите новый класс foo :: bar к узлу в файле, который он отслеживает, он будет искать файл с именем foo / manifest / bar.pp (или foo / manifest / bar.rb ) в его $ modulepath , даже если это не так. Мне этот файл нужен при запуске.
Важно отметить, что директивы import оцениваются только тогда, когда анализируется файл, в котором они находятся. При запуске мастера марионеток он прочитал свой файл site.pp , увидел инструкцию import и обнаружил только nodes / test1.pp , так что единственные файлы он отслеживал изменения: site.pp и nodes / test1.pp . Он никогда не видел nodes / test2.pp .
Одним из способов решения этой проблемы было бы просто прикоснуться к site.pp после добавления нового файла в узлы каталог. Это заставит хозяина марионетки повторно прочитать site.pp , что заставит его повторно обработать оператор import и затем увидеть новый файл.
В конечном итоге, хотя ты Лучше следовать рекомендациям Шейна и отделить данные от кода. Если вы можете структурировать свои определения так, чтобы не требовалось оператора import , вам будет лучше; он все еще используется, но во многих отношениях import является пережитком более старых практик Puppet, которые больше не актуальны.