使用Puppet配置远程规则集

时间:2018-11-17 10:55:07

标签: puppet prometheus configuration-management facter

我正在尝试使Prometheus node_exporter和Prometheus Server自动化。 对于node_exporter,我编写了一个模块来安装所有必需的软件包,请根据$::ipaddress等设置facter

现在,我想确保从应用节点收集的信息($hostname$job_name,[...])已导出到相应的远程Prometheus配置文件中,但是我想要以异步方式完成此步骤,例如,随后在Prometheus Server上运行一个木偶代理。

我尝试将类定向到puppetlabs/logrotate模块,该模块基本上在执行以下操作:

logrotate / init.pp

class logrotate (
  String $ensure              = present,
  Boolean $hieramerge         = false,
  Boolean $manage_cron_daily  = true,
  Boolean $create_base_rules  = true,
  Boolean $purge_configdir    = false,
  String $package             = 'logrotate',
  Hash $rules                 = {},
) {
  do some stuff
}    

logrotate / rules.pp

class logrotate::rules ($rules = $::logrotate::rules){
  #assert_private()
  create_resources('logrotate::rule', $rules)
}

logrotate / rule.pp

define logrotate::rule(
  Pattern[/^[a-zA-Z0-9\._-]+$/] $rulename           = $title,
  Enum['present','absent'] $ensure                  = 'present',
  Optional[Logrotate::Path] $path                   = undef,
  (...)
  ) {
    do some stuff
  } 

缩短了我的ni_trending(node_exporter)和ni_prometheus模块,它们看起来与logrotate非常相似:

ni_trending / init.pp

class ni_trending (
  $hostname       = $::fqdn,
  $listen_address = $::ipaddress,
  $listen_port    = 51118,
) { 

) inherits ni_trending::params {

anchor { 'ni_trending::start': }
  ->class { 'ni_trending::package': }
  ->class { 'ni_trending::config':
    (...)
    listen_address => $listen_address,
    listen_port    => $listen_port,
    (...)
    }
  ->class { 'ni_trending::service': }
  ->class { ' ni_trending::prometheus':
    (...)
    hostname     => $hostname,
    listen_port  => $listen_port,
    (...)
    }
    ->anchor { 'ni_trending::end': }
}

ni_trending / prometheus.pp

class ni_trending::prometheus (
  Hash $options        = {},
) {

  ni_prometheus::nodeexporterrule { 'node_exporter' :
    ensure      => pick_default($options['ensure'], 'present'),
    hostname    => pick_default($options['hostname'], $ni_trending::hostname),
    listen_port => pick_default($options['hostname'], $ni_trending::listen_port),
    }
}

ni_prometheus / nodeexporterrules.pp

class ni_prometheus::nodeexporterrules ($rules = $::ni_prometheus::nodeexporterrules) {

  create_resources('ni_prometheus::nodeexporterrule', $nodeexporterrules)

}

ni_prometheus / nodeexporterrule.pp

define ni_prometheus::nodeexporterrule (
  $job_name                         = $title,
  Enum['present','absent'] $ensure  = 'present',
  $hostname                         = $hostname,
  $listen_port                      = $listen_port,
) {

  file_line { "prometheus-${job_name}" :
    path  => "/etc/prometheus/${job_name}.list",
    after => 'hosts:',
    line  => "${hostname}:${listen_port}",
  }
}

但是,这仅在我在Prometheus Master上本地应用node_exporter时才有效-而不是在外部机器包含ni_trending::prometheus类的情况下,这对我来说很有意义-因为它很显然感觉缺少了一些东西。 :-)我该如何工作?

谢谢!

1 个答案:

答案 0 :(得分:2)

这听起来像是exported resources的工作(一天就能赚two!)。这是一个节点的目录构建工具,用于生成可应用于其他节点(以及可选地,还可应用于导出节点本身)的资源。我仍未跟踪要在哪里管理的内容的详细信息,因此,这是一个更通用的示例:维护本地主机文件。

通用示例

假设我们要自动管理一个列出我们所有受管节点的主机文件。 Puppet具有内置资源Host,它表示主机文件中的一项。我们通过让受管理的每个节点导出适当的主机资源来利用这一点。这样的事情会出现在每个节点上包含的类中:

@@host { "$hostname": ip => $ipaddress; }

@@前缀将资源标记为已导出。除非通过稍后描述的机制,否则它不会应用于当前目标节点。 $hostname$ipaddress只是目标节点提供的事实,并在该上下文中得到了解决。还要注意,资源标题是全局唯一的:每个目标节点都有不同的主机名,因此,应用于不同目标节点的所有导出的Host资源都将具有不同的标题。

然后,每个要应用所有那些Host条目的节点将通过使用exported resource collector在自己的目录中导入

<<|Host|>>

导出这些资源的节点也可以收集其中的一部分或全部。此外,还有一些方法可以更选择性地收集哪些资源。参见上面的链接。