Não foi possível encontrar a classe, e ainda está lá

Ao fazer uma puppet agentchamada de uma nova imagem, estou recebendo um err: Could not find class custommoderro. O módulo em si é o /etc/puppet/modules/custommodmesmo que todos os outros módulos que estamos chamando, mas este é obstinante.

[site.pp]

node /clunod-wk\d+\.sub\.example\.local/ {
      include base
      include curl
      include custommod
      class{ "custommod::apps": frontend => "false}
      [...]
}

Quando o puppetmaster é executado com saída de depuração, ele encontra claramente as informações para base e curl:

debug: importing '/etc/puppet/modules/base/manifests/init.pp' in environment production
debug: Automatically imported base from base into production
debug: importing '/etc/puppet/modules/curl/manifests/init.pp' in environment production
debug: Automatically imported curl from curl into production
err: Could not find class custommod for clunod-wk0130.sub.example.local at /etc/puppet/manifests/site.pp:84 on node clunod-wk0130.sub.example.local

A linha 84 é include custommod

Um diretório abreviado e estrutura de arquivo:

/etc/puppet
   |- manifests
   |     |- site.pp
   |
   |- modules
         |- base
         |    |- manifests
         |          |- init.pp
         |
         |- curl
         |    |- manifests
         |          |- init.pp
         |   
         |- custommod
              |- files 
              |     |- apps
              |         |- [...]
              |
              |- manifests
                    |- init.pp
                    |- apps.pp

Eu verifiquei a ortografia:}

O conteúdo do init.ppdiretório custommod é completamente normal:

class custommod {
}

A intenção é criar uma classe vazia para o arquivo apps.pp, que é onde está a carne.

class custommod::apps {

    [lots of stuff]
}

Só que nunca chega ao arquivo de aplicativos. Se eu comentar include custommod, o erro acima é gerado na class{ "custommod::apps": frontend => "false}linha.

O que estou faltando na minha busca para descobrir como esse erro está sendo gerado? Eu preciso observar que este repositório funciona muito bem se for executado localmente via puppet apply.

Então ... isso é um pouco embaraçoso, mas ...

Ambientes.

Bem ali no meu /etc/puppet.confarquivo é o seguinte:

[master]
  manifest=$confdir/manifests/site.pp
  modulepath=$confdir/environments/$environment/modules:$confdir/modules

Depois de stracetentar descobrir onde estava procurando arquivos, notei algo. Ele estava procurando por custommod under /etc/puppet/environments/production/modulese, como havia um diretório lá (vazio), ele não foi verificado/etc/puppet/modules . Aparentemente, ao importar um módulo, ele verifica a presença do diretório, em vez da presença do arquivo (init.pp).

Remova esse diretório vazio, as coisas começam a funcionar.

Execute o agente fantoche usando um ambiente diferente, as coisas começam a funcionar.

Moral da história:

Os caminhos do ambiente de marionetes não agem como bash $ PATH.

Corri para o mesmo problema, mas tinha uma correção diferente

Se você gerar um módulo fantoche como este:

puppet module generate foo-example_module

Ele criará um módulo nomeado example_modulecom o fooespaço para nome. Todos os manifestos estarão dentro de um diretório chamadofoo-example_module

O nome da classe definida no init.pp precisa ser o mesmo que o nome da pasta.

Correção simples:

mv foo-example_module example_module

Se você executar o puppet-lint, ele avisará com a seguinte mensagem:

ERROR: example_module not in autoload module layout on line 42

Se você estiver usando um Puppetfile com r10k ou librarian-puppet, também poderá ser necessário remover o espaço de nome para que os arquivos sejam colocados sem o prefixo 'foo' no diretório de módulos.

antes:

mod 'foo-example_module',
    :git => git@github.com:foo/example_module'

depois de:

mod 'example_module',
    :git => git@github.com:foo/example_module'

Outro problema que pode acontecer é quando o seu módulo possui um metadata.jsonarquivo inválido .

Verifique se o metadata.jsonarquivo possui todos os campos obrigatórios (consulte https://docs.puppet.com/puppet/latest/reference/modules_metadata.html#allowed-keys-in-metadatajson )

Ocorreu um problema semelhante com o fantoche 3.7.1 para o Fedora: Não foi possível encontrar o fantoche de classe para o my.server

Solução:

sudo ln -s /my/local/copy/puppet/modules /etc/puppet/

Então funciona.

Eu tive um problema parecido. No meu caso, o nome da classe era "onehost :: change_IoT_password_reminder". Depois de usar o strace, descobri que o puppet estava procurando por um arquivo modules / onehost / manifestests / change_iot_password_reminder.pp. Parece que usar letras maiúsculas nos nomes das turmas não é uma boa ideia, mesmo que não seja a primeira letra da turma.