实际生产使用中,默认的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
