柴少的官方网站 技术在学习中进步,水平在分享中升华

puppet系列(一)之puppet的部署、配置文件以及命令详解

一、puppet的介绍(文字解释部分参考了权威指南)

       作为自动化运维管理老大哥级别的软件,这个词大家都很熟悉了,我也就不阐述什么发展史啊,跟其他工具的对比了。不过有一点是要注意的,puppet分为社区版和企业版。我们应该用的都是社区版,很多博客写得还是社区版2系列的,现在已经到3系列了,区别还是有一些的,这里就直接记录3系列的社区版本了。企业版已经是4系列了。怎么区分社区版和企业版呢,除了网上了解,还可以安装完之后看目录,如果目录是/etc/puppetlabs就说明是企业版,如果安装完之后目录是/etc/puppet就是社区版。Master版本一定要高于Agent。Puppet2.6.0版本之后才支持微软Windows系列操作系统,并且只支持file资源符。

1.1 puppet工作模型

Puppet工作模型主要分为三层:分别是部署和调度层、配置语言和资源抽象层、事务层。

(1)部署和调度层:

        Puppet master在一台机器上以守护进程的方式运行,同时还包含各种客户端节点的配置信息。Agent在与master通信的过程中,通过标准的SSL协议进行加密和验证,验证通过后,Agent从Master上读取相应的节点配置信息。需要注意的是:并不是每次连接agent都会从master上读取信息,只有该节点在master上配置信息发送变化时才会被读取。

       如果客户端启动了puppet服务,默认情况下agent每30分钟连接一次master,当然配置文件也可以修改去同步的时间。有的通过crontab的方式管理。

(2)配置语言及资源调度层

       Puppet使用描述性语言来定义配置项,在Puppet中将配置项被称为资源。描述性语言还可以声明配置的状态,例如一个软件安装、配置、启动的各环节、上下游依赖关系等。

当agent连接Master时,Master并不知道Agent的操作系统型号和版本。Agent通过Facter工具收集系统相关信息,并通过SSL协议将Agent的信息传递给Master。Master根据Agent收集到的相关信息,通过资源的提供者来为agent服务。

(3)事务层

      Puppet事务层其实就是它的解析引擎。Puppet事务层配置每一台主机的过程包括以下4步。

      步骤1:解析和配置编译。

      步骤2:将编译好的配置同步到Agent。

      步骤3:在Agent上应用配置。

      步骤4:向Master报告运行结果。

      首先Puppet会创建一个图表来表示所有资源的关系和上下级执行顺序,以及和Agent的关系。然后Puppet将按照资源之间的关系和上下游顺序依次执行。

     接着Puppet为每一个Agent获取相应的资源,并把它们编译成“目录”,然后将目录依次分发到各主机,并通过Agent来应用它们,最后应用结果以报告形式反馈给Master。注意:Puppet并不是完全的事务,因为事务会记录日志,而Puppet并没有记录日志,也无法将数据库那样进行回滚。

1.2 puppet的工作流程

第一步:agent访问master建立访问信任关系,流程中包括master对agent证书授权签名(第一次访问的时候),以后就是对证书的验证,通过后master端就准许agent访问指定的资源。

第二步:建立信任关系后master调用agent的facter,获取agent主机的一些机器信息变量,如主机名、IP地址等。agent将这些信息通过SSL加密传输发送到master,master以变量名形式获取这些信息并使用。

第三步:master接收agent的主机信息请求,并将它们发送到本机的manifests或ENC(外部节点分类器),ENC包括Python,Ruby和shell等,只要支持yaml格式都可以,然后进行配置信息查询。

第四步:master根据agent的HOSTNAME匹配到相应的Node节点。整个解析过程分为语法检查,如果语法错误则停止并报错,否则继续解析最终编译生成catalog。

第五步:agent接收到catalog后,再本机应用master的配置信息。

第六步:根据接收到的catalog中的信息判断agent在执行时有没有file文件要从master推送到agent,如果有则向master fileserver发起请求获取文件。

第七步:将agent的信息以报告形式上报master。python2.6及以下的版本需要配置文件中加reports=ture参数才可以,puppet2.7以上默认开启。

第八步:整个流程结束

博文来自:www.51niux.com

二、puppet服务端与客户端的安装

2.1 编译安装(官方不推荐这种方式,个人也不推荐,在实际编译过程中可能会随着操作系统版本的不同出现不同的问题)

# yum install ruby ruby-libs ruby-shadow -y

# wget downloads.puppetlabs.com/facter/facter-2.4.0.tar.gz

# tar zxf facter-2.4.0.tar.gz

# cd facter-2.4.0

# ruby  install.rb  #当然可以通过ruby install.rb --destdir=/usr/local/puppet指定安装位置


#wget downloads.puppetlabs.com/hiera/hiera-3.3.1.tar.gz

#tar zxf hiera-3.3.1.tar.gz

#cd hiera-3.3.1

#ruby  install.rb

#wget downloads.puppetlabs.com/puppet/puppet-3.8.7.tar.gz

#tar zxf puppet-3.8.7.tar.gz

#cd puppet-3.8.7

#ruby  install.rb

注意:puppet源码编译安装后,切莫急着删除源码包,可以将源码包中的配置,如puppet.conf、auth.conf、fileserver.conf和tagmail.conf模板文件复制到/etc/puppet目录下。

# mkdir /etc/puppet

# cp conf/* /etc/puppet

# cp  ext/redhat/server.init  /etc/init.d/puppetmaster

# cp ext/redhat/client.init /etc/init.d/puppet

# chmod +x /etc/init.d/puppetmaster

# chmod +x /etc/init.d/puppet

注:编译安装客户端和服务端是一致的,区别是配置文件里面的设置,以及server服务的启动。

2.2 yum安装方式

http://yum.puppetlabs.com/ #官网yum源目录,以及安装包url地址。

我在实际生产环境中是用的yum安装这种形式,当然随着系统版本的不同,所需要的软件包组以及软件包的版本也是有不同的。我的做法是搭建了yum源服务器,做了一个epel源的仓库,这样可以适应不同系统版本的yum安装。yum源服务器已经在别的文章里面讲述了,这里就不过多累述了。

#yum install ruby ruby-libs ruby-shadow -y

# rpm -Uvh http://yum.puppetlabs.com/puppetlabs-release-el-6.noarch.rpm  #这是安装puppet的安装源,如果我们做了yum源服务器就不需要这步
# yum install puppet puppet-server facter -y  #服务器端的操作

#yum install puppet  facter -y #客户端的操作

# puppet -V  #检查版本
3.8.7

# service puppet start  #启动客户端服务

# service puppetmaster start  #启动服务端服务

图片.png

三、puppet目录结构及文件介绍

不管是yum安装还是编译安装,/etc/puppet目录里面也没啥文件了,客户端还好,基本启动服务在,有puppet命令,有puppet.conf文件就可以了。服务器还是有好多要设置的,这就需要我们自己手工创建和拷贝了。

3.1 puppet的目录结构

/etc/puppet  #目录是puppet的主配置文件的根目录

     --auth.conf  #agent访问master的权限认证文件。

     --autosign.conf  #master对agent证书自动签名的配置文件

     --files/  

            --fileserver.conf #master向agent同步静态文件的配置文件

     --manifests/ #入口的导航文件与逻辑文件等。此目录中存放的文件又称为清单文件。

            --site.pp  #puppet主文件(入口文件)

      --module/ #基础模块目录。

      --puppet.conf #MASTER守护进程的主要配置文件

      --ssl/ #数字证书文件的缓存目录,master在此目录存放CA证书和已签名授权的Agent证书文件列表,agent在此目录存放被master授权的证书文件。

      --tagmail.conf #puppet邮件发送配置文件

      --namespaceauth.conf #名称空间配置文件

3.2 配置主配置文件的介绍

其他的文件会在后面的部署搭建操作中进行介绍,那样会更直观一点。

3.2.1 puppet.conf服务端文件的介绍

# puppet master --genconfig  #就会将master的所有配置选项都列出来,我们可以>到一个文件中,可以去查看其它的参数选项和介绍,但是实际情况我们并不需要如此全面的配置文件,只会用到很少的一部分,大部分的选项还是使用默认的。

# cat /etc/puppet/puppet.conf

[main]      #用于puppet全局配置

logdir = /var/log/puppet   #puppet日志的存放位置

rundir = /var/run/puppet   #puppet进程pid文件存放目录

ssldir = $vardir/ssl  #ssl证书存放位置

autoflush = false #是否实时刷新日志到磁盘

[master]   #服务端的配置,puppet.conf配置文件里面通常有[main]全局区域,[master]区域或[agent]区域

reportdir = /var/lib/puppet/reports  #报告存放目录,客户端的每次执行会生成一份以日志+时间命令的yaml文件报告
autosign = true  #自动授权签名配置文件
autosign = /etc/puppet/autosign.conf  #用于是否自动签发,默认是false
bindaddress = 0.0.0.0  #服务器监听地址
masterport = 8140  #服务器监听端口

reports = store  #上传的方式报告的方式,默认就是store,默认就是写到服务器本地的磁盘,如果没有其他设置如上传到http报告服务器,等这里也可以不填写。

evaltrace = true  #通过此参数看到执行中的过程与变化
manifest = /etc/puppet/manifests/site.pp  #agent连接master端的起始配置目录
modulepath = /etc/puppet/modules  #modules基础模块与配置文件存放路径

certname = 服务器端的名称

#certname不定义的的话,客户端在与服务器端同步的时候会报下面的错误:

Error: Could not send report: Server hostname 'master.puppet' did not match server certificate; expected localhost

3.2.2 puppet.conf客户端文件的介绍(# puppet agent --genconfig 可以查看更详细的配置信息和注释)

[main]      #用于puppet全局配置

logdir = /var/log/puppet   #puppet日志的存放位置

rundir = /var/run/puppet   #puppet进程pid文件存放目录

ssldir = $vardir/ssl  #ssl证书存放位置

autoflush = false #是否实时刷新日志到磁盘
[agent]                 #客户端的配置

certname = 客户端的名称或者客户端的IP地址
daemonize = true #后台运行
allow_duplicate_certs = true #是否允许证书自动覆盖,默认不允许的,每个证书的有效期为5年。
report = true #上传客户端对resouces的执行结果,2.7以上自动开启
report_server = 上传的地址(主机名或者域名)    #这里主要是针对puppetmaster做了负载均衡,想将上传报告汇聚于一个服务器的时候,或者汇聚到某一个报告服务器的时候。所以如果单master可以不写这一项。
report_port = 8140  #上传的端口(默认端口是8140的话可以不设置)
runinterval = 9000m #客户端执行间隔9000分钟,默认是30分钟
splay = true #是否在执行时间上另加一个随机时间
splaylimit = 10m #加的随机时间的最大长度
configtimeout = 2m #客户端获取配置超时时间
color = ansi #日志记录是否加颜色
ignorecache = true #是否忽略本地缓存
classfile = $vardir/classes.txt #关联与检索配置文件目录

ocalconfig = $vardir/localconfig  #本地缓存配置目录

server = 服务器端名称 

3.2.3  autosign.conf 文件介绍

需要手工创建,用于自动签名证书功能。通过master上的autosign.conf配置文件。可以实现对某一来源或所有来源的agent做自动授权证书签名。

# cat /etc/puppet/autosign.conf  #*代表允许所有,也可以指定IP段等。
*

3.2.4 auth.conf文件介绍

Master会根据auth.conf配置文件来限制agent的来源(来源包括IP、域名或环境列表等)。为了网络访问安全,agent再访问master过程中,其使用https协议进行通信交互,基本的访问格式如下:https://{server}:{port}/{environment}/{resource}/{key}

auth.conf权限控制列表格式:

图片.png

auth.conf配置文件格式包含7个参数,分别是path、environment、method、auth、allow、allow_ip和deny,每个参数都有自己独立的值,通过这7个参数的自由组合,就形成了agent访问master目录权限控制的ACL。

path:指定ACL的路径。Path后接系统路径、正则表达式、路径前缀和资源等信息。

environment : 它可以包含一个环境或多个环境列表,如果不设置则默认为所有环境。

method : 包含find、search、save和destroy(销毁),多参数用逗号隔开

auth:包含yes或no,any和no或off。默认是yes或on.auth设置成yes或on均表示匹配那些已经通过认证的agent请求。Auth设置成any意味着只匹配认证进行中和没有被认证的请求。Auth设置no或off,均表示匹配未认证过的agent请求。认证过的请求会跳过此ACL。

allow : 值可以是hostname或certname.2.7.1以后的版本还支持正则表达式。

allow_ip:接一个IP或者IP网段,表示允许那些IP范围通过

deny:接一个IP或者多个IP,网段或域名等,表示禁止这些范围访问master的目录权限。

# cat /etc/puppet/auth.conf #里面的注释部分有很多例子

3.2.5 fileserver.conf配置文件介绍

fileserver.conf是master目录的挂载配置文件,它包含了master的挂载目录位置和挂载目录的授权信息,只有agent服务器从master获取一个文件或文件列表时才会用到它。文件同步不要大于1MB的数据文件,puppet虽然有实现同步静态文件的功能,但其并未使用专业的文件同步数据协议,如果多个agent同时同步比较大的数据,就会引起master超时,最终导致同步失败。

举例:

[files] 
path /etc/puppet/files
allow 192.168.1.0/24

3.2.6 客户端puppet.conf的实际配置实例:

# cat /etc/puppet/puppet.conf
[main]
    logdir = /var/log/puppet
    rundir = /var/run/puppet
    ssldir = $vardir/ssl
[agent]
certname = 192.168.1.111  #这里的名称应该是唯一的,不然去master服务器去认证证书的时候,服务端那边已经有了此名称的证书,你就验证不过去了。所以这里一般以主机名来命名。
daemonize = true
allow_duplicate_certs = true
report = true
reports = store,http
report_server = master.hadoop
report_port = 8140
runinterval = 20m
splay = true
splaylimit = 10m
configtimeout = 2m
color = ansi
ignorecache = true
classfile = $vardir/classes.txt
ocalconfig = $vardir/localconfig
server = master.hadoop

# puppet agent -t  #在客户端执行此命令,第一次访问就是申请证书建立访问通信的机制。如果是服务器端还没有定义什么规则的前提下。

图片.png

#从上图可以看出,没有红色的报警就说明是没有出错的。

下面是服务器端的证书文件查看截图:

图片.png

博文来自:www.51niux.com

3.3  命令介绍

puppet 2.6之后的版本,将所有功能集成到了一个单独的二进制程序,即puppet。

# puppet help
agent             #agent守护进程
apply             #在本地申请Puppet清单
ca                #管理本地证书文件
catalog           #编译、保持、查看和转换catalog
cert              #管理证书和请求
certificate       #提供对CA进行证书管理的访问。  certificate_request  #管理证书请求
certificate_revocation_list  #管理已撤销证书的列表。
config            #配置选项
describe          #显示有关资源类型的帮助
device            #管理远程网络设备
doc               #生成Puppet文档和引用
facts             #存储facter返回信息
file              #检索并将文件存储在filebucket中
filebucket        #存储和检索文件中的文件
help              #显示帮助手册信息
inspect           #发送检查报告
instrumentation_data  #管理监听数据
instrumentation_listener  #管理监听状态
instrumentation_probe  #管理监听探测
key              #创建、保持和删除证书的秘钥文件
kick              #gant主动更新工具
man               #显示帮助手册信息
master            #master守护进程
module            #通过puppet forge创建、安装和查找基础模块
node              #查找与管理节点
parser            #*.pp文件语法检查
plugin            #插件管理
queue             #puppet队列
report            #创建、显示和提交报告
resource          #资源抽象层shell
resource_type     #查看类、定义的资源类型和所有清单中的节点。  secret_agent        #模拟agent
status            #查看服务状态

独立命令:

pi:资源帮助文档(puppet describe)

puppetdoc:文档生成工具(puppet doc)

puppetmasterd:守护进程(puppet master)

puppetrun:客户端更新工具(puppet kick)

puppetqd:对了命令(puppet queue)

puppet:agent守护进程(puppet agent)

puppetca:证书文件授权命令(puppet cert)

filebucket:远程备份恢复工具(puppet filebucket)

ralsh:puppet资源抽象工具(puppet resource)

3.3.1 agent命令介绍(Agent访问Master获取配置信息的命令。)

# puppet agent -h   #查看命令使用帮助

puppet agent [--certname <NAME>] [-D|--daemonize|--no-daemonize]
  [-d|--debug] [--detailed-exitcodes] [--digest <DIGEST>] [--disable [MESSAGE]] [--enable]
  [--fingerprint] [-h|--help] [-l|--logdest syslog|eventlog|<FILE>|console]
  [--masterport <PORT>] [--no-client] [--noop] [-o|--onetime] [-t|--test]
  [-v|--verbose] [-V|--version] [-w|--waitforcert <SECONDS>]

--certname : 设置客户端的certname(唯一ID)。 主机读取此唯一标识字符串,通常将其设置为节点的完全限定域名,以确定节点将接收哪些配置。 使用此选项来调试设置问题或实现异常节点识别方案。 (这是一个Puppet设置,一般写在puppet.conf。)

-D|--daemonize:将进程发送到后台。 这是默认值。也可以写入到puppet.conf。

--no-daemonize:不要将进程发送到后台。

-d|--debug : 打开puppet调试模式,输出启动过程中的调试信息。

--detailed-exitcodes : 详细信息退出码。通过退出代码提供交易信息。 如果启用,退出代码“2”表示有更改,退出代码“4”表示事务中出现故障,退出代码为“6”表示存在更改和失败。

--digest : 更改证书指纹摘要算法。 默认值为SHA256。 有效值取决于安装的OpenSSL版本,但可能包含MD5,MD2,SHA1和SHA256。

--disable:会在agent机器上建立一个锁定文件,在锁定文件没有删除之前,agent并不会将master获取的配置信息应用到本机,此命令可以防止agent守护进程重复执行

--enable:清理锁定文件,并回复puppet的正常工作状态。

--fingerprint:  显示当前证书或证书签名请求指纹,然后退出。 使用'--digest'选项来更改所使用的摘要算法。

-h|--help:打印此帮助信息。

-l|--logdest: 在哪里发送日志消息。 选择'syslog'(POSIX syslog)服务),'eventlog'(Windows事件日志),“控制台”或日志的路径文件。 如果启用调试或详细功能,则默认为“控制台”。
   否则,它默认为POSIX系统上的“syslog”和Windows上的“eventlog”。

--masterport:服务端的连接端口,一般写在puppet.conf文件中。

--no-client:不要创建配置客户端。 这将导致守护进程启动但不检查配置,除非它被“puppet kick”触发。 只有在puppet.conf中使用listen = true运行监听,或者使用`--listen`选项启动时才有意义。

--noop:此参数又被称为puppet的dry run模式,在此模式下运行主机不会做出任何变更,但是它会告诉你本次执行中puppet都做了些什么,根据dry run模式输出结果来查看是否和我们的预期一致。

--onetime:让puppet agent运行一次就停止。

-t|--test:一些命令的集合,通过--test可以打开onetime、verbose\ignorecache\no-daemonize\no-usecacheonfailure\detailed-exit-codes\no-splay和show diff等参数。

--verbose:输出puppet扩展信息。

--version:打印版本信息并退出。

 --waitforcert: 此选项仅对尚未具有证书的守护程序有效,默认情况下启用,值为120(秒)。 这会导致“puppet agent”每2分钟连接一次服务器,并要求它签署一个证书请求。 这对于初始设置木偶客户端是有用的。 您可以通过指定时间0来关闭等待证书。可以写入到puppet.conf配置文件里面去。不过就在签名的时候有作用也没必要写进去。

environments:后面接puppet环境参数,此功能主要用于配置文件的灰度。

3.3.2 apply 命令介绍(单独执行代码的工具,在本机运行以.pp结尾的程序。单机运行工具。)

puppet apply [-h|--help] [-V|--version] [-d|--debug] [-v|--verbose]
  [-e|--execute] [--detailed-exitcodes] [-L|--loadclasses]
  [-l|--logdest syslog|eventlog|<FILE>|console] [--noop]
  [--catalog <catalog>] [--write-catalog-summary] <file>

--genconfig : 生成配置文件选项

-d|--debug:打开puppet调试模式,输出执行过程中的调试信息

--detailed-exitcodes:详细信息退出码。通过退出代码提供交易信息。 如果启用,则退出代码为“2”表示有更改,退出代码为“4”表示事务中出现故障,退出代码为“6”表示存在变更和失败。

-h|--help:打印帮助信息。

--loadclasses:加载任何存储的类。”puppet agent”缓存配置的类(通常在/etc/puppet/classes.txt),并且设置此选项将导致所有这些类在您的puppet中设置。

-l|--logdest : 将输出的信息输出到指定文件,默认是输出到屏幕

--noop : 此参数又被称为puppet的dry run模式,在此模式下运行主机不会做出任何变更,但是它会告诉你本次执行中puppet都做了些什么,根据dry run模式输出结果来查看是否和我们的预期一致。

--execute : 用于执行puppet代码片段

-t|--test : 一些命令的集合,通过--test可以打开onetime、verbose\ignorecache\no-daemonize\no-usecacheonfailure\detailed-exit-codes\no-splay和show diff等参数。

--verbose:输出puppet扩展信息。

--catalog:接JSON格式的文件或从标准输入导入JSON格式的数据,目前catalog参数已经取代了apply的功能。注意,通过puppet master --compile可以生成JSON格式的数据,然后通过puppet apply工具实现catalog参数接JSON格式数据。

--write-catalog-summary:  编译目录后,将资源列表和类列表保存到节点在名为classes.txt和resources.txt的状态目录中

例子:

puppet apply -l /tmp/manifest.log manifest.pp
puppet apply --modulepath=/root/dev/modules -e "include ntpd::server"
puppet apply --catalog catalog.json

3.3.3 cert 命令介绍(管理证书和请求)

Agent访问master时使用的是SSL安全套接字,其优点是加密双方的通信数据,从而保证信息安全。首次访问需要Master对agent证书签名才可以正常建立SSL通信,所以首次连接需要先通过puppet cert命令在master上对agent的数字证书签字。通过puppet cert命令可以实现管理、授权、回收、显示和产生签名文件。

# puppet cert -h

puppet cert <action> [-h|--help] [-V|--version] [-d|--debug] [-v|--verbose]
  [--digest <digest>] [<host>]


动作:
clean:清理master主机上存储的所有相关证书文件。后面跟主机名的话只会清除某个主机的,如果指定了'--all',则所有主机证书(包括签名和无符号)将被删除。

fingerprint:打印主机证书的DIGEST(默认为签名算法)指纹。

generate:为指定域名授权签发一个证书文件

list:在master上可以列出目前agent机器等待签发证书的信息

print:打印证书的版本信息

revoke:回收指定agent的证书,请注意,在吊销证书后,需要重新启动master服务。

sign:通过等待的证书进行签名。后面跟申请主机名的话只是对此主机进行证书签发,如果指定--all就是对所有的请求进行证书签发。

verify : 确认证书是否由本地CA签发。

reinventory: 建立已颁发证书的清单。 这将破坏由'cert_inventory'指定的当前库存文件,并从'certdir'中找到的证书重新创建。 在执行此操作之前,请确保master服务已停止。

注:有一个问题我也不知道怎么用命令解决只能采取一个粗暴的方法来解决了。就是如果有的证书申请,我们没有通过签发,用上述的参数不能对这个请求进行操作,因为它是未认证的请求,如localhost的证书请求:

# puppet cert list -all  #这种请求,如果不清除,如果堆积多了看着也很不爽,怎么把这种请求去掉呢。

  "localhost"     (SHA256) 3B:97:32:0D:0A:0E:61:CE:22:AA:54:A7:71:C5:57:47:9C:50:66:20:85:3C:22:9E:BE:31:FF:D8:B4:89:42:A2

粗糙的解决办法:/var/lib/puppet/ssl/ca/requests/这个目录里面存放着,没有被签发的证书请求,我们可以采取删除此目录下文件对应文件的形式,来清除我们不想签发的证书请求。如:# rm -rf /var/lib/puppet/ssl/ca/requests/localhost.pem  。然后再# puppet cert list -all  查看就没有了。

3.3.4 master命令介绍

Puppet master是master守护进程命令,启动后默认以TCP协议监听在8140端口上。它的工作原理是通过Ruby的Webrick Web接收agent服务器的请求,根据请求内容与master上的site.pp文件进行匹配,并根据site.pp文件内存编译成catalog向agent分发,在agent上应用这些配置信息。其实master的守护进程还有另外一种启动形式,就是通过service puppetmasterd start启动。这种方式启动简单,但是出问题不容易发现,如文件不存在,守护进程是无法启动的,而也不会报错。

# puppet master -h

puppet master [-D|--daemonize|--no-daemonize] [-d|--debug] [-h|--help]
  [-l|--logdest syslog|<FILE>|console] [-v|--verbose] [-V|--version]
  [--compile <NODE-NAME>]

--genconfig:将配置信息打印出来

-D|--daemonize:将进程发送到后台运行,是master的默认参数。

--no-daemonize:将进程输出信息发送到标准输出。

-d|--debug:打开调试信息

-h|--help : 打印帮助信息

-l|--logdest:指定输出日志的路径和文件名,默认是发送到屏幕终端。

--masterport:自定义监听端口,这个一般在配置文件中定义。

-v|--verbose:输出扩展信息

-V|--version:显示master的版本信息

--compile <NODE-NAME>:将编译后的catalog以JSON格式输出到$vardir/yaml/目录下。NODE-NAME是agent的hostname,它的输出结果为JSON格式输出,它将导入puppet apply中使用。

pidfile:master在监听多端口时的pid文件不能公用,所以要通过pidfile参数指定不同的pid文件位置。

当作为独立守护进程运行时,服务端接受以下信号:
SIGHUP:重新启动puppet主服务器。
SIGINT和SIGTERM:关闭puppet主服务器。
SIGUSR2:关闭日志文件的文件描述符并重新打开它们。 与logrotate一起使用。

3.3.5 module命令介绍

Puppet module是Puppet的基础工具,它包含下载、更新、查找、升级和创建基础模块等功能。我们会经常用到它的查找基础模块功能,它可以从puppet forge上查找已经开发好的puppet基础模块代码来为我们所用,以减少重复劳动,并提升工作效率。

# man puppet-module  #可以查看此命令的man帮助

# puppet help module

选项:

--verbose : 是否详细登录。

--debug : 是否记录调试信息。

--environment production : 这个可以一般写在配置文件里面,这里指定环境默认是生产环境。

--modulepath $basemodulepath:模块的搜索路径,作为由系统路径分隔符分隔的目录列表。 (POSIX路径分隔符为':',Windows路径分隔符为';'。)已弃用在puppet.conf中设置modulepath的全局值。 请改用目录环境。 如果您需要使用除“<ACTIVE ENVIRONMENT'S MODULES DIR”:$ basemodulepath“的默认模块路径之外的其他内容,则可以在environment.conf中设置”modulepath“。

动作:

build : 构建模块发行包。

changes:示已安装模块的已修改文件。

generate:创建标准的基础模块目录结构

install:安装puppet forge的基础模块

list:以树形结构显示现有的基础模块(结果输出类似tree命令)

search:在puppet forge中查找基础模块

uninstall:删除已经安装的基础模块

upgrade:升级已经安装的基础模块

3.3.6 resource命令介绍

这是资源抽象层的shell,通过它可以将当前系统状态转换为puppet的代码,并且它还具有将当前的系统状态改变为puppet ral状态等功能。

puppet resource [-h|--help] [-d|--debug] [-v|--verbose] [-e|--edit]
  [-H|--host <host>] [-p|--param <parameter>] [-t|--types] <type>
  [<name>] [<attribute>=<value> ...]


--debug : 打开调试信息开关

--edit : 将查询结果写入文件中,在编辑器中打开这一文件,并且以puppet代码的表现形式复述这一文件。

--host : 指定之后,连接到已命名主机的资源服务器,获取指定类型资源列表。

--param:添加更多参数以进行查询输出

--types : 列出所有可获得的类型

--verbose : 输出扩展信息

3.3.7 doc命令介绍

将puppet代码中注释转换为文档的工具。它可以为puppet语言、节点和类创建帮助文档,从而使那些对系统生疏的人快速了解系统。

# puppet doc -h
puppet doc [-a|--all] [-h|--help] [-l|--list] [-o|--outputdir <rdoc-outputdir>]
  [-m|--mode text|pdf|rdoc] [-r|--reference <reference-name>]
  [--charset <charset>] [<manifest-file>]


--all:在rdoc模式下,此参数可以输出详细的文档资源类型。

--outputdir:生成文档的输出路径,此参数只支持rdoc模式。

--mode:后接输出模式,后接doc支持的输出模式包括text、pdf和rdoc,默认模式是text模式。如果使用rdoc模式,则需要提供manifests-path路径。

--reference:生成特定的文档信息。

--charset:设置字符集,此参数只支持rdoc模式。

--manifestdir:设置puppet的manifests路径,如果不设置此参数,它会在puppet.conf寻找manifestdir默认路径。此参数只支持rdoc模式。

--modulepath:设置puppet的基础模块路径,如果不设置此参数,它会在puppet.conf寻找modulepath默认路径。此参数只支持rdoc模式。

--environment: 仅用于'rdoc'模式。 的配置环境读取所述设置时读取modulepath和manifestdir设置来自puppet.conf。

3.3.8 kick命令介绍

远程agent管理控制工具,通过它可以主动要求某台服务器更新配置,而且它支持查看agent存活状态。

puppet kick [-a|--all] [-c|--class <class>] [-d|--debug] [-f|--foreground]
  [-h|--help] [--host <host>] [--no-fqdn] [--ignoreschedules]
  [-t|--tag <tag>] [--test] [-p|--ping] <host> [<host> [...]]

--all:连接所有agent(需要ldap支持)

--class : 连接一类agent(需要ldap支持)

--debug : 打开调试信息开关

--foreground : 在前台运行每一个配置,当连接到一个agent时,只有agent端更新完毕才会退出继续执行下一个,默认是关闭的。

--host : 可以指定agent,这个可以出现多次。

--ignoreschedules : 决定客户端在运行配置的时候是否要忽视过程。这一功能可以用来强制客户端执行其原本不会执行的特别迅速的任务。默认设置是关闭的。

--parallel:并行指示每一个客户端应该连接哪一个进程,参数默认是1,也就是按照顺序依次连接每个客户端。

--puppetport :使用指定的TCP端口连接到agents。 默认为8139。

--tag : 指定一个tag(标志)来选择应用的对象。不可以与test参数一同应用。

--test : 打印可以连接的客户端,但并不会真正连接它(需要LDAP支持)

--ping:发送ICMP包到指定的客户端,并忽略那些没有回应的客户端。

3.3.9 其他命令

其他命令的使用可使用:puppet man 命令名称   来查看使用用法,如:# puppet man ca或者#man puppet-ca

博文来自:www.51niux.com

3.4 证书目录介绍

puppetmaster第一次启动会自动生成证书自动注册自己

# tree /var/lib/puppet/ssl/
/var/lib/puppet/ssl/
|-- ca
|   |-- ca_crl.pem
|   |-- ca_crt.pem
|   |-- ca_key.pem
|   |-- ca_pub.pem
|   |-- inventory.txt
|   |-- private
|   |   `-- ca.pass
|   |-- requests
|   |-- serial
|   `-- signed
|       `-- puppet.master.pem  #这里有代表已注册
|-- certificate_requests
|-- certs
|   |-- ca.pem
|   `-- puppet.master.pem
|-- crl.pem
|-- private
|-- private_keys
|   `-- puppet.master.pem
`-- public_keys
    `-- puppet.master.pem

#  puppet cert --list --all  #查看一下我们的服务器端已经注册成功了,红色的部分是两个警告,不建议再puppet.conf文件里面定义manifest和modulepath
Warning: Setting manifest is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations
   (at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1141:in `issue_deprecation_warning')
Warning: Setting modulepath is deprecated in puppet.conf. See http://links.puppetlabs.com/env-settings-deprecations
   (at /usr/share/ruby/vendor_ruby/puppet/settings.rb:1141:in `issue_deprecation_warning')

+ "puppet.master" (SHA256) 3D:11:6E:97:72:E3:4F:5E:BD:D9:27:2A:18:5F:70:FF:52:37:59:9D:81:F4:4C:01:50:19:E1:A6:4B:C1:D5:9C (alt names: "DNS:master.puppet", "DNS:puppet", "DNS:puppet.master", "DNS:puppet.puppet")


# puppet agent -t  #客户端第一次发起请求,是获取认证证书请求,因为我们服务器端已经开启了自动认证,所以不用再去服务端操作了。

图片.png
#再次上puppet服务器端查看,看到192.168.1.106已经被注册了。
图片.png

当然也可以通过tree的方式查看:

图片.png


如果删除某个主机的证书,让其重新生成证书呢,比如此机器换机房了,或者换业务了,主机名变化了,agent端的certname发生变化了:

服务器端的操作(以192.168.1.105举例):

# puppet cert clean 192.168.1.105
客户端的操作:

#find /var/lib/puppet/ssl -name 192.168.1.105.pem -delete



作者:忙碌的柴少 分类:puppet系列 浏览:19097 评论:2
留言列表
Edward
Edward 感谢作者的这两篇关于Puppet的文章,很受用,其他类似文章时间都已经非常久了。  回复
忙碌的柴少
忙碌的柴少 嗯 主要是现在都在用salt之类的,puppet确实有些老了。  回复
发表评论
来宾的头像