本文共 5285 字,大约阅读时间需要 17 分钟。
在使用的时候依然会遇到问题,如果有大量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转载地址:http://hdkgn.baihongyu.com/