puppet组织架构

   树结构如下： 
       |-- puppet.conf   #主配置配置文件 
       |-- fileserver.conf #文件服务器配置文件 
       |-- auth.conf     #认证配置文件 
       |-- autosign.conf # 自动验证配置文件 
       |-- tagmail.conf  #邮件配置文件（将错误信息发送） 
       |-- manifests     #文件存储目录(puppet 会先读取该目录的.PP 文件) 
       |   --nodes 
       |   |    | puppetclient.pp 
       |   |-- site.pp   #定义puppet 相关的变量和默认配置。 
       |   |-- modules.pp  #加载class 类模块文件（include syslog） 
       |-- modules        #定义模块 
       |   -- syslog     #以syslog 为例 
       |        |-- file 
       |        |-- manifests 
       |        |   |-- init.pp #class 类配置
       |        |--- templates    #模块配置目录 
       |        |   |-- syslog.erb #erb 模板

资源：定义目标状态的核心组件；

核心资源包括：notify、package、group、user、file、exec、cron、service等；

模块：以资源为核心，是类的集合，如mod1，mod2

节点：以被管理主机为为核心，如node1，node2

puppet利用模块+节点的方式，实现目标状态的定义

manifest：清单，用于定义并保存资源，是一个资源组织工具；

facter：获取各被管理节点资源使用情况的方式；

看了网上无数资料，通过亿图画出了以下三种结构，红色的表示根目录，桔色的表示目录，蓝色的表示文件。因为我处于探索puppet中，所以不好说谁好谁坏，根据我目前个人的理解，我觉得图二比较适合我公司用，linux服务器不多，只有70台左右，其它几百台服务器都是windows，用不上puppet。图一，太过于简单，如果节点服务器一多，结构势必会有点乱，图三，过于精细化，对上千台服务器的规模有用。

功能说明:安装cron包并启动服务

vim base.pp
----------------------
class cron::base {   
package { cron:  
name => $operatingsystem ?  
{#facter 获取客户端操作系统确定包的名称  
ubuntu => "cron",  
debian => "cron",  
redhat => "vixie-cron",  
centos => "vixie-cron", },  
ensure => present,  
}  

puppet组织架构