Puppet在自动化运维工作中的应用（获奖名单已公布-2013-12-18）

send_linux

获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4115960-1-1.html

话题背景：
系统管理员经常陷入一系列的重复任务中：如升级软件包、管理配置文件、系统服务、cron任务以及添加新的配置、修复错误等，这些任务通常是重复低效的，解决这类任务的第 一反应是让他们自动化，于是出现了定制脚本。环境复杂的场景中，定制脚本和应用程序一再被重复开发，并且很难适合多种平台，灵活性和功能也很难保证，于是魔术师Puppet这样的自动化配置管理工具便出现了。Puppet结合类及模块功能可以自动化管理成千上万台Linux/Unix服务器，而且puppet社区现在也比较成熟了，每天都会产生很多工具和补丁，是系统管理员自动化运维的首选工具之一。

本期话题：
话题一：可以分享下puppet的学习心得及提升技巧。
话题二：分享下puppet在实际工作中的应用心得及注意事项。
话题三：以自己的工作环境举例，说明下puppet在其公司的应用（可作无害处理）

本期嘉宾：
刘鑫 （gray1982）    高级系统运维工程师，CU集群和高可用版版主
胡安伟（king_819）   系统运维主管，CU自动化运维版版主
余洪春（抚琴煮酒）   系统架构师


活动时间：
2013.10.31-2013.11.20

活动要求：
1、 要言之有物，不能低于20个字。
2、 本次话题主要关注Puppet和自动化运维方面原理和实践的心得体会和使用技巧，其他问题可能不做重点
         
讨论有奖：
《构建高可用Linux服务器第二版(3印)》5本

zhangxuan3210

话题一：可以分享下puppet的学习心得及提升技巧
通过几个月的puppet的学习，感觉puppet功能很强大，能完成日程运维工作中的绝大部分问题，通过它可以对机器从到货到下架的整个生命周期进行维护和管理，基于linux的一切接文件，puppet可以很好的维护好这些文件，并能保持好文件的状态。通过几个月的学习和使用和体会，感觉puppet确实是一个较好的C/S工具，但在权限管理，接口方面有些欠缺，不能有效的实现各自host管理。这方面chef做的比较好。

话题二：分享下puppet在实际工作中的应用心得和注意事项
架构方面：
1.尽量采用预认证，统一证书，不要一个agent一个证书，否则机器改名后难于管理，并且机器多了不好对证书进行管理，进行证书统一方便进行puppet的master的集群的搭建。
2.master前端接入采用nginx+passenger，不要采用puppet自带的webrick服务，自带web性能较差。
3.机器较多的话，dashboard使用foreman，尽量不要使用dashboard，dashboard处理是后端数据库容易成为瓶颈(报告的表结构设计不够合理),且功能较少，foreman提供的功能较多，并且接口较多。
4.agent端尽量采用agent主动触发，不用daemon后台运行，agent的自动运行可以较少并发和负载(crontab)，agent开启daemon，会有内存泄漏，并且如果agent挂了，就会失去和master的通信。
5.如果可以，可以考虑使用去master化，采用puppet apply来实现每个agent就是一个master，这样就避免master端的负载过高或导致报表模块的数据库写入较慢。
资源描述：
1.资源的描述尽量使用package，不用exec，package依赖于源，yum或gem等各种源，yum和gem源可进行服务隔离，独自搭建。
2.资源描述尽量做到组件化，能做到资源组合和复用，能使用虚拟资源的就用虚拟资源，后台进行异步配置存储，否则，会使资源描述的杂乱脏，不够优雅。
3.引入节点分类器，不要全部是对机器进行分类，否则服务变换，或机器改名，会对puppet的运行出错，维护起来麻烦。
4.尽量让agent通信一次后再次通信时没有资源的修改，这样才是最好的资源描述。

话题三：以自己的工作环境举例，说明下puppet在其公司的应用（可作无害处理）
目前在公司能将基础运维组件进行收敛统一管理起来，主要包括系统基础组件(基本账户，基本目录，信任关系,系统基本配置等)，服务基础组件(Apache,tomcat,jdk,nginx,lvs,redis,memcache,ruby,python,mysql,mfs,hadoop-client,基本脚本等)以及公司内部的一些基础运维组件。

南非蚂蚁

支持下，puppet功能比较强大，但是也比较复杂！

pssh用的比较多

Gray1982

200+服务器没啥问题，我个人感觉只是比较复杂，不过逻辑性的东西都搞清楚了，几本上P都支持

nbrr

管理过几百架服务器的环境，也管理过上万架服务器的环境，都没用过puppet

刚好最近在学习，说一下我的体会
环境小的话用puppet WEBrick就可以了，多了可以在puppet master前端加apache或者nginx
环境小的话可以把nodes定义直接放在manifests下，大的环境可以用ENC存储在数据库或者ldap里
个人不太熟悉ldap，所以在用perl读取mysql中nodes对应的modules，从而生成yaml

dashboard或者foreman提供了网页界面和更多的功能，目前还没试过

关注运维

前东家～1k台机器已经通过puppet管理了，主要用在对haproxy,nginx,mysql,redis,resin这些服务的配置管理上。
效果很明显，不过puppet主要还是对“配置”的控制，如果要对服务器做服务的”控制“，还需要求救于func这样的工具，func用起来感觉还不错，其模块还在慢慢增加和完善中。
salt还不怎么稳定，对于服务器量级在1k左右的中小型企业来说，从受欢迎度，方便性，可维护性和效率等方面说func+puppet应该是首选。
再说puppet，如果能和svn等版本工具结合起来使用，就更加方便和安全了，在这点上做了一点尝试，简单来说就是通过web来编辑puppet配置，提交更新，客户端拉取生效。原理很简单，初始化svn puppet配置仓库，puppet server co 一份副本，程序在某个地方co一份副本，通过web OP来操作各类配置（程序副本），保存提交触发ci和puppet server副本 up操作。这样做达到了配置的安全性和修改配置的便利性，当然也可以在win下副本上用编辑器修改 ～～