☰

本地“傀儡应用”和“傀儡代理”与傀儡大师之间的区别

tag-icon • tag-icon puppet puppetmaster
本地“傀儡应用”和“傀儡代理”与傀儡大师之间的区别

我们正在从包含所有配置的单一 Puppet 存储库迁移。这个存储库包含的内容实际上不应该出现在每个节点上，因此基于 Puppetmaster 的系统似乎是适当隔离内容的最佳方式。

我遇到的问题是，将同一个 repo 复制到本地节点并puppet apply /etc/puppet/manifests/site.pp在其上运行后，它工作得很好。我们的安装运行非常顺利。

当我将 puppet repo 放在 puppetmaster 上并让代理签名时，它似乎没有做任何事情，除了向 puppetmaster 报告它的本地目录。

有一段时间，我无法重现执行此操作的配置，我们的一个自建模块抛出了一个错误，表明它试图从本地机器的modules目录复制文件，而不是像它应该的那样从 puppetmaster 复制。

这表明，在为本地使用和通过 puppetmaster 构建 repo 时，模块和清单语法可能会存在差异。

如果存在任何差异，那么这些差异是什么，或者转换工作的主要绊脚石是什么？

/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文件及同类文件是指向的符号链接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
  [...]
}

clunod-wk01234.sub.example.local当通过 puppet apply 运行时，它可以并且确实匹配命名的节点。

[int-设置.pp]

class int_setup {
  file { "/var/cluebat":
    ensure => directory,
    mode => "755",
    owner => "root",
    group => "root";
  }

  group{"puppet":
    ensure => present
  }

}

答案1

我所知道的唯一棘手之处是file资源类型。

替换文件的备份行为有所不同，默认使用服务器的文件存储桶而不是本地文件存储桶。

需要注意的更重要的事情是source参数。

source => '/tmp/somepath/sshd_config',

对于原始文件路径，它将始终尝试本地路径。

source => 'puppet://puppetmaster1/modules/sshd/sshd_config',

有了puppet://server/路径，它总是会尝试远程路径。

source => 'puppet:///modules/sshd/sshd_config',

有了空的服务器规范，事情就会变得有趣。

本地应用时，使用本地puppet模块路径来查找文件。

当向 puppetmaster 报告时，向其提供清单的服务器将被视为服务器。

此外，如果您需要对文件来源进行创新，您可以为参数提供source一个列表：

source => [ '/tmp/somepath/sshd_config', 'puppet:///modules/sshd/sshd_config'],

将使用第一个发现某物的位置。

答案2

问题最终在于节点选择方式的不同。原始nodes.pp文件中的代码：

node /clunod\-wk\d+\.sub\.example\.local/ { )

puppet apply它正确匹配名为 clunod-wk01234.sub.example.local 的节点。当针对本地 Puppet 清单运行时，它工作正常。但远程则不行。

问题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

第一种形式向 puppetmaster 报告节点名称“clunid-wk01234”，第二种形式报告 FQDN。第二种形式满足声明node，而第一种形式不满足。通过将节点行更改为不包含 FQDN，可以解决这个问题，此时一切都正常。

安装了 remote-puppet 的机器是更新后的镜像，因此与运行 local-puppet 的机器确实存在一些细微差异。其中一个变化最终在于那一行是如何/etc/hosts声明的。现在我们知道了。

然后我发现两个文件调用是使用硬路径编写的，其余的则使用了正确的 puppet:/// 语法。

答案3

“本地”和“远程”傀儡规则之间没有区别。

您能发布您的 site.pp 以便我们检查错误吗？

服务器和客户端是否使用相同的 DNS 服务器？它们的 /etc/resolv.conf 文件中的“搜索”或“域”行是否不同？

您还可以使用--debug --verbose --no-daemonize选项运行 puppet 并获得更多输出。

相关内容