foreman架构的引入10-hostgroup如何转换为本地的fact

简介:

零基础学习Puppet自动化配置管理系列文档

在Foreman上可以根据业务逻辑设置多个主机组(Host Groups),并且可以将不同的节点加入到不同的主机组,这样在每次操作“puppet run”的时候,只需要在搜索按钮里搜索对应的主机组即可找到里面包含的所有节点,如下图所示

Foreman安装Foreman安装

但是,foreman目前在puppet run上对mcollective的集成度很低,基本就是只能运行一条命令。那么如果要在shell终端上通过mco命令去对这些自定义的Host Groups进行操作应该如何做呢。答案是转换为facter。

自定义facter有四种方式,如下:http://kisspuppet.com/2014/03/30/puppet_learning_base10/

这里介绍第三种方式将Foreman上设置的主机组(Host Groups)转换为每个节点自己的facter

1、首先创建主机组

Foreman安装Foreman安装

2、查看节点的主机组信息

其实相当于自定义了一个外部变量,变量名叫hostgroup,值为节点加入的组名称

Foreman安装Foreman安装

Foreman安装Foreman安装

3、编写一个fact模块

模块的功能就是将Foreman上的变量“hostgroup”落地到每个节点的/etc/facter/facts.d/${hostname}.txt文件中,内容为fact的标准格式。

#模块结构
[root@puppetmaster162 modules]# tree fact
fact
├── files
├── manifests
│   ├── config.pp
│   ├── fact.pp
│   ├── init.pp
│   └── params.pp
└── templates
    └── hostgroup.erb
3 directories, 5 files
#模块主配置文件init.pp
[root@puppetmaster162 modules]# cat fact/manifests/init.pp 
class fact {
  tag("puppet_env")
  require fact::params
  $hostgroup_erb = $fact::params::hostgroup_erb
  include fact::config
  include fact::facter
}

#创建目录以及文件
[root@puppetmaster162 modules]# cat fact/manifests/config.pp 
class fact::config{
  file { '/etc/facter' :
    ensure  => directory,
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
  }
  file { '/etc/facter/facts.d' :
    ensure  => directory,
    owner   => 'root',
    group   => 'root',
    mode    => '0644',
    require => File['/etc/facter']
  }
  file{ "/etc/facter/facts.d/$hostname.txt":
    owner   => "root",
    group   => "root",
    mode    => 0400,
    content => template($fact::hostgroup_erb),
    require => File['/etc/facter/facts.d'],
  }
}

#定义变量
[root@puppetmaster162 modules]# cat fact/manifests/params.pp 
class fact::params{
  $hostgroup_erb = 'fact/hostgroup.erb'
}

#定义fact模板(原因可参考http://kisspuppet.com/2013/11/10/mcollective-middleware/)
[root@puppetmaster162 manifests]# cat fact.pp 
class fact::facter{
file{"/etc/mcollective/facts.yaml":
    owner    => root,
    group    => root,
    mode     => 0440,
    loglevel => debug, # reduce noise in Puppet reports
    content  => inline_template('<%= scope.to_hash.reject { |k,v| k.to_s =~ /(uptime.*|path|timestamp|free|.*password.*|.*psk.*|.*key)/ }.to_yaml %>'),
  }
}

#设置文件模板
[root@puppetmaster162 modules]# cat fact/templates/hostgroup.erb 
hostgroup=<%= @hostgroup %> 
foreman_env=<%= @foreman_env %>

4、Foreman上管理主机组和模块fact

先导入类,然后在主机组里进行关联即可,由于fact模块是针对所有主机的,建议关联到1级主机组,加入的节点会自动继承。关联完成后的效果如下

Foreman安装Foreman安装

Foreman安装Foreman安装

5、在Foreman上对两个节点执行“puppet run”操作

Foreman安装Foreman安装

6、查看facter信息是否生成

[root@foreman163 ~]# facter hostgroup
prd 
[root@puppetmaster162 ~]# facter hostgroup
prd/kisspuppet

7、通过mco命令结合fact进行过滤查看

[root@puppetmaster162 ~]# mco ping  -F hostgroup=prd
foreman163.kisspuppet.com                time=98.55 ms
---- ping statistics ----
1 replies max: 98.55 min: 98.55 avg: 98.55 
[root@puppetmaster162 ~]# mco ping  -F hostgroup=prd/kisspuppet
puppetmaster162.kisspuppet.com           time=94.14 ms
---- ping statistics ----
1 replies max: 94.14 min: 94.14 avg: 94.14 
[root@puppetmaster162 ~]# mco puppet -v runonce -F hostgroup=prd/kisspuppet
Discovering hosts using the mc method for 2 second(s) .... 1
 * [ ============================================================> ] 1 / 1
puppetmaster162.kisspuppet.com          : OK
    {:summary=>      "Started a Puppet run using the 'puppet agent --test --color=false --splay --splaylimit 30' command"}
---- rpc stats ----
           Nodes: 1 / 1
     Pass / Fail: 1 / 0
      Start Time: Thu Dec 18 15:13:09 +0800 2014
  Discovery Time: 2004.07ms
      Agent Time: 85.19ms
      Total Time: 2089.26ms

注:以上方式只是提供了一种思路,更多的方式还需要根据具体的实际环境而改变,总之一点,fact很强大,看你怎么用。



本文转自凌激冰51CTO博客,原文链接:http://blog.51cto.com/dreamfire/1591390,如需转载请自行联系原作者


相关文章
|
13天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
11天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
29 1
服务架构的演进:从单体到微服务的探索之旅
|
10天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
27 8
下一篇
无影云桌面