《puppet-试用报告-new》由会员分享，可在线阅读，更多相关《puppet-试用报告-new（5页珍藏版）》请在金锄头文库上搜索。
1、目 录Puppet试用报告11. 开篇总结32. 安装配置环境33. 测试过程44. 依赖性45. 安全性46. 扩展灵活性57. 复杂性58. 架构59. 性能510. 可用性分析511. 业务结合性分析612. 可维护性613. 价格分析614. 针对上述问题总结6一、 开篇总结本人对puppet的评分是7.5分（满分10分），具体打分请看下面。Puppet 系统自身设计了一套语法规则，客户端根据这语法规则解释执行；维护人员按照系统管理的角度来说可以部署很多东西，配置可能复杂。文件传输需要借助第三方工具（nginx/apache）提高性能。安全性很高，配置比较繁琐。Client或者serv
2、er死了，都无从得知，需要借助第三方监控。部署结果无上报，无从得知。迁移倒是挺方便的。支持集群（伪机器，多台puppet置于负载均衡器后端(nginx等)）。每增加一台新机器需要内部DNS添加机器名到IP的映射，而且不能修改主机名。二、 安装配置环境 -打8分 软件环境 (第一次在server 安装好，打包即可在client端部署)Ruby-1.9.3p448 （添加PATH，位于第一个）./configure prefix=/usr/local/ruby193 & make & make installFacter 1.3 ruby install.rbPuppet 3.2.2 ruby i
3、nstall.rbOpenssl2 (操作系统自带) 配置方面/etc/hosts 192.168.9.234 rhel5_2 (或者添加内部DNS)，对所有的server/client都需要添加主机名跟IP的映射关系到内部DNS。rootrhel5_2 puppet-3.2.2# touch /etc/puppet/fileserver.confrootrhel5_2 puppet-3.2.2# vi /etc/puppet/puppet.confrootrhel5_2 puppet-3.2.2# mkdir /etc/puppet/sslrootrhel5_2 puppet-3.2.2#
4、mkdir /etc/puppet/manifestsrootrhel5_2 puppet-3.2.2# mkdir /etc/puppet/modulesruby /usr/bin/puppet resource group puppet ensure=presentruby /usr/bin/puppet resource user puppet ensure=present gid=puppet shell=/sbin/nologinrootrhel5_2 puppet# ls -lt /etc/puppet/drwxrwx-x 8 puppet root 4096 07-15 14:5
5、8 ssl-rw-r-r- 1 root root 0 07-15 14:57 classes.txt-rw-r-r- 1 root root 0 07-15 14:57 localconfig-rw-r-r- 1 root root 1062 07-15 14:57 puppet.confdrwxr-xr-x 2 root root 4096 07-15 14:35 modulesdrwxr-xr-x 2 root root 4096 07-15 14:35 manifests-rw-r-r- 1 root root 0 07-15 14:34 fileserver.conf-rw-r-r-
6、 1 root root 4133 07-15 11:29 auth.conf 服务启动ruby /usr/bin/puppet master -daemonize -verbose (8140)ruby /usr/bin/puppet agent -daemonize -verbose -server=rhel5_2 (8139)ruby /usr/bin/puppet cert list all (签名证书)(ps ef | grep puppet 检验)三、 测试过程 部署server端，添加相应的配置文件，启动server端，观察日志。 部署client方面，添加ssl key，在se
7、rver sign CA证书 文件传输方面，没有大量机器大范围测试 编辑服务端和客户端配置文件，添加node,修改参数，看客户端是否执行了server 端要求的部署工作。(在/etc/puppet/manifests/site.pp 添加导入模块的modules.pp，然后在/etc/puppet/manifests/modules.pp 添加导入模块test，然后在/etc/puppet/manifests/nodes/execXXX.pp添加node节点，最好在/etc/puppet/modules/test目录创建test具体模块内容)。|- manifests| |- modules.
8、pp| |- nodes| | - execTest.pp| - site.pp|- modules| - test| - manifests| - init.pp 编辑配置文件，设置传输大文件，观察效果(编辑配置文件/etc/puppet/modules/test/init.pp)。-rw-r-r- 1 root root 409600000 07-16 09:52 /etc/puppet/modules/test/files/test.txtrootrhel5_2 files# cat ./manifests/init.pp #class test file /tmp/test.txt:
9、ensure = present, group = root, owner = root, mode = 0644, source = puppet:/modules/test/test.txt # 观察客户端执行的时间动向。 观察执行结果的上报，通知。四、 依赖性 -打8分 Puppet依赖ruby (最低1.8.7)，我们现网所有机器都要另外安装ruby Puppet依赖facter，版本跟puppet配套，现网所有机器都需要安装 Puppet依赖内部DNS，依赖主机名。五、 安全性 -打10分 所有通信都是基于SSL 的，安全性可靠保证，无问题。六、 灵活性 -打6分 扩展性不好，无法定
10、制添加新功能，基本都是在puppet内部自身的设计中完成一切工作（自定义功能不强） 需要维护人员自己控制一个资源的执行是一次的还是多次,需要避免多次重复执行同样的规则. 命令执行部署方面,每台机器配置文件编辑,管理不灵活.七、 复杂性 -打6分 配置文件规则太多，有变量，面向对象，继承，全局，个性化配置。 每台机器有独立的配置，也有共同的配置，对比多台机器的服务配置比较困难 对同等角色但是又具有不同服务的机器配置起来比较麻烦.八、 架构 C/S架构九、 性能 -打8分 大量机器情况下，文件传输效率低，不过可以通过结合nginx来提高文件传输能力，即puppet集群。改善性能。 受限于ruby解
11、释执行语言,每一个请求都要解释一次.十、 可用性分析 -打6分 单台client 挂掉的情况下，服务端无法得知，降低了可用性 如果是在单台 server提供服务的情况下，server端挂了，client无法得知 Client是定时30分钟执行一次服务端的请求, 可以在crontab 里面添加one-time执行策略，但是这样降低了可用性 Puppet集群可提高可用性 Server端无从得知客户端的执行结果十一、 业务结合性分析 -打7分 适合作为系统管理方面的部署,不太适合作为业务发布类的部署,业务发布小文件可能比较多,任务众多. 命令执行方面,大批量机器配置众多,没有SSH来得直观.十二、
12、可维护性分析 -打7分 服务端操作修改配置（配置繁琐），重启方便，但是配置没有语法检查，需要简单熟悉下ruby Client端部署方面简单明了，Client是定时30分钟执行一次服务端的请求, 可以在crontab 里面添加one-time执行策略，但是这样也会降低可维护性 每增加一台新机器需要在内部DNS添加主机名到IP的映射关系， 而且一旦安装了puppet，就不能修改主机名，否则重新认证ca key。 迁移方面还是比较方便.十三、 价格分析 -打9分 开源版本 基本功能都有，但是很多高级功能无(如GUI) 企业版本什么都有十四、 针对上述问题总结（1）资源配置太多，对于懒人来说很痛苦（2）文件IO传输效率低（内建的webserver） (可以跟nginx结合 提高IO传输效率)（3）执行结果无上报，不知道成功是否（4）开源版本无法GUI 管理，无实时的数据（5）客户端写死半个消失执行一次。 (可以考虑one-time执行，用crontab，有缺点)（6）client/server死了，无从得知，需要第三方监控支持（7）客户端可能有重复执行的危险，需要操作人员控制。1
