Impossible de trouver la classe, et pourtant elle est là

Lorsque puppet agentje fais un appel à partir d'une nouvelle image, je reçois une err: Could not find class custommoderreur. Le module lui-même est /etc/puppet/modules/custommodidentique à tous les autres modules que nous appelons, mais celui-ci est obstinante.

[site.pp]

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

Lorsque le marionnettiste est exécuté avec une sortie de débogage, il trouve clairement les informations de base et de 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

La ligne 84 est include custommod

Un répertoire abrégé et une structure de fichiers:

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

J'ai vérifié l'orthographe:}

Le contenu de init.ppl'annuaire des clients est complètement banal:

class custommod {
}

L'objectif est de créer une classe vide pour le fichier apps.pp, où se trouve la viande.

class custommod::apps {

    [lots of stuff]
}

Seulement, il n'atteint jamais le fichier des applications. Si je commente le include custommod, l'erreur ci-dessus est générée à la class{ "custommod::apps": frontend => "false}place sur la ligne.

Que manque-t-il dans ma chasse pour savoir comment cette erreur est générée? Je dois noter que ce dépôt fonctionne très bien s'il est exécuté localement via puppet apply.

Donc ... c'est un peu gênant, mais ...

Environnements.

Là, dans mon /etc/puppet.confdossier, voici:

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

Après avoir jeté stracedessus pour comprendre où il cherchait des fichiers, j'ai remarqué quelque chose. Il cherchait un logement sous /etc/puppet/environments/production/modules, et comme il y avait un répertoire (vide), il n'est pas allé vérifier/etc/puppet/modules . Apparemment, lors de l'importation d'un module, il vérifie la présence du répertoire plutôt que la présence du fichier (init.pp).

Supprimez ce répertoire vide, les choses commencent à fonctionner.

Exécutez l'agent marionnette en utilisant un environnement différent, les choses commencent à fonctionner.

Morale de l'histoire:

Les chemins de l'environnement de marionnettes n'agissent pas comme bash $ PATH.

J'ai rencontré ce même problème, mais j'ai eu une solution différente

Si vous générez un module marionnette comme ceci:

puppet module generate foo-example_module

Il créera un module nommé example_moduleavec l' fooespace de nom. Tous les manifestes seront dans un répertoire appeléfoo-example_module

Le nom de la classe définie dans init.pp doit être le même que le nom du dossier.

Solution simple:

mv foo-example_module example_module

Si vous exécutez puppet-lint, il vous avertira avec le message suivant:

ERROR: example_module not in autoload module layout on line 42

Si vous utilisez un Puppetfile avec r10k ou librarian-puppet, vous devrez peut-être également supprimer l'espace de nom afin que les fichiers soient placés sans le préfixe 'foo' dans le répertoire de vos modules.

avant:

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

après:

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

Un autre problème qui pourrait se produire est lorsque votre module a un metadata.jsonfichier non valide .

Assurez-vous que le metadata.jsonfichier possède tous les champs obligatoires (voir https://docs.puppet.com/puppet/latest/reference/modules_metadata.html#allowed-keys-in-metadatajson )

A rencontré un problème similaire avec la marionnette 3.7.1 pour Fedora: impossible de trouver la marionnette de classe pour my.server

Solution:

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

Alors ça marche.

J'avais un problème similaire. Dans mon cas, le nom de la classe était "onehost :: change_IoT_password_reminder". Après avoir utilisé strace, j'ai trouvé que la marionnette recherchait un fichier modules / onehost / manifests / change_iot_password_reminder.pp. Il semble que l'utilisation de majuscules dans les noms de classe ne soit pas une bonne idée, même si ce n'est pas la première lettre de la classe.