クラスが見つかりませんでしたが、まだあります

puppet agent新しいイメージから呼び出しを行うと、err: Could not find class custommodエラーが発生します。モジュール自体は、/etc/puppet/modules/custommod私たちが呼び出している他のすべてのモジュールと同じですが、これは頑固です。

[site.pp]

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

puppetmasterをデバッグ出力で実行すると、baseおよび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

行84は include custommod

短縮されたディレクトリとファイル構造：

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

スペルを確認しました：}

init.ppcustommodディレクトリ内のコンテンツはまったく目立たない：

class custommod {
}

目的は、肉がある場所であるapps.ppファイルの空のクラスを作成することです。

class custommod::apps {

    [lots of stuff]
}

ただ、appsファイルに到達することはありません。をコメントアウトするとinclude custommod、class{ "custommod::apps": frontend => "false}代わりに上記のエラーが行に生成されます。

このエラーがどのように生成されているかを知るための狩りで何が欠けていますか？このレポがを介してローカルで実行された場合、このレポは問題なく動作することに注意する必要がありpuppet applyます。

だから...これは少し恥ずかしいですが...

環境。

私の/etc/puppet.confファイルの中にはこれがあります：

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

それを投げstraceてファイルを探している場所を見つけた後、私は何かに気付きました。でcustommodを探していました/etc/puppet/environments/production/modulesが、そこにディレクトリがあったため（空の状態）、checkに行きませんでした/etc/puppet/modules。どうやらモジュールをインポートするとき、ファイルの存在（init.pp）ではなく、ディレクトリの存在を確認します。

その空のディレクトリを削除すると、作業が開始されます。

別の環境を使用してpuppetエージェントを実行すると、作業が開始されます。

この話の教訓：

Puppet環境のパスは、bash $ PATHのようには機能しません。

私はこの同じ問題に遭遇しましたが、別の修正がありました

次のようなパペットモジュールを生成する場合：

puppet module generate foo-example_module

これは、という名前のモジュールが作成されますexample_moduleとfoo名前空間を。すべてのマニフェストは、というディレクトリ内にありますfoo-example_module

init.ppで定義されているクラスの名前は、フォルダー名と同じである必要があります。

簡単な修正：

mv foo-example_module example_module

puppet-lintを実行すると、次のメッセージが警告されます。

ERROR: example_module not in autoload module layout on line 42

r10kまたはlibrarian-puppetでPuppetfileを使用する場合は、名前空間を削除して、モジュールディレクトリに「foo」プレフィックスなしでファイルが配置されるようにする必要があります。

前：

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

後：

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

発生する可能性がある別の問題は、モジュールに無効なmetadata.jsonファイルがある場合です。

metadata.jsonファイルにすべての必須フィールドがあることを確認します（https://docs.puppet.com/puppet/latest/reference/modules_metadata.html#allowed-keys-in-metadatajsonを参照）

Fedoraのパペット3.7.1で同様の問題が発生しました：my.serverのクラスパペットが見つかりませんでした

溶液：

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

その後、動作します。

同様の問題がありました。私の場合、クラス名は「onehost :: change_IoT_password_reminder」でした。straceを使用した後、puppetがmodules / onehost / manifests / change_iot_password_reminder.ppファイルを探していることがわかりました。クラスの最初の文字でなくても、クラス名に大文字を使用することはお勧めできません。