自动化运维之puppet

kinila

随着IT行业的迅猛发展，传统的运维方式靠大量人力比较吃力，近几年自动化运维管理快速的发展，得到了很多IT运维人员的青睐，一个完整的自动化运维包括系统安装、配置管理、服务监控三个方面。那今天咱们大家一起来学习一下puppet实际运维中的案例。仅供参考，欢迎大家提更多的意见！

一、应用背景

某公司新到500台服务器，需要安装Linux系统，并部署上线以及后期的管理配置。对于系统安装，这个时候肯定得采用批量安装的，常见批量安装方式有大家熟知的Kickstart和Cobbler，具体配置方法，网上也有很多好文章，这里略过。

提示：如果采用自动安装的话，我们可以自动初始化系统、内核简单优化、及常见服务、软件客户端等安装。当然puppet客户端也可以放在kickstart中安装并配置完毕。

当系统稳定运行后，现在我们需要调整和管理部分服务器，例如要修改100台服务器的系统参数、远程执行命令等，这时候如何操作呢？我们可能会想到脚本，想法很好，如果让你手动去100台服务器执行同样的脚本、或者修改某一个配置，是不是也浪费时间呢，利用puppet可以在几分钟、甚至数秒内全部搞定。

二、实际案例配置

现在有一个需求，需要修改100台Linux服务器上的crontab ntp时间服务器地址，原服务器crontab NTP配置段为：

0 0 * * * /usr/sbin/ntpdate pool.ntp.org >>/data/logs/crontab/ntpdate.log 2>&1

现在需要调整为内部自建的服务器地址10.1.1.21，并且修改同步的时间，如下：

0 */5 * * * /usr/sbin/ntpdate 10.1.1.21 >>/data/logs/crontab/ntpdate.log 2>&1

编写puppet ntp模块：

Vi /etc/puppet/modules/ntp/manifests/init.pp

class ntp {

Exec { path =>”/bin:/sbin:/bin/sh:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin”}

exec {

“auto change crontab ntp config”:

command =>”sed -i -e ‘/ntpdate/s/0/*\/5 /2′ -e ‘s/pool.ntp.org/10.1.1.21/’ /var/spool/cron/root”,

}

}

这段代码的注解：创建ntp模块，利用exec资源远程执行一条命令，同样可以举一反三，其他的修改和配置都可以参考此方法。其中Exec path的意思是定义全局path。如果不定义的话，每一次exec资源都要定义一个path路径。

二、实际案例配置

当我们有大规模集群的时候，所有服务器要求要求数据一致，可以采用rsync同步，配置rsync服务器端，客户端执行脚本命令即可。同样可以使用puppet+脚本来同步，这样比较快捷，当然也可以使用puppet rsync模块。Rsync配置此处忽略，直接上puppet代码：

##定义www模块

class www {

##定义全局path

Exec { path =>”/bin:/sbin:/bin/sh:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin”}

##推送sh脚本到客户端，192-9-117-162-tdt.com为服务端

file {

“/data/sh/rsync_www_client.sh”:

source =>”puppet://192-9-117-162-tdt.com/files/www/rsync_www_client.sh”,

owner =>”root”,

group =>”root”,

mode =>”755″,

}

##推送密钥文件到客户端，权限设置为600

file {

“/etc/rsync.pas”:

source =>”puppet://192-9-117-162-tdt.com/files/www/rsync.pas”,

owner =>”root”,

group =>”root”,

mode =>”600″,

}

##远程执行命令，备份原有程序，并判断rsync客户端脚本是否有修改，如果有变化，则执行。

exec {

“auto backup www data”:

command =>”mkdir -p /data/backup/`date +%Y%m%d`;mv /data/index /data/backup/www/`date +%Y%m%d` ; /bin/sh /data/sh/rsync_www_client.sh “,

user =>”root”,

subscribe =>File["/data/sh/rsync_bus_client.sh"],

refreshonly =>”true”,

}

}

三、测试puppet

注*这里如果要使用puppetrun（puppet kick）推送功能的话，需要提前配置好客户端，并在客户端授权允许服务端发送信号，具体配置文章见：http://wgkgood.blog.iyunv.com/1192594/869694

在服务器端执行:

puppet kick -d -host `cat puppet.txt`

Cat Puppet.txt内容为需要同步的客户端的主机名：

192-9-117-163-tdt.com

192-9-117-164-tdt.com

192-9-117-165-tdt.com

四、puppet总结

本文仅供参考，通过了解和学习，我们可以更加深入的去理解puppet工作原理以及深入配置，举一反三：

1、如何在master端对客户端进行分组？除了正则还可以用什么？

2、当服务器数量不断增加，一台puppe tmaster肯定很吃力，如何扩展？如何更好的维护和统一管理puppet node配置？

3、如何结合SVN直接提交代码？等等问题。











Puppet在一款自动化系统配置管理的工具，它可以让你在很短的时间内对大量硬件和系统基本类似的系统，进行统一的系统配置管理。

    说的简单点，就像开网吧，你需要对网吧的每一台机器安装操作系统，配置完全一样的软件，比如QQ和360，供网友上网，在系统和软件有损坏时，很简单的一个恢复操作就可以让机器回到刚刚安装好操作系统和软件的状态。

    Puppet就是可以干这个事儿的，不同在于，Puppet是给网络管理员用的，而针对的系统多是*nix系统，因为Puppet目前对Windows支持的很少，但这不妨碍Puppet成为DevOps实现过程中的利器，另外一个类似的工具是Chef。

    Puppet本身基于Ruby实现，但即使没有Ruby的经验也没甚大碍。Puppet自己提出了所谓Puppet Language，是一种DSL(Domain Specific Language)语言，用直白而描述性的语言，定义系统应该具有的状态，比如一个简单的例子tmpfile.pp：

file { 'testfile':
path => '/tmp/testfile',
    ensure  => present,
    mode    => 0640,
    content => "I'm a test file.",
}    在安装了Puppet了机器上运行：
puppet apply tmpfile.pp

    结果就会在/tmp下新增加一个testfile，内容是This is a test file。

     这个例子太简单。除了file这种类型外，Puppet提供了大量的资源类型，供对系统的状态进行描述，比如打开(如果不存在会自动下载)某项服务，自动增加一个用户。当管理的机器成百上千，这样的自动化服务达到的效果就很可观了。

    puppet apply是Puppet在单机上运行和测试的工具，真实的使用情景会是，一台机器(master)专门保留所有机器配置管理的状态信息，而每台机器(agent)会在指定的时间向master发起查询，从而更新自己的系统状态，以期与指定状态保持一致。








Puppet学习之exec资源管理: http://blog.iyunv.com/uid-23500957-id-3808111.html





puppet 如何有条件的执行exec资源: http://www.tuicool.com/articles/EV7Ffa
　　
　　puppet exec 资源:  http://blog.csdn.net/qingchn/article/details/7737415
　　Puppet中文wiki: http://puppet.wikidot.com/