Различия между местным «кукловодом» и «марионеточным агентом» для кукловода

Мы находимся в процессе перехода от монолитного репозитория марионеток, который содержит всю конфигурацию. Это одно репо содержит вещи, которые никогда не должны быть на каждом узле, поэтому система на основе марионеточного мастера кажется лучшим способом надлежащим образом разделить вещи.

Проблема в том, что одно и то же репо отлично работает при копировании на локальные узлы и puppet apply /etc/puppet/manifests/site.pp беги по нему. Наши установки выполняются очень чисто.

Когда я помещаю репозиторий марионеток в марионеточный мастер и подписываю агента, кажется, что он не делает ничего, кроме сообщения своего локального каталога мастеру марионеток.

Некоторое время там, и я не мог воспроизвести конфигурацию, которая сделала это, один из наших самодельных модулей выдавал ошибку, предполагающую, что он пытался скопировать файл с локального компьютера. modules каталог, а не кукловод, как следует.

Это говорит о том, что могут быть различия в синтаксисе модуля и манифеста при создании репо для локального использования и через puppetmaster.

Если есть какие-либо различия, то каковы они или каковы основные моменты, вызывающие сбои в преобразовании?

В /etc/puppet/puppet.conf файл на мастере:

[main]
logdir=/var/log/puppet
vardir=/var/lib/puppet
ssldir=/var/lib/puppet/ssl
rundir=/var/run/puppet
factpath=$vardir/lib/facter
pluginsync=true

# Set up Environments
## Each environment has a dedicated 'modules' directory under /environments/ from
## which puppet will preferentially pull. Otherwise, it'll use the top level  
## 'modules' directory. That is where common code goes.
[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules
  ssl_client_header= SSL_CLIENT_S_DN
  ssl_client_verify_header = SSL_CLIENT_VERIFY
[production]
  manifest=$confdir/manifests/site_prod.pp
[integration]
  manifest=$confdir/manifests/site_integ.pp
[development]
  manifest=$confdir/manifests/site_dev.pp
[operations]
  manifest=$confdir/manifests/site_ops.pp

На данный момент site_prod.pp file и тому подобное являются символическими ссылками на site.pp.

Классы, определенные в файле site.pp, зависят от имени хоста. Как я уже упоминал, при запуске через puppet apply все работает нормально. В худшем случае я могу сделать то, что мне нужно, с помощью временного монтирования NFS, но я бы не стал этого делать.

site.pp Для вашего удовольствия:

filebucket { "main": server => $server; }
File { backup => "main" }

Exec { path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" }

import "stages.pp"
import "int_setup.pp"
import "nodes.pp"

Импортированные файлы .pp находятся в том же каталоге, что и site.pp. nodes.pp там мясо, но также содержит секрет-соус. Некоторые отрывки:

node /clunod\-wk\d+\.sub\.example\.local/ {

  class { "int_setup": stage => "setup"; }
  include base
  include curl
  include custommodule
  [...]
}

Что может и соответствует узлам с именем clunod-wk01234.sub.example.local при запуске через марионетку применить.

[int-setup.pp]

class int_setup {
  file { "/var/cluebat":
    ensure => directory,
    mode => "755",
    owner => "root",
    group => "root";
  }

  group{"puppet":
    ensure => present
  }

}