У меня есть сервер pmaster-dev это марионеточный клиент (его хозяин pmaster). Сервер pmaster-dev сам выступает в роли кукловода для нескольких клиентов.
когда pmaster-dev проверяется с pmaster он кэширует свои факты в локальный файл базы данных sqlite3 /var/lib/puppet/state/clientconfigs.sqlite. При каждом последующем заселении pmaster-dev никогда не обновляет этот локальный кеш. Таким образом, его факты всегда устарели. Другие клиенты pmaster (включая pmaster сам) никогда не кешировать.
Как нам сказать ему обновить кеш или отключить кеширование фактов? Почему это кешируется, в то время как другие клиенты pmaster не?
Мы запускаем 2.7.18 в сжатой системе Debian.
Здесь /etc/puppet/puppet.conf файл для pmaster-dev:
[agent]
server = pmaster.example.org
environment = master
configtimeout = 300
logdir = /var/log/puppet
vardir = /var/lib/puppet
ssldir = /etc/puppet/ssl
rundir = /var/run/puppet
ca_server = puppetca.example.org
ca_port = 8141
graph = true
report = true
pluginsync = true
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
diff_args = '-u'
show_diff = true
[master]
certname = pmaster-dev.example.org
syslogfacility = local2
logdir = /var/log/puppet
vardir = /var/lib/puppet
rundir = /var/run/puppet
ssldir = /srv/puppetmaster/ssl
reports = tagmail,lastcheck,logcache
manifest = /srv/puppet/$environment/manifests/site.pp
graph = true
modulepath = /srv/puppet/$environment/modules:/srv/puppet/$environment/services:/srv/puppet/$environment/clients
cacrl = /srv/puppetmaster/ssl/crl.pem
ca = false
manifestdir = /srv/puppet/$environment/manifests
queue_source = stomp://pupqueue-dev.example.org:61613/
async_storeconfigs = true
storeconfigs = false
dbadapter = mysql
dbuser = puppet
dbpassword = secret
dbserver = pupqueue-dev.example.org
dbname = puppet
ssl_client_header = SSL_CLIENT_S_DN
ssl_client_verify_header = SSL_CLIENT_VERIFY
Покопавшись в исходных файлах Puppet Ruby, я отследил проблему до ошибки, связанной с объединением разделов файла конфигурации Puppet. Все сводится к слову «мастер»
Резюме: Мастера Puppet, выступая в качестве клиента Puppet и в «основной» среде, вызывают проблемы с анализом файла конфигурации.
подробности: Когда марионеточный агент запускает одну из вещей, которые он выполняет, это анализирует файл конфигурации (обычно /etc/puppet/puppet.conf).
Файл конфигурации разбит на разделы, например, «[основной]», «[агент]», «[мастер]» и т. Д. Каждый из этих разделов сохраняется отдельно в хэше, сгенерированном в результате анализа файла конфигурации. В моем случае, pmaster-dev имеет следующие разделы: «память», «мастер», «cli» и «агент».
Также могут быть разделы для каждой среды. Например, если существует среда под названием «stable201301», тогда в файле конфигурации может быть раздел под названием «[stable201301]».
Для каждого из вышеперечисленных разделов (называемых в коде «источниками») вы проверяете все параметры, связанные с «хуками». Если в этом разделе определена настройка с ловушкой, вы вызываете эту настройку ловушкой. Некоторые настройки, которые имеют хуки, включают catalog_format, node_name_fact и storeconfigs.
Одна из наиболее интересных настроек - "async_storeconfigs", у которой есть ловушка, устанавливающая класс кеширования.
Напомним, что разделы также могут включать по одному для каждой среды. ПРОБЛЕМА: Что, если мастер Puppet (когда он действует как клиент Puppet) находится в «основной» среде?
Обычно роль раздела «[master]» - это настройки для мастера Puppet. Но если хозяин Марионеток сам использует среду «хозяина», возникает конфликт. В частности, параметр async_storeconfigs из [master] загружается из файла конфигурации. Поскольку мастер Puppet (как клиент Puppet) находится в «основной» среде, этот параметр приводит к установке класса кеша, и поэтому, когда puppet agent --test При запуске марионеточный клиент ищет кэшированные факты.
Решение(?): Вы можете убедиться, что мастер Puppet никогда не использовал «главную» среду. Лучшим решением было бы запретить парсеру конфигурации клиента просматривать раздел «[master]» (поскольку это применимо только к мастерам Puppet). Еще лучшим решением было бы разделить файлы конфигурации клиента и мастера.
Похоже, вы не понимаете, что clientconfigs.sqlite на самом деле есть. Этот файл является частью Сохраненная конфигурация механизм марионетки. Это файл, поддерживаемый Хозяином Марионеток, а не клиентами.
Его создание контролируется storeconfigs, async_storeconfigs и db* параметры в [master] раздел puppet.conf. По умолчанию (когда нет db* заданы параметры) - использовать адаптер SQLite.
Судя по вставленной вами конфигурации, похоже, что вы настроили мастер для хранения конфигурации в базе данных MySQL через брокера Stomp. Так кажется, что не обновлять базу данных SQLite намеренно?
Почему этот файл базы данных был создан с самого начала - хороший вопрос. Моя гипотеза заключается в том, что Puppet Master запустился с неполной конфигурацией во время начальной настройки сервера.