在使用的时候依然会遇到问题，如果有大量node需要定义，意味站点清单文件，节点需要大量定义，是否有快捷方式，多数主机都不会直接面向外部提供服务
能对外提供访问入口的主机，接入层，是负载均衡器的名称，内部节点一般都是私有地址，需要一个内部的dns服务器，用于做服务发现
既然节点在内部，就要考虑名称是否详细，而不是简洁了、
站点清单的定义：
主机名定义：
主机名(主机角色)#-机架-机房-运营商-区域.域名
www1-rack1-yz-unicom-bj.magedu.com（由小而大的格式）
Web服务器3W开头
mysql 可能是mysql开头的
同一类主机的应用应该是相似的
/etc/puppet/manifests/site.pp
node 'base' {
include ntp
}
node ‘HOSTNAME’ { 精确主机名定义
…puppet code…
}
node /PATTERN/ { 可以使用模式
…puppet code…
}
node /node[0-9]+.magedu.com/
0-9可以出现多次，可以根据pattern，来实现多个主机 共享一个
基础的服务每个主机都需要的，可以当做基节点，节点定义也可以继承的
节点定义的继承：
node NODE inherits PAR_NODE_DEF（父类） {这个节点定义好后，既有自己的配置，也继承了父类的配置
…puppet code…
}
nodes/
清单配置信息可模块化组织：
databases.d/ 所有的数据库主机
tomcatservers.d/ 所有的tomcat主机
如果有必要分开定义，把每一类主机按角色分类
nodes.d/：可通过多个pp文件分别定义各类站点的清单；而后统一导入site.pp，方法如下：
site.pp文件使用中如下配置：
import 'nodes/*.pp’
实践中应该是多环境，多环境定义，开发环境在本地公司内部网络，服务在云端，测试环境也有可能在云端，所以我们的peppet只是针对单一环境来设定 ，也只能应付一个环境，而这个环境默认叫production
对应的puppet master安装后，默认支持多环境的，可以为不同环境的主机提供不同的定义
三种环境
development 开发
testing 测试
production 生产
如果不定义环境，默认是生产环境
master如果要支持多环境配置，那么整个配置方式都要发生改变
**3.4之前配置很容易，在agent端/etc/puppet/environments/{production,development,testing}创建三个子目录
在master端，阿凯puppet.conf，加上参数environments = production, development, testing。，每一个环境都应该有自己的模块路径和站点清单
production]
modulepath=/etc/puppet/environments/production/modules/
manifest=/etc/puppet/environments/production/manifests/site.pp
1
[development]
modulepath=/etc/puppet/environments/development/modules/ 专用生成环境的模块
manifest=/etc/puppet/environments/development/manifests/site.pp 专用生产环境的站点清单
1
[testing]
modulepath=/etc/puppet/environments/testing/modules/
manifest=/etc/puppet/environments/testing/manifests/site.pp **
版本不一样的多环境配置方法是不一样的
3.6之后这么配置
master支持多环境：
(1) 配置文件puppet.conf
[master]
environmentpath = $confdir/environments（这个目录就是指环境子目录的父目录）
1
(2) 在多环境配置目录下为每个环境准备一个子目录
ENVIRONMENT_NAME/ 每一个子目录底下都应该有manifests目录
manifests/
site.pp 用于这个环境的站点清单
modules/ module 目录
要在agent端
agent端：
[agent]
environment = { production|development | testing } 指明你属于哪一个环境
接下来配置多环境
把1,2节点先停止
把master也停止
**改成多环境配置，把默认的站点清单删除，不用了
modules的下的模块也没用了，应该都在environments下的三种环境的模块中
先定义三个环境
拷贝nginx到三个环境中 **
改成一个静态文件
修改workprocess
把文件复制到其他环境目录上
默认现在两个环境，生产和开发
把它当做我们多环境配置目录
有大量默认配置
confdir默认就是/etc/puppet，参数间可以互相调用的
定义没生效
默认环境production
虽然有模块但是还没定义站点清单
各自定义一个站点清单
另外一个环境】
调用的是同一个子类，但是两个子类在不同环境中，配置文件所启动的数不一样，所以客户端分属于不同环境时，获取到的内容应该是不一样的
配置node1
+environment ，处于production环境执行
把nginx删除
用puppet安装
不能再重复定义一次，先不管
真实跑一下试试
定义的auto这一项
再次删除
只有1个子进程了
当你客户端分别属于不同环境时，不同环境可以拥有不同配置，虽然都叫nginx，不同环境中的，同一模块所拥有的配置也不尽相同
这就是puppet的多环境配置
**
额外配置文件：
文件系统：fileserver.conf master端
（只告诉哪些路径下的内容是当做fileserver定义访问的）
认证（URL）：auth.conf
这两个文件其实是定义master上的资源通过http协议来访问时，哪些url资源可以被哪些客户端访问的，一定类似于此前在httpd上，定义一个location 使用grant require all granted类似
其实就是web服务器，有些url内容比较敏感，不允许随意访问**
哪个路径下的文件，允许谁来访问
哪个路径下的什么内容，允许ip什么的来访问
auth yes代表要认证
真正认证通过auth。conf来定义
path 模式匹配 指定路径下的资源允许谁来访问
$1是引用括号中匹配到的主机地址，每个人访问只能是自己的专有地址
其实是个url，对于某个catalog（分类）url底下任意内容，每个人只能允许访问它自己 子目录，而且只允许method
find的就相当于get
哪些url的资源只允许下面哪些主机通过什么方法来获取
报告的时候是需要agent端把自己的结果报告给master端的，master 需要有一个位置来存储agent端的报告，相当于master端提供了文件共享服务，这个服务提供客户端使用put方法，用put方法去创建新的包和文件，因此这样就不能让人随意访问了，
对于report而言，每个客户端都有自己专用的子目录，在这个目录下可以用save方法，相当于put，但只允许每个人访问自己的目录
$1其实也是这个主机名
相当于每个modules下的目录
白名单
server端在签署证书的时候需要人工介入，每次都要puppet cert sign是比较麻烦的，可以set-all 没必要auto sign不然很危险
每次服务端发生改变，客户端是每隔30分钟到master端请求与自己相关的配置。，假如刚请求，服务端配置改了，那就有可能需要29分钟后才会获取到，如果想要尽快获取到，
如果能让master通知agent端，即便时间不到，也可以进行put相关配置，不过要想让服务端通知agent端，agent端也需要监听在套接字上，因为不监听无法接受别人请求
应该在agent端，定义只允许接受谁的通知，要认证，在服务端可以使用一个命令推送通知，puppet help kick
all所有主机
host指定主机
去kick的是agent的/run目录 所以agent端要允许/run的url允许使用save方法
auth any 认证所有主机
allow只能允许master主机
现在就可以配置agent端
需要放在main段
在最后配置段之前加
重启服务
修改master端的配置
发送kick信息
node1再使用ps aux，进程变为两个
kick能够让服务器主动通知agent端执行，相当于触发agent端立即来同步，不管时间是否到了
当你需要发布新版本的时候，应该定义一个符号链接指向新生成的子目录，把子目录先推过去，file类型的资源，把目录复制过去
2.再利用file类型的资源，把你对于的目标目录下的符号链接指向最新版本，这是发布新版本的
还要再定义一个资源，叫回滚。符号链接指向老版本，一旦发布完出现故障，立即写模块，手动触发上一个子目录
得到程序包新给的文件包，file类型资源，把这个新的资源推送给tomcat主机的webapps目录下，但是真正提供应用的应该是一个符号链接，这个符号链接指向的还是过去的版本，还要把这个符号链接修改一下指向新的版本
文件类资源。1.复制文件到tomcat主机上webapps目录下，2.复制后，让对应的程序主目录url，符号链接指向新版本即可，其他不用动
如果要灰度发布，站点清单中要一批一批的上去
如果一个关键的程序包出现漏洞，需要设置打补丁，所有主机都需要打，要让所有主机都执行同一个命令，或者也可以在puppet下定义i资源，这个资源就是把补丁包文件推给每一台主机，让每一台主机在本地都yuminstall
所以也可以定义模块，去让所有主机去include，
所有主机都有basenode，这时候就有好处了，所有节点都需要去继承某个基节点的定义
但是如果你的主机在线上有千台，推的话，puppet会挂掉的，但是早期美团也能用一台puppet应付线上大多数环境，如果应付不了，puppet也需要扩展
一台不行，用两台，但是比较麻烦，两台以后还需要想办法把请求反代过来
puppet是ruby语言写的，调用是rpc，所以要使用ruby语言中专用的反代工具来反代，pasenger，意味需要在nginx上调用pasenger模块反代，否则直接反代http协议是不可用的
就算反代都可以，但是两个主机各有一个CA，agent到一个主机验证可以通过，另外一个就通过不了了，还需要把ca拿出来，集中在一台服务器上实现，在前端反代的时候，还需要理解CA请求，调度到CA主机上才可以
就算不做扩展，也需要给它做高可用
高可用容易，第一台主机初始化后，/file/lib/所有文件通过NFS主机共享同步过来,NFS是单点，可以用支持挂载的分布式文件系统，有冗余能力的
即便如此在有些情况下，依然有遇到访问压力大的问题，puppet收购了一个项目，叫collectivemq，是一个socket命令，以队列方式，不至于把服务器压垮
听说性能相当优异，因此可以把puppet运行在colletcivemq之上，但是没见过哪家公司用
puppet也有web gui面本去展示报告
第三方的是foreman
开发模块参数是最主要的
假如修改了有问题，puppet最好也需要回滚
应该有自己的测试环境，开发环境来开发你的puppet模块，测试环境来测试你的有没有问题，有个主机专门开发。开发没问题了，再把你的模块同步到能puppet的master中去，同步以后，这个新版本有问题了，还需要再重新同步一个老版本过去，模块老版本，本地如果没保存老版本，就同步不过去了，这时候就麻烦大了，为了避免这个情况，所以一般需要保存你的配置的多个版本的，因此应该还有一个版本控制系统，每次开发完确保没什么问题了，就可以推送到版本控制系统上，从这个系统推送到puppet主机上去，将来开发新版本也可以放在控制系统上，控制系统和老版本和新版本一起，再把新版本推送的puppet上，puppet得到后，kick到各个主机生效，发现有问题，就从版本控制系统捡一个老版本出来，放到puppet线上，再kick到各个主机，恢复到老版本
所以需要个版本控制系统，用来恢复到过去
版本控制器有很多CDS,SVN,GIT