web-dev-qa-db-ja.com

ローカルの「パペット適用」とパペットマスターへの「パペットエージェント」の違い

現在、すべての構成を含むモノリシックなパペットリポジトリからの移行を進めています。この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
  }

}
puppetpuppetmaster
4
sysadmin1138

私が知っている唯一の注意点は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'],

何かが見つかった最初の場所が使用されます。

5
Shane Madden

問題は結局、ノードの選択方法の違いになりました。元の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：///構文を使用していました。

4
sysadmin1138

「ローカル」と「リモート」のパペットルールに違いはありません。

間違いをチェックできるように、site.ppを投稿できますか？

サーバーとクライアントは同じDNSサーバーを使用していますか？ /etc/resolv.confファイルの「search」行または「domain」行は異なりますか？

--debug --verbose --no-daemonizeオプションを使用してパペットを実行し、より多くの出力を取得することもできます。

1
hayalci