推荐-运维学习笔记-Puppet应用配置的工作原理

背景知识

Puppet的核心功能是配置管理。一般来说，用户在master上集中做配置，同时，被管理节点上的agent会定期从master上下载配置数据，再应用（apply）到本地，从而使管理节点的状态（用户，组，文件，安装包，服务等的设置和运行状态）与masters上定义的保持一致。

有时，出于测试的目的，并不希望真的应用配置，那么就需要执行puppet agent –test –noop让agent运行在dry-run状态

触发条件

在无master模式下（masterless），可以运行puppet agent apply <manifest文件路径> 命令直接加载本地manifest，并应用到本地。这种方式一般只用于测试，生产环境大都使用agent/master模式。

在agent/master模式下，agent默认每30分钟自动触发一次。也就是说在master上做的任何更改可能要过30分钟才能在agent端生效。如果你想改变这个时间间隔，可以通过在agent上修改puppet.conf的runinterval属性

    [agent]  
    runinterval=10         #修改为每10分钟运行一次

 或者使用splay属性

    [agent]  
    splay=true              #默认是false。设置为true之后，运行间间隔变为随机数。当agent很多时，可以一定程度降低master的负载
    splaylimit = 20m     #间隔最长是20分钟,也可以设置成秒,分，小时，天，年

在agent/master模式下，还可以从master上运行puppet kick命令主动触发。为了使用这个功能，需要做以下配置。

1  在agent的puppet.conf中打开listen属性或者运行puppet agent –listen,然后agent就会在8139端口监听master发过来的指令。

    [agent]  
    listen = true         #agent会监听本地8139端口，需重启服务

注意：如果agent节点有防火墙，打开8139端口

2  然后在master上运行puppet agent <agent节点FQDN>触发一次新的配置应用。

工作流程

1. agent向master发起连接,并使用SSL证书相互认证身份。如果agent是第一次连接master，agent会生成私钥，下载CA证书的副本，提交证书申请，然后等待一个超时（waitforcert）。如果master在这个时间内签发了agent的证书，agent会下载证书，继续后面步骤。

2. 如果pluginsync是true,agent从master下载plugin

3. agent向master请求catalog,同时向master发送fact(软件及硬件信息,比如hostname, ip).然后等待catalog生成。

4. master使用site.pp（4的左侧部分）或者ENC（4的右侧部分）进行节点分类，获取agent节点所需的配置。然后使用一些agent/master提供的变量，比如facts，environement还有内部变量，编译相关manifest生成catalog

5. agent从master下载catalog，然后应用到本地。

6. 如果catalog中使用了mount point，比如"source=>"puppet:///abc"，agent会在应用过程中访问master的相关URI(/file_metadata/和/file_content/）下载文件内容并应用到本地

7. agent将应用结果生成report，发送给master

8. 结束本次应用，agent等待下一次。

注意：在以上agent/master的通讯过程中，都是agent主动调用master上暴露出来的RESTful API并将数据“拉”到本地，master并不主动向agent发送任信息。

下面我们来看看上边步骤中涉及到的各种功能和配置

SSL证书及认证

证书相关的属性可以在agent/master的puppet.conf里配置

[main]  
ssldir=/var/lib/puppet/ssl                    #设置存储所有SSL证书及相关文件的目录
[agent]               
#以下为可选配置。不设置会使用默认值
certname=mycert.example.com         #agent节点的证书名称，默认是节点FQDN.等同于puppet agent --certname mycert.example.com。master会用这个值来做节点分类
waitforcert=300s                               #默认值120秒。这个例子中，如果master没有为当前节点签发的证书，agent等待300秒再检查。等同于puppet agent --waitforcert 300. 

注意：agent需要对master URI（/certificate/，/certificate/ca和/certificate_request）有相应权限，以读取CA证书，提交证书申请和下载签发的证书。权限设置在auth.conf中。 默认是所有agent对这些URI都有权限。

证书及相关文件存在下面的目录中（在线文档）

/var/lib/puppet/ssl                    #存储所有SSL证书相关文件，在puppet.conf中定义为$ssldir 
├── ca                                    #CA证书目录，只存在于master上  
│   ├── ca_crl.pem                 #被CA取消(revoke）的证书
│   ├── ca_crt.pem                 #CA证书
│   ├── ca_key.pem                #CA证书私钥
│   ├── inventory.txt                #所有CA证书签过的证书的列表
│   ├── private
│   │   └── ca.pass                 #保护CA证书私钥的密码
│   ├── requests                     #存储所有master收到的但还未签署的agent的证书
│   ├── serial                          #下一个被签证书的序列号
│   └── signed                        #存储所有的已签证书，包含master和所有agent的证书
│       ├── agent.pem        
│       └── master.pem
├── certificate_requests          #当前节点所生成的证书申请，包括已提交和签发的
├── certs                                 #当前节点所有可见的已经签发的证书
│   ├── ca.pem                       #CA证书的拷贝  
│   └── master.pem                 #当前节点的已经被签证书
├── private                         
├── private_keys                    #当前节点的私钥
│   └── master.pem
└── public_keys                     #当前节点公钥
    └── master.pem

也可以通过下面的命令查看/签发/撤销/清除证书，细节请看在线文档

puppet cert list                                         #显示等待签署的证书
puppet cert list -a                                     #显示所有的证书， 结果中+开始的行表示已经签发（sign）的证书，-的行表示已经撤销（revoke）的证书，没有+/-的行是已经提交申请，等待被签发的证书
puppet cert sign -a|<hostname>              #签署所有的或者特定节点的证书
puppet cert clean -a|<hostname>            #物理上删除该证书所有文件。没有证书，agent会连接master失败
puppet cert revoke -a|<hostname>         #撤销证书。Pupet将证数加入ca_crl.pem，但是不删除物理文件。效果与clean相同，导致agent连接master失败   
puppet config print ssldir --section agent        #显示ssldir的值

如果证书被意外清除或者撤销，可以重新生成，细节请看在线文档

1 在master上清除证书记录和相关物理文件

puppet cert clean <certname>

2 停止agent进程，例如

puppet resource service puppet ensure=stopped

3 在agent节点上找到证书目录(默认是/var/lib/puppet/ssl)

puppet config print ssldir --section agent

4 在agent节点上手工删除$ssldir目录

5 在agent节点重新启动agent,这一过程会自动提交证书申请

puppet resource service pe-puppet ensure=running

6 在master上签署证书

puppet cert list 
puppet cert sign <certname>

如果有很多管理节点，也可以使用autosign来自动签发证书，细节请看在线文档

1 在master上修改puppet.conf

[main] 
autosign=true  #允许autosign

2 在master上修改/etc/puppet/autosign.conf，创建白名单

*.scratch.example.com   #master自动签发名字（certname）以scratch.example.com结束的证书

Plugin（在线文档）

plugin可以让用户扩展或者自定义的一些功能，比如fact，resource type，provider。plugin用Ruby编写，随module保存和发布，可供同一module中其他代码调用。

在agent端的puppet.conf中，当pluginsync=true 的时候，agent会在每次检查时自动下载master上的所有plugin。

[agent] 
pluginsync=true       #从3.0,默认打开

注意：agent需要对master URI（/file_metadata和/file_content）有读权限，以下载plugin文件。权限设置在auth.conf中。默认是所有agent对这些URI都有所需权限。

plugin的目录结构如下

{modulepath}
└── {module}
    └── lib                                               #plugin目录
         |── augeas
         │   └── lenses        
        ├── facter                                     #plugin提供的额外fact
        └── puppet                                        
            ├── parser                                #plugin指定parser的行为 
            │   └── functions
            ├── provider                              #plugin指定provider的对各resource type的行为           
             |   ├── exec                
             |   ├── package
             |   └── etc... (any resource type)
            └── type                                     #plugin提供的额外类型

Facts（在线文档）

facts是指节点上的一系列系统信息，比如hostname, IP。这些信息可以被manifest或者template使用，用来做系统相关的判断或配置。

使用facts一个途径是安装facter包，可以通过系统的包管理器软件安装，比如在Redhat Linux上, 运行"yum install facter"。此外，也可以通过plugin创建定制的facts

如果想了解facter可以返回哪些facts，运行"facter -p" 或者参考在线文档

在Puppet语言中，facts是处于top-scope，可以被所有manifest使用

内置变量（在线文档）

agent提供的变量

$clientcert - agent                 #节点证书名。默认是节点FQDN(等于变量$::fqdn)。与puppet.conf中的certname一致
$clientversion                       #agent 版本
$environment                       #environment值

master提供的变量

$servername,                      #master的FQDN
$serverip                             #master的IP
$serverversion                    #master 版本
$settings::<name>              #master的puppet.conf中的所有设置
$environment                      #environment值

在Puppet语言中，这些变量都是是处于top-scope，可以被所有manifest使用

Environment

Puppet可以同时管理多个相互隔离的环境，比如production, testing, development，并为它们提供不同的配置。这个功能可以通过定义environment来实现。

注意：Puppet默认运行在production environment中，不需要特别设置。

最新的Puppet版本中使用directory environment，也就是为每个environment设置不同的目录将他们的manifest文件隔离开。

1  在master的puppet.conf里进行以下设置，细节请看在线文档

[main]
environmentpath = /etc/puppet/environments            #所有environment在master上的父目录
#以下为可选配置。不设置会使用默认值
basemodulepath = /etc/puppet/modules                  #所有environment都可以访问的module，用于放置所有environment共享的module
default_manifest = ./manifests                                 #定义manifest路径，默认值./manifests 是指使用当前environment下的manifests目录。如果设置为绝对路径，就意味着所有environment都使用同一个manifests目录
disable_per_environment_manifest=false                #每个enviornment是否使用自己的的manifest子目录。默认是false,如果设置为true, 所有environment是共享同一个manifest目录，同时default_manifest必须是绝对路径

2  在master上为每个environment创建目录，细节请看在线文档

$environmentpath
    |── {environment name}                                  #环境名，比如testing或者其他名字
      |── manifests                                                 #当前环境中的所有manifest的父目录
      |    |── site.pp                                                 #当前环境中的site.pp
      |── modules                                                   #当前环境中的所有module的父目录
      |    |── {module name}                                   #当前环境中的module
      |── environment.conf                                     #environment配置文件，默认不创建。如果当前environment需要使用与puppet.conf中不同的设置，可以在environment.conf中进行设置。可设置项包括modulepath, manifest, config_version,environment_timeout

3  在agent的puppet.conf里设置

[agent]
environment=<environment name>                        #说明agent要获取哪个environment的中的配置。等同于puppet agent --environment <environment name>。 如果这个environment在master上不存在，agent将无法获取catalog。

4 重新启动agent

节点分类(node classification)

生成catalog的第一步是必须找到agent节点的配置里使用了哪些class和resource。这个过程称为节点分类(node classification)。

默认的方式使用site.pp中的静态配置，其默认路径是/etc/puppet/manifests/. 如果environment被设置了，请查看enviornment相关设置来确定site.pp位置

node 'web01' , 'web02' , 'web03' {   #节点名称，可以是一个或者多个名字，也可以是表达式，比如 node /^www\d+$/ { ... }
  include apache                             #节点中声明的class
}

另一种方式是使用ENC(External Node classifier)。这种方式提供一个外部的数据源来存储节点定义，例如PuppetDashBoard, The Foreman and PuppetEnterprise。同时，它会提供一个程序。master可以调用这个程序并输入节点FQDN名作为参数，然后这个程序会返回一个YAML格式的文件，其中包含节点需要使用的class和resource。这个程序可以是由任何语言编写。

使用这个功能，需要在master的puppet.conf里进行配置

[master]
node_terminus = exec                                        #使用ENC
external_nodes = /etc/puppet/node.rb               #外部程序路径。

Catalog

每个catalog就是一个节点的所有配置信息的集合，包含这个节点所分配的所有class, resource,file等等。catalog由master编译manifest而成，并由agent在目标节点上应用。

catalog本身是一个JSON格式的文件，在agent上保存在/var/lib/puppet/client_data/catalog/$certname.json

在master上，manifest以module的方式组织保存，其目录结构如下。详情请见在线文档

$modulepath                                    #module总目录，可以由puppet.conf中的modulepath指定
     ├── {module name}                   #某个module的目录，以module名命名
           ├── manifests                      #manifests目录
           │       └── init.pass              #module自加载的起始文件，包含一个与module同名的class
           ├── files                              #静态文件。source => "puppet:///modules/<module name>/<file name>" 就是指向这个目录
           ├── templates                     #template文件。content=>template ("<module name>/<template file name>" ) 就是指向这个目录
           ├── lib                                 #plugin目录
           ├── spec                             #plugin文档
           ├── tests                            #manifest文档

Mount Point

在使用file resource的source属性时，需要指定源文件的路径。这个源文件所在目录就是mount point。

如果源文件不在module的files子目录下，就需要手工配置

1 在master的fileserver.conf设置mount point，具体设置请看在线文档

[mydir]                                    #mount point名称
path /tmp/mydir                      #对应的master上的物理目录
allow *                                    #节点级ACL。这个例子中，允许任何节点访问，也可以使用allow_ip/deny/deny_ip进行其他设置

2  如果想进行更小粒度的ACL控制，需要在master上设置auth.conf。具体设置请看在线文档

path ~ ^/file_(metadata|content)/mydir/                          #mount point的URI, agent通过这个URI将文件“拉”到本地
auth yes                                                                        #必须进行证书认证
method find                                                                   #允许读
allow mynode.example.com                                           #允许mynode.example.com访问

3  因为master一般是以puppet用户运行，所以puppet用户对/tmp/mydir必须至少有读权限，可以用Linux命令chmod或者chown来设置。