PUPPET生产拾遗(2)

实际生产使用中,默认的puppet配置方式对应复杂的产线使用场景会遇到各种问题,业务多而杂,标准需求&&非标需求之间的冲突,外购系统&&内部自研系统的冲突,会造成各种各样的需求,所以在使用的时候会做一些修改,以下记录一些常用的功能。

facter

facter是puppet跨平台的信息收集工具,支持自定义,
使用facter -p 可以获取到facter自带的信息,如开机时间,OS版本等等,这些基础信息非常有用,puppet可以基于这些内置facts信息实现动态配置

自定义facts

  • 添加配置,路径可以自己定义,最后加到FACTERLIB的环境变量下即可,EP:/var/lib/puppet/my_fact/allusernum.rb
Facter.add(:users) do
setcode do
 %x{/bin/cat /etc/passwd |wc -l}.chomp
  end
end
  • 将配置路径加到环境变量内:
export FACTERLIB=/var/lib/puppet/my_fact/
  • 使用:
facter users
63

hiera

hiera 是个非常实用的功能,先来看下传统puppet的配置方式,比如产线有100个应用,每个应用会对应一个puppet的env,配置时候会发现这100个env里有相同的同步项(module),比如代码路径,日志路径等等,但也会有不同的同步项目(module),如配置文件等,这样就导致了相同的同步项需要放在100个env的目录下,一旦相同的module有修改,相当于要改100遍,更不要说这100个应用里也会存在部分相同的module,这种module和env相互勾连的情况,可想而知多难用。
hiera可以非常好的解决这个问题,实现类似子类父类继承的关系,一个module可以被多个env引用,并基于facts的变量值动态识别环境

安装配置hiera

  • 安装
yum install hiera hiera-puppet -y
mv /etc/hiera.yaml /etc/puppet/
ln -s /etc/puppet/hiera.yaml /etc/hiera.yaml
ll /etc/hiera.yaml
  • 配置
#hiera 配置
cat /etc/puppet/hiera.yaml 
---
#定义配置文件格式
:backends:
  - yaml
:hierarchy:
  - common #一般编写的是所有环境都需要使用的通用配置
  - "environment/%{::environment}" #基于环境的差异化配置
  - "osfamily/%{::osfamily}_%{::operatingsystem}" #基于操作系统以及版本的差异化配置
:yaml:
  :datadir:"/etc/puppet/hieradata" #存放上面hierarchy的配置路径

#环境配置
cat /etc/puppet/environment/sa_common/manifests/site.pp
node default {
    hiera_inclue('basic_setting')
    hiera_inclue('env_setting')
    hiera_inclue('os_setting')
}

#所有环境需要的通用配置
cat /etc/puppet/hieradata/common.yaml
---
basic_setting:
  - basic_dns
  - basic_user
app_setting:
  - basic_app_cfg

#不同环境的特殊配置
cat /etc/puppet/hieradata/environment/sa_env.yaml
---
env_setting:
  - env_cfg
  - env_user

#不同OS版本的差异配置
cat /etc/puppet/hieradata/osfamily/RedHat_7.5.yaml
---
os_setting:
   - rh7_yumrepo

#上面的配置里存放的均是puppet的modules
ls /etc/puppet/modules/
basic_dns
basic_user
basic_app_cfg

最后在客户端执行puppet agent -t 同步时,同步就会从comm开始自上而下进行匹配同步,当然实际产线运用中,配置项会用的多的多,这边只是记录一下配置实,避免忘记

mcollective

mco 框架,我们产线服务器数量大约高峰在1.6-1.8W台VM+BM,平时在1.2W左右,大规模主机集群可以通过之前的横向扩展方式进行部署,但我们有需求需要进行短时间内主动推送,就会有问题,比如产线6000台主机需要同步配置文件A,另外6000台需要同步配置文件B,需要在1小时内完成,(虽然Slat-stack等类似可以很简单的完成。。但这里还是只先记录puppet。。),这种场景下使用puppet kick 也不现实,更别说高版本的puppet 还把这个命令移除了。所以用mco的方式推送会比较好,mco说白了就是一个推送框架,server端和client端都链接中间件(rabbitmq&&activemq)然后通过消息广播的方式进行命令下发,mcoserver端支持客户端的自动发现,以及推送的正则表达式,可以 基于facts的返回进行推送,但实际使用下来并不是很稳定,且广播方式推送虽然很快,6000台大约在1min内能完成,但是由于使用的是异步方式,mco客户端只会告诉server端我执行了puppet同步,但同步结果却不会返回,所以也存在一定局限性。

  • Rabbitmq

搭建省略。产线集群搭建可以参考之前的笔记

  • Mco服务端
yum install mcollective  mcollective-common -y #依赖rubygem-stomp、rubygems和ruby相关包,在puppet5.x版本中 mcollective 已经随puppet安装,无需另外安装

cat /etc/mcollective/server.cfg
topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/libexec/mcollective  #插件位置
logfile = /var/log/mcollective.log
loglevel = info
daemonize = 1
# Plugins
securityprovider = psk
plugin.psk = a36cd839414370e10fd281b8a39ada9 #MCollective通信共享密钥,和MCollective客户端保持一致
connector = stomp #通信协议
plugin.stomp.host =  21.66.127.1  #Middleware地址
plugin.stomp.port =  61613  #Middleware监听端口
plugin.stomp.user = mcollective  #Middleware通信账号
plugin.stomp.password = secret #Middleware通信密码
# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml
/etc/rc.d/init.d/mcollective start
chkconfig mcollective on
  • Mco 客户端
yum install mcollective  mcollective-common -y #依赖rubygem-stomp、rubygems和ruby相关包

cat /etc/mcollective/client.cfg
topicprefix = /topic/
main_collective = mcollective
collectives = mcollective
libdir = /usr/libexec/mcollective
logger_type = console
loglevel = warn
# Plugins
securityprovider = psk
plugin.psk = a36cd839414370e10fd281b8a39ada9  #MCollective通信共享密钥,和MCollective服务端保持一致
connector = stomp  #通信协议
plugin.stomp.host = 21.66.127.1  #Middleware地址
plugin.stomp.port = 61613  #Middleware监听端口
plugin.stomp.user = mcollective  #Middleware通信账号
plugin.stomp.password = secret #Middleware通信密码
# Facts
factsource = yaml
plugin.yaml = /etc/mcollective/facts.yaml
  • 通信
mco ping
上一篇:SpringBoot + webSocket + stomp +thymeleaf 推流


下一篇:向linux kernel中添加cmdline的四种方式