現在、すべての構成を含むモノリシックなパペットリポジトリからの移行を進めています。この1つのリポジトリには、これまでにすべてのノードに存在するべきではないものが含まれているため、puppetmasterベースのシステムは、適切に分離するための最良の方法のようです。
私が抱えている問題は、ローカルノードにコピーしてpuppet apply /etc/puppet/manifests/site.pp
を実行すると、同じリポジトリが正常に機能することです。インストールは非常にきれいに実行されます。
Puppetmasterにpuppet repoを配置してエージェントに署名しても、ローカルカタログをpuppetmasterに報告する以外は何もしません。
しばらくの間、これを行った構成を再現できなかったため、自作のモジュールの1つが、ローカルマシンのmodules
からファイルをコピーしようとしていることを示すエラーをスローしていました必要に応じて、puppetmasterではなくディレクトリ。
これは、ローカルで使用するため、および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
ファイルとilkは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
[...]
}
Puppet applyを介して実行すると、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
}
}
私が知っている唯一の注意点はfile
リソースタイプです。
置き換えられたファイルのバックアップは、ローカルのファイルバケットの代わりにデフォルトでサーバーのファイルバケットを使用して、動作が異なります。
注意すべきより重要なことは、source
パラメータです。
source => '/tmp/somepath/sshd_config',
生のファイルパスでは、常にローカルパスが試行されます。
source => 'puppet://puppetmaster1/modules/sshd/sshd_config',
とともに puppet://server/
パス、常にリモートパスを試行します。
source => 'puppet:///modules/sshd/sshd_config',
空のサーバー仕様があると、面白くなります。
ローカルに適用すると、ローカルのパペットモジュールパスがファイルの検索に使用されます。
Puppetmasterに報告する場合、マニフェストを提供したサーバーはサーバーとして扱われます。
さらに、ファイルのソースについてクリエイティブにする必要がある場合は、source
パラメータにリストを指定できます。
source => [ '/tmp/somepath/sshd_config', 'puppet:///modules/sshd/sshd_config'],
何かが見つかった最初の場所が使用されます。
問題は結局、ノードの選択方法の違いになりました。元のnodes.pp
ファイルのコード:
node /clunod\-wk\d+\.sub\.example\.local/ { )
これはclunod-wk01234.sub.example.localという名前のノードに正しく一致します。 puppet apply
がローカルの人形マニフェストに対して実行されたとき、これは正常に機能していました。しかし、リモートではありませんでした。
問題は、localhost
行が/etc/hosts
でどのように定義されたかでした。
非稼働:
127.0.0.1 localhost clunod-wk01234 clunod-wk01234.sub.example.local
ワーキング:
127.0.0.1 localhost clunod-wk01234.sub.example.local clunod-wk01234
最初のフォームはノード名「clunod-wk01234」をpuppetmasterに報告し、2番目のフォームはFQDNを報告していました。 2番目の形式はnode
デルカレーションを満たしますが、最初の形式は満たしません。これは、FQDNを含まないようにノード行を変更することで解読されましたが、その時点ですべてが正常に機能しました。
リモートパペットを備えたマシンは更新されたイメージだったので、ローカルパペットを実行しているマシンとは若干の違いがありました。これらの変更の1つは、/etc/hosts
の1行がどのように宣言されたかにあります。今、私たちは知っています。
次に、2つのファイル呼び出しがハードパスを使用して記述されていることを発見しました。残りは正しいpuppet:///構文を使用していました。
「ローカル」と「リモート」のパペットルールに違いはありません。
間違いをチェックできるように、site.ppを投稿できますか?
サーバーとクライアントは同じDNSサーバーを使用していますか? /etc/resolv.confファイルの「search」行または「domain」行は異なりますか?
--debug --verbose --no-daemonize
オプションを使用してパペットを実行し、より多くの出力を取得することもできます。