May 9
开篇
     “古巴比伦王颁布了汉摩拉比法典,刻在黑色的玄武岩,距今已经三千七百多年,你在橱窗前,凝视碑文的字眼,我却在旁静静欣赏你那张我深爱的脸……”,想必大家都听过这首周杰伦演唱的《爱在西元前》,由方文山填词,歌词生动美妙不落俗套。作为周杰伦的御用作词人,方文山其实只有高中学历,但他才华横溢,创作了不少经典之作,有些作品甚至被收录进了学校的课本中。那么他是如何写出这么美妙的歌词呢?直到看了他的访谈笔者才了解到其实他的歌词大多来源于生活中的灵感,这首《爱在西元前》就是他在某日逛完博物馆后有感而发,他从现实的场景获得灵感再进行文字加工,从而文思泉涌,妙笔生花。其实运维工作也亦然,需要我们时时从工作中寻找灵感。笔者从事运维工作接近8年,多年的工作经验总结出一个道理:我们要善于从运维工作中发现问题,并根据问题及过往经验发明创造改进工具,接着再从发明创造中提炼技术,最后根据技术提炼原理。近来以Docker为代表的容器很火,很多互联网公司都在使用。那么Docker是如何获得互联网公司的青睐的,我们又应该如何来应用Docker,本章将从以下几个方面逐一介绍:
 我们为什么使用Docker
 离线系统业务架构
 Clip名字服务
 Clip名字服务与Docker应用场景



我们为什么使用Docker
     首先来看一下我们在运维中发现了哪些问题。以笔者就职的腾讯公司案例为例,腾讯产品战线很长,笔者所在的团队负责运维腾讯的QQ、Qzone等核心产品,而这些产品也算是中国互联网骨灰级的业务了,整体架构都有着复杂的历史背景。不仅团队的老员工发现架构逐渐产生的问题,团队新入职的同事也会指出与原任职公司比较架构存在的一些问题等等。如何将很多好的技术融入到我们的业务架构中,以解决产品的问题是摆在每一个运维架构师面前的难题。架构的复杂性与历史沉重的包袱决定着牵一发而动全身,并且架构支持的业务为近半数的中国互联网网民所使用,还有着不少的优点,在对其进行改进优化之前,我们主要先分析了它的优缺点:
  优点:目前还是单机或单集群对应一个业务模块的形式,彼此间没有交集与复用(见图1),其架构优势应对爆发式增长扩容方便,成本结算简单,架构形成的历史原因更多的是前者流量的爆发增长。
点击在新窗口中浏览此图片
图1
  缺点:随着网民的饱和,相同业务模块下移动流量上涨,PC流量直线下降,很多业务出现了低负载情况。海量服务器的运维场景中即使只有1%的低负载规模也是惊人的,在实际运营中低负载+长尾业务下的机器数量可能达到了25%-30%甚至更高。当然这里不排除业务对流量做了冗余与灾备,但是多个业务模块的灾备就会出现浪费资源的情况。除低负载与长尾业务外,为了应对业务的流量徒增团队为产品留出了足够富裕的Buffer资源以应对某业务徒增,而导致这些资源的实际利用率不高。

分析了优缺点后以及运营中发现的这问题后,从2014年中我们就开始着手离线业务混合部署项目。项目的思路是通过高负载业务譬如音频转码、视频转码、图片人脸计算和图片特征提取业务(注:后统称“离线业务”)与低负载、长尾业务和部门buffer业务进行混合部署,来提升机器利用率并同时为部门节约机器成本。不过经过半年多的运营,我们也发现了很多问题:
  在低负载与长尾业务上部署离线业务,如果离线业务抖动出现大的CPU毛刺(特别在晚高峰时段)就会影响用户的使用体验,从而导致部分投诉产生的情况。
  部署在buffer池上的离线业务,由于在线业务申请机器导致机器上的离线环境没有及时清理,继续运营影响在线业务的正常使用。
这两个问题比较有代表性的问题也是我们最不希望看到的,所以总结经验教训后在2015年上半年我们又重新打磨项目开发了新版离线系统,新项目与老项目相比通过Docker技术将离线业务与在线业务的低负载、长尾业务和Buffer池进行了部署,从而顺利解决了上述的问题。这里主要利用了Docker的三个优势:
  Cgroup对资源的隔离让离线与在线业务彼此间对资源使用有了保障;
  命名空间,让相同框架多业务跑在相同物理机上成为可能;
  容器的快速回收上线下线,使用Buffer资源时不再为回收离线资源而头痛。



离线系统业务架构
上文中笔者提到QQ、Qzone的整体架构着很复杂的历史背景,而希望仅仅通过Docker或一两种工具来解决现实存在的所有问题是不现实的,所以我们在保持现有架构与内部用户习惯的基础上另辟蹊径逐渐解决我们产品运营上的一些问题,具体部署见图2。
点击在新窗口中浏览此图片
离线系统业务架构(图2)

从图2中可以看到在部门Cmdb基础之上,我们建立了数据分析系统,通过它可以分析出哪些是低负载业务,哪些是时段低负载业务。在此基础之上我们使用Clip名字服务系统在Cmdb基础之上重新建立了业务之前的IP关系,并根据重新划定关系的IP进行了业务流量与资源快速的调度。其中Etcd为服务发现工具,根据Clip名字服务系统传入的信息通过Confd重新生成HAproxy的配置文件并热重启它,离线业务流量通过HAproxy的虚拟IP屏蔽底层资源信息,建立离线与资源的生态供应链,同时上层监控与调度均为Clip名字服务系统。这里读者有可能会有疑问,尽管HAproxy的虚拟IP屏蔽底层资源信息(其为动态的),但如果程序有问题,如果能快速到机器上去debug自己的程序呢? 这里我们使用的是Clip名字服务。




Clip名字服务
Clip(http://blog.puppeter.com/read.php?7)是一个名字服务C/S架构,它将传统的IP管理维度替换为名字服务即有意义可记忆的String。Clip将IP对应的String关系保存在Server端。Client端可以下载SDK,通过SDK遍历Server端的String对应IP的关系,并在本地对获取的IP模块关系进行重新的组织与编排。传统服务器IP方式与String方式相比,String方式有3点优势:
  传统IP管理方式,IP由4组无意义的数字组成,比较难记忆。String更方便记忆;
  管理海量服务时,IP相似经常会导致运营故障,譬如A模块(10.131.24.37 )和B模块(10.117.24.37),后两组数字一致,系统惯性的认为B模块就是A模块,发送配置导致线上故障。通过string管理方式可以规避此问题;
  String 可以解析1个IP,也可以解析一组IP ,根据IP也可以反解析String对应关系,使得管理一组服务更加方便。
    Clip中的String由四段(字段含义idc-product-modules-group)组成,读者会发现String与Cmdb的结构很像:四级模块定位一个服务。但是为了充分利用资源我们的业务要求一个IP可能要对应多个服务,不同的服务有自己的波峰与波谷,在相同的IP上只要保证各业务的波峰不重叠就满足了业务的需求,也充分了利用资源。而在一台服务器上混合部署不同的业务模块,四级模块就只能定位到服务的IP级别,而无法精确定位到真正的服务,所以Clip名字服务在Cmdb的基础上增加了port端口,即五段(字段含义idc-product-modules-group-port)定位一个服务。我们可以将动态的IP通过Clip接口注册到指定含义的String上,通过Clip自带工具来解析实时的String对应IP关系,譬如:

# clip cstring -q idc-product-modules-group-port
192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5

Clip数据存储结构分为两层:
关系层保存了String对应IP或内部系统Cmdb的模块关系(见图3)。
点击在新窗口中浏览此图片
Clip名字服务关系表(图3)
关系层数据含义见表1
点击在新窗口中浏览此图片
关系层数据含义表1
数据层保存了String与IP的具体关系(见图4)。
点击在新窗口中浏览此图片
Clip名字服务数据表(图4)
点击在新窗口中浏览此图片
Clip名字服务在存储String对应IP关系基础上,在SDK上还提供了远程端口扫描、远程ssh、远程文件拷贝和查找String关系结构的工具子命令等,更多可以见http://blog.puppeter.com/read.php?7。




Clip名字服务与Docker应用
如笔者上文所提,离线系统的建设思路就是将离线业务通过Docker快速的部署在资源空闲的机器上,而空闲的机器是通过数据分析系统长期分析沉淀的结果,Clip名字服务就是这两种资源建立联系的桥梁,但只有Clip绑定关系还是不够的,还需要建立绑定关系String对应Docker环境的关系,所以在Clip名字服务的基础上我们又扩充了Docker的资源关系表。
点击在新窗口中浏览此图片
Docker资源关系表图5
其中Docker资源使用的关系表的字段含义见表3:
点击在新窗口中浏览此图片
我们来看一个需求案例:某视频转码业务在上海需要使用资源约1000核心,对应的关系表为表4
点击在新窗口中浏览此图片
由于buffer资源不时在变动,我们需监控String (sh-buffer-qq-video-2877)整体核数是否低于mcount值,如果低于则出发自动扩容策略。同时也需针对Docker资源使用关系中的app_port字段来监控整体String (sh-buffer-qq-video-2877)业务是否处于健康状态。在这里我们沉淀了String (sh-buffer-qq-video-2877)的一些基础数据如负载、内存、网络和磁盘IO等为资源的调度奠定的基石(见图6)。
点击在新窗口中浏览此图片
离线运营系统图6
Dec 15
通过Puppet管理大量机器的过程中会经常遇到连接超时的情况,所以通过Shell脚本包装Puppet Agent随机连接也是一种很好的方法,以下为连接过程脚本。



Puppet连接过程架构
点击在新窗口中浏览此图片



Agent连接Master脚本(注:部分内部为了安全被替换为中文注释)


#!/bin/bash
# author: wds
# time : 20151212

## init
PATH="/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin/"
export PATH
export LC_ALL=POSIX
export LANG=en
_PWD="/etc/puppet"
_PUPPET="/usr/local/services/puppet/bin/puppet agent"
_HOST="puppet.example.com"
_LOG_TIME=`date +%Y%m%d%H%M`

[ ! -e ${_PWD}/lock ] && mkdir ${_PWD}/lock
[ ! -e ${_PWD}/log ] && mkdir ${_PWD}/log
[ -e /etc/puppet/log/ ] && find /etc/puppet/log/ -name "*.log" -mtime +3 -exec rm -rf {} \;
[ -e /etc/puppet/lock/ ] && find /etc/puppet/lock/ -name "*.lock" -mmin +17 -exec rm -rf {} \;

## function
getip()
{
    IPADDR=`ifconfig eth1 | awk '/inet addr/ {print $2}' | cut -f2 -d ":"`
    if [ "x${IPADDR}" == "x" ];then
        IPADDR=`ifconfig eth1 | awk '/inet addr/ {print $2}' | cut -f2 -d ":"`
    fi
    echo $IPADDR
}

netlog()
{
    #打网络日志
}

#content title
sendalarm()
{
    #发送告警
}

rand(){
    min=$1
    max=$(($2-$min+1))
    num=$(date +%s%N)
    echo $(($num%$max+$min))
}

clip_ini(){

if [ ! -e /usr/local/services/clip/clip ];then
    netlog "clip not exists fail"
    exit
fi
# clip 相关介绍http://blog.puppeter.com/read.php?7

if [ ! -e /etc/facter/facts.d/clip ];then
    ipaddress=`getip`

    clip=`/usr/local/services/clip/clip cstring -i $ipaddress`
    if [ ! -e /etc/facter/facts.d/ ];then
      mkdir -p /etc/facter/facts.d/
    fi

    echo -n "#!/bin/bash
    echo \"clip=$clip\"
    " > /etc/facter/facts.d/clip
    chmod -R 777 /etc/facter/facts.d/clip
fi

return 0
}

hostname=`getip | sed 's/\./_/g'`
if [ "x${hostname}" != "x" ];then
        hostname $hostname
fi

##############################################################################################
#/usr/local/services/puppet/bin/puppet agent --server puppet.example.com --test

## first  首次连接
if [ ! -e ${_PWD}/lock/first.lock ];then
    sed -i '/puppet/d' /etc/hosts
    echo "IP $_HOST # puppet" >> /etc/hosts
    res=`$_PUPPET --server $_HOST  --test | tee -a ${_PWD}/log/puppet.log | grep "Finished catalog run" | wc -l`
    if [ $res -eq 0 ];then
    netlog "puppet first fail"
    else
        touch ${_PWD}/lock/first.lock
    fi
fi

## second 二次连接

if [ ! -e ${_PWD}/lock/second.lock ];then
ipaddress=`getip`
clip=`/usr/local/services/clip/clip cstring -i $ipaddress`
if [ "x$clip" != "x" ];then
  touch ${_PWD}/lock/second.lock
fi

idc=`echo $clip | awk -F '-' '{print $1}'`
if [ "$idc" == "tj" ];then
    _host='IP'
elif [ "$idc" == "sz" ];then
    _host='IP'
elif [ "$idc" == "sh" ];then
    _host='IP'
else
    _host='IP'
fi

sed -i '/puppet/d' /etc/hosts
echo "$_host $_HOST # puppet" >> /etc/hosts
fi

## app
##########################################################################################
if [ -e ${_PWD}/lock/puppet.lock ];then
exit;
fi

clip_ini
wait
touch ${_PWD}/lock/puppet.lock
rnd=$(rand 1 5)
sleep $rnd
res=`$_PUPPET --server $_HOST  --test | tee -a ${_PWD}/log/puppet.log | grep "Finished catalog run" | wc -l`
if [ $res -eq 0 ];then
  rnd=$(rand 1 20)
  sleep $rnd
  res=`$_PUPPET --server $_HOST  --environment=${_ENVIROMENT} --test | grep "Finished catalog run" | wc -l`
  if [ $res -eq 0 ];then
    netlog "puppet cluster fail"
  fi
fi

netlog "puppet succ"
rm -rf ${_PWD}/lock/puppet.lock
exit 0;
Tags: ,
Oct 28
Clickheat是一款网站热力图工具,它可以获取用户在网站的行为,并以图形式呈现在页面上,借助它可以了解用户行为以便有针对性的对网站进行优化。以下是内部系统的一个案例

点击在新窗口中浏览此图片

Clickheat由PHP开发,下载后将源部署到自己的服务器上,并在网站页面中嵌入相应的JS代码来生成点击热图,然后通过调用相应的页面查看。Clickheat官方网站(http://www.labsmedia.com/clickheat/index.html)
Oct 27
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?13

开篇
虽然工作多年,但是对系统技术痴迷热情从未改变,所以在2015年初,历时1年多写的《Puppet权威指南》书发行了。在与很多朋友技术交流过程当中了解很多人也有类似写书的想法,经常有人问你出书的流程是什么? 如何来写一本书?出书的收益又如何?等问题。综合这些问题,我也来分享一下:

如何萌生写书想法;
写书的流程是什么;
如何将过程转化为收益。

希望通过介绍整个过程,能让更多有意的朋友能为业界提供更多的思路与创新技术(注:由于笔者能力水平有限,在写作过程中难免会有错字、语句不通顺等情况。如果大家有任何疑问可以给我留言,我会尽快回复与更正,非常感谢)。


如何萌生写书想法
回忆了一下,首先从来没想要写书,只是偶然的机会而已。在2001年左右,上高中时很喜Photoshop和3Dmax,在那时我就已经会安装Windows 98操作系统,在班级中公认的是一个计算机高手。另外,我也经常买《电脑报》、《网友世界》和《黑客X档案》杂志,通过XCAN来扫描远程服务器开放端口,并根据扫描后端口确认是否有漏洞,这些对于那时的我会带来很多的成就感与自豪感,记忆中曾多次一条命令就可以让网吧远程的系统蓝屏,但有一次在网上遇到了牛人,他能随意改我的QQ密码,盗取我的163账号,查IP地址能定位到我的家门牌号,那一刻我觉得自己弱爆了,后来经常与他交流学习经验,那时我最不喜欢学习编程语言,而他说你要做为一个优秀的黑客就要去学习编程语言和网络协议,也是那时他让我第一次知道TCP/IP协议的三卷书,通过与他交流与指导,我开始自学C编程语言,学了才知道C语言并没有想象中那么难。

后来上了大学,操作系统中学了Linux,了解他历史的都应该知道玩Linux才是真正的黑客,所以那时去电脑市场买了一个Redhat6.0版本的系统盘来安装,安装后不知道怎么用,在网上查资料时知道了www.chinaunx.net(简称CU),那年是2006年,因为我的CU ID(研究生)注册时间就是2006年。从CU学到了很多东西,譬如记忆深刻的《门户网站运维abc》、《Shell能力测试》和《Shell基础20篇》等都是很好的学习资料, 还有一篇文章来描述如何学习Linux,大概中心是要想学好Linux;
多看书;
多实践;
多总结沉淀;
遇到问题自己查找资料解决,解决不了再寻求帮助;
如果学习的知识点都掌握了,多去帮助他人解决问题,其实帮助他人也是自己学习的一个过程。
所以,在CU经常找别人问的问题,看是否能解决,如果解决不了再去网上找解决思路与过程,那时也是因为这原因,我写了很多文档,由于看了Shell编程13问的文章,忽然觉得我的文档总结可以写成一本书的形式与别的朋友进行分享,经过对文档总结提炼与打磨,最终在2008年写出了第一版本,不过现在已经找不到最初的版本了,在电脑里找到了2010年最后变更时间的书,无意间人生的第一本书就这样的写完了。

2008年在北京工作后,一天在QQ忽然有人问我,看你CU比较活跃是否可以可以来我们这里帮讲一些网络的课程,我抱着试试看的态度应邀去了华章的编辑社,去了才知道这是有名的机械工业出版社,我很喜欢买他们书。到了后是一位美女来接我,交谈中我说我写过书,美女说是否可以发我看看,几天后我提交了一份书的原本发给编辑社,美女帮我指定了出版策划(杨福川),第一次与福川见面时在中关村的麦当劳,感觉一见如故与技术人交谈很开心,他看过我给的文档后,给了我很多出书的建议,说对于刚出茅庐的我书的内容还是很好的,但对于出版来说要走的路还要很多,不过也鼓励我,希望有机会能合作出一本书。就这样几年过去了,应该是2012年系统架构师大会,再次遇见福川,福川问是否有兴趣来写书,我说OK没问题,正好由于内部部门产品变动,我负责的系统没有运营工具,我对Puppet进行研究并在线上应用。那时Puppet知道人并不是很多,所以一拍即合开始写人生的第二本书《Puppet权威指南》。



写书的流程
下定决心后写书并不复杂,以下为写书流程:
1)寻找一个靠谱出版社,因为他会有渠道帮你做后续推广;
2)确认写书的标题与大纲,其中大纲很重要,有一个目标才好量化时间与写作进度。写作大纲中一般还包含选题思路、读者对象、内容简介、市场分析、卖点分析、作者简介和营销建议这7项;
3)签约合同,合同是双方利益保障,对于出书者来说写完出版社不出版,可以通过合同来约束。当然,反过来没按照预定写出来,还是要陪违约金的(这也是签约后动力之一)。除此之外,还要确认付款方式,两种:
方式1:一次性买断书的版权,即一次打完所有歀。
方式2:是按出版发行量计费,根据书的售卖情况打款(我签约的这种)
大家可以自己来确定付款方式(写书并不挣钱,但是收益还是有很多的,一会会介绍)。
4)合同确认后,策划会分配一个编辑给作者。我的编辑(孙海亮)海亮给我的感觉三个词形容,积极、专业和耐心。编辑会把控整体的进度、写作风格、语句是否通顺、是否能很好的读者学习了解书中的专业知识内容,然后就是定期发文稿给编辑;
5)最终出版社收到完整的书稿(齐、清、定)后会制定编辑加工计划,并以书的形式打印出来各章,确认排版与最终效果是否一致,前后有三次校对过程;
6)最后确定封面,出版与推广;
7)根据约定出版社付稿酬。

流程中有很多值得分享的案例:
案例1:(做任何事,大多数人都会有一个热情期,当热情变成负担,这时如何来磨练自己让负担再转为热情?)
开始我写书很有热情第一个月就写了两章,将文稿发给海亮很快回复了我的邮件,当我打开文稿到是挺喜庆的,满篇的红字,感觉像老师改小学生作文一样,在其中提出了很多意见与建议,如何从读者的角度来写书等,其实那一时刻热情已然不在,更多的是觉得变成的负担,心想如果按照这样写下去何日能写好,用一个月写的文稿按海亮要求基本要从改一遍。果不其然,开始一个月写两章,到半年时我才写了4章。不过,需要承认海亮提的意见是非常好的,在写过第6章回头再看的时候,首先觉得是有成就感的,因为我真的总结出了很多内容,接着对文章不断的实践与打磨,我对Puppet认识也更加深入,所以日常的实践打磨到后续的价值转化,最后负担又转为了热情。

案例2:(出版社很专业从一些细微的案例可以体现到)
在Puppet编程语言中有自己的if..else,如果作为我专业人士来描述,我会写if 为真,怎么样,否则为假怎么样。海亮很耐心的和我解释这里应该如何写,建议借鉴谭浩强老师写的C语言编程中的对if..else描述,当时我做了对比差异确实很大。
另外,我的书大约是2014年10月份最终完成,11月份印刷完毕,直到2015年1月份才正式出版,推迟两个多月,原因是很多书店年底会清货,11月份出版很容易被清理到书店不容器看到的地方,所以推迟发行。我相信这些建议与意见都是从日常工作中摸索总结出来的,是专业的表现。

案例3:(工作+写书的时间分配)
如何的合理利用时间,通常我是周一到周五每天早上拿出半小时来阅读之前写的内容,中午午休1小时来实践Puppet,晚上1小时来继续写Puppet 。周六也拿出半天或一天时间来写和改,保持一个节奏,这样会比较轻松一点。

案例4: (如何丰富写作内容)
如果单写Puppet工具应用确实内容不是很多,所以我从对比角度出发,首先是业界流行的配置管理工具都有哪些(Puppet vs Cfengine vs Chef)他们优缺点是什么、我为什么选择Puppet、与老牌配置管理工具Cfengine相比Puppet为什么可以弯道超车、Puppet都谁在应用它、未来前景如何、它整套架构与运行原理如何、到最后实践如何应用它、都哪些场景适合使用它等。Puppet与很多工具软件一样,官方提供了详细的文档(http://docs.puppetlabs.com/)我们可以从这里获取很多信息。更主要的是获取信息后就是如何应用在自己的工作场景中,解决了自己实际问题同时也让读者在真是需求场景下,能够印象更加的深刻。

以下为写作过程中点滴
点击在新窗口中浏览此图片


如何将过程转化为收益
看一本书容易,但写一本书还是挺难的,需要有毅力和时间去写,写的过程中需要不断的对软件应用、实践与打磨,具备了这些,我们就肯定会从写作过程中得到收益。而写书除了money更多是无形的收益,其中对于我个人的职业技术生涯收益,我抽象了以下五点:

1)总结沉淀与转化能力
写一本运维工具相关的书,不但要对工具了解,还要了解工具的历史,以Puppet工具为例它的作者(Luke Kanies)是一位优秀的运维工程师,有着多年的运维工作经历,做运维的都有过类似的经历接手一套产品相关的运营系统没有运营文档或者运营文档不全是很悲剧的事情,当然有的公司会强制要求员工写文档或者Wiki,优势是当系统交接时,被交接的对象会通过文档绕过一些坑,而且这也是比较好的习惯,但也有他的缺点就是这些系统文档或Wiki并不实时与准确,相信Puppet作者也有过这样的经历,所以Puppet的解决思路是以编程语言形式,将当前系统所需要的安装软件包配置描绘出来,通过辅助工具还可以以图形式看到模块之前的依赖状况,而这一切都是实时的,一旦错误线上马上会体现出来,Puppet思路很好的解决的我们曾经面临问题。而对于我后续做运营工具的思考,我的总结是“从运维过程中获取经验,根据经验发明创造改进工具,接着根据工具创造提炼技术,最后根据技术再提炼原理”。有理由相信这也是Puppet开发运和营过程中的体现。

2)模仿能力
如果领导让我开发一套配置管理工具,相信我是有能力做出来的,但我也相信开发出来的配置管理工具只能满足临时的需求,长期来看它根据需求要不断的完善、重写与迭代,而配置管理系统在业界有很多,譬如Puppet、Ansible、Cfengine和chef等,他们均是配置管理工具,其实更好的方式是使用它们,模仿它们和改造它们为我们工作所用,因为它们有自己的开发社区、有多年的积淀、有非常好的思想能让你去借鉴、它们像一种协议一样统一了大家的思想,而这种思想对未来应用到其他领域是十分有帮助的,所以这里如何借鉴与模仿很重要。

3)换位思考能力
对于一个专业的互联网从业人员来讲,希望把书介绍的尽量详细与专业,书中可能会有一些工作中的术语,譬如“灰度”对于有工作经验的朋友肯定知道他的含义,但是对于那些刚入行的朋友却不知所云,所以我们要换位思考,以读者而且是刚入行的读者角度,尽量的白话书中的专业术语。这种换位思考能力不但可以应用写书,还可以在生活与工作中得到借鉴。

4)沟通与分享能力
思想就是武器,能说才是火力,光有武器火力不太猛还不行,如何在写书过程中不断的补充武器来提升火力很重要,因为任何一行业都要有交流沟通,特别是互联网行业尤为突出,所以总结每一章后,要想如何把他讲出来分享给其他人,这种分享过程可能先是文章、然后是技术博客、接着抽象出原理,最后是与同事来分享它,提升自己沟通与分享能力。

5) 运营能力
等书出来了,最后就是自己的运营能力。
引用
网上有一篇文章(Google通过Puppet管理超过6000台的苹果桌面操作系统)地址:http://my.oschina.net/HankCN/blog/180105
,我个人觉得这是一句有炒作的嫌疑,当时Puppet管理服务器能力并不是很强,而Google是很多技术公司的标杆,所以此新闻一出有一定的炒作意义,既然标杆用的都是Puppet工具,相信它也可以用在更多的公司中,而之所以Puppet使用广泛可以弯道超车与他的公司运营能力也有一定的关系。


最后,我想说的是写书分为两种,一种是有时效性的,一种是相对没有时效性的,TCP/IP三卷书就是相对没有时效性的,如果TCP/IP协议不变,写一本这样的书收益可以一直延续下去,而我写的工具书是有时效性的也许是1-2年 ,因为Puppet版本是在不断的迭代变更,但不管他如何改变,他值得学习的创新思路是永远不变的。所以走过这条路,也许绕了很多弯,调整心态,坚持走下去,即便是弯路,也可以收获美景。



鸣谢
很多书会在开篇提起感谢很多人,开始没什么感觉,写过书之后才体会到了这一点,因为有了你们的支持,才会让我坚持又坚持完成这本书,所以这篇文章最后要感谢曾经在写作过程中帮助过我的人,特别是我的老婆,感谢。



参考资料
Puppet labs官方网站:https://puppetlabs.com/
Ansible:http://www.ansible.com/
Chef:https://www.chef.io/chef/
Cfengine:https://cfengine.com
Puppet作者经历:http://blog.puppeter.com/read.php?10  
Shell编程13问:http://bbs.chinaunix.net/thread-218853-1-1.html
Shell能力测试:http://bbs.chinaunix.net/thread-476260-1-1.html
门户网站运维abc:http://bbs.chinaunix.net/thread-1281178-1-1.html
Shell基础20篇:http://bbs.chinaunix.net/thread-452942-1-1.html
Luke Kanies(Puppet作者linkedin):http://www.linkedin.com/profile/view?id=ABQAAAA6kLcB06__Nn-a_DEULHGnaTzLR2wPp-c
谁在用Puppet:https://puppetlabs.com/about/customers
Oct 5
源地址:http://www.ituring.com.cn/article/53193

Puppet对于做DevOps的同学来说,是个非常熟悉的名字,但仍有人还不了解它。那么我先来简单介绍一下:Puppet是由Puppetlabs公司开发的系统管理框架和工具集,被用于IT服务的自动化管理。由于良好的声明式语言和易于扩展的框架设计以及可重用可共享的模块,使得Google、Cisco、Twitter、RedHat、New York Stock Exchange等众多公司和机构在其数据中心的自动化管理中用到了Puppet。半年一度的PuppetConf大会也跻身于重要技术会议之列。AWS的CloudFormation文档中有一段关于Puppet的介绍,其开头是这么说的: Puppet has become the de facto industry standard for IT automation。(puppet是自动化运维的标杆)

同时,Puppet在Openstack中也发挥着重要的作用:Openstack-intra社区将其用于Openstack wiki系统,持续集成系统等等的运维管理;此外社区的puppet-openstack项目用于完成Openstack服务的自动化部署和管理,目前已经在stackforge中托管并通过Openstack的Gerrit系统来管理代码提交;此外,Cisco,RedHat,Miriantis等多家公司的Openstack发行版或部署工具中均使用到了puppet-openstack。目前,Puppet在UnitedStack的日常运维管理和产品的自动化部署中也起到了重要作用。

好了,刚刚还不了解Puppet的读者们现在已经知道:Puppet是一个牛逼哄哄的自动化运维管理工具。可能有人已经下完了软件包跃跃欲试了,先别急,有关Puppet的使用资料在网上可以搜到一大堆,官方的文档也详细到了“令人发指”。关于Puppet的使用经验分享和各种特性的深入探讨以及如何使用Puppet管理Openstack部署的方案分析,哦,都不在本文的讨论范围之内。 本文的重点是八卦一下puppet为什么可以这么成功。同时,为避免引起非Puppet程序员感官上的不适,我屏蔽了各种代码级别的展示和对细节的探讨。

故事要从Luke Kanies,这位twitter昵称与Puppet的服务器端进程名同名的哥们说起,在很久很久以前...

enter image description here

成长:苦逼的学生时代

在1992年的时候,Luke进入诺思兰学院成为了一名化学专业的学生,这是一所位于威斯康辛州的小学校,全美排名在178左右徘徊。

小伙子很争气只呆了一年就跑到了大名鼎鼎的里德学院,成为了乔布斯的校友。不过倒霉的是里德学院被评为全美十大苦逼学校之一,6年毕业率仅为75%,也就是有1/4的同学拿不到毕业证。有别于很多文理学院自由选课的模式,里德的大一学生必须完成规定的人文必修课程,学习希腊及罗马的古典文化。这门课程已经有超过50年的历史,里德动用了学校最为强大的师资力量来为学生奠定文化基础。这还没完呢,之后学生还必须在四个拓展领域选课:文学、哲学、宗教、艺术方面;历史、社科、心理学方面;自然科学方面;还有数学、逻辑、语言学或外语。大三学生必须通过专业测试,大四学生则必须完成专题毕业论文才能毕业。毕业论文并不可怕,可怕的是里德学院的毕业论文的学时是一年,所以有想出国留学的同学,请密切关注另外九所大学的名字…

该来的还是会来的。1996年,Luke大四了。要想顺利毕业,那么他必须得修完这长达一年的论文项目,这意味着在这一年内他必须要动手设计和实现,并用实验数据证明,最终组织成论文来完成课题。Luke的论文题目是Site-directed Mutagenesis in Soy Cytosolic Ascorbate Peroxidase,我推敲了半天,中文翻译大致是:大豆抗坏血酸盐过氧化物酶胞质的定点诱变。

打工:漂泊和积累

万幸的是,我们不用去研究一口气都念不完名字的论文。扯远了,Luke毕业后没去找一份和化学相关的工作而是去了Cypersite当起了Mac系统管理员。在Cypersite的日子里,Luke使用AppleScript干着行MacOS的管理工作,不过干了不到一年还没转正的时候,他便跑路了。

因为在97年的12月份,他在Metro One Telecommunications找到了一份系统管理员的活儿。Metro One Telecommunications当年可是纳斯达克上市公司,主要业务是提供电话号码查询服务。在其巅峰时,公司在全美拥有7000名雇员,然而在2009年初,在售完最后一部分的经营业务后,该公司还剩余3人。瞄了一眼Metro One今天的股价:0.01美元。通信行业早已是昨日黄花了,吴军博士已经在《浪潮之巅》中将这些历史描述得尽致淋漓。

又扯远了,在Metro One的1年零9个月里,Luke的主要工作是管理分散在全美的30个呼叫中心,包括了呼叫中心计算设备的部署和设置,外加从总部对其进行不间断的维护。看到这里,我突然想到某家startup的创始人之前在电信部门做过相同的工作,后来他去做了一个很炫的可视化部署工具,我猜测通信行业的部署工作充满了重复的机械劳动,有一种自动化的强烈需求。这里提一下,provision曾是电信行业中的一个术语,专指安装通信设备前的准备工作,而在devops中常说提起的bare-metal provision是指在计算机上安装操作系统或者hypervisor的过程。

在1999年,Luke离开了这家电话公司,在BlueStar担任系统工程师,BlueStar是一家卖解决方案的经销商,主营业务有:RFID, Auto ID, POS, Mobility products。Luke主要负责一家DSL ISP服务器端基础架构的设计和实现。他构建了一套自动化且可集中管理的系统,并负责基础架构项目的持续开发以及实施和维护。

Luke在“蓝翔”干了还没到两年,又跑去了卡特彼勒融资服务公司担任顾问,提供系统自动化管理相关的咨询。我查了下,卡特彼勒公司位列世界500强,成立于1925年,是世界上最大的工程机械和矿山设备生产厂家、燃气发动机和工业用燃气轮机生产厂家之一,也是世界上最大的柴油机厂家之一。我在网上没有查到Luke在这段时间具体干了些什么,只能感叹Luke作为一个系统管理员是怎么混进一个高帅富的融资公司担任顾问的。

创业伊始:对轮子的修修补补

在卡特彼勒待了两年后,Luke开始单飞,找人合伙创建了Reductive Consulting(2010年改名为Puppetlabs),头衔是独立顾问,专门从事Unix基础设施自动化相关的咨询。他着手研究当前开源的系统管理和监控工具如CFEngine,ISconf,Nagios等等,并且通过二次开发把这些工具联结成一套满足客户需求的解决方案。这是一个重要的阶段,Luke开始将积累多年的经验和思考转变为对工具的改写,这期间他的主要工作包括重写了CFEngine的解析器和开发了ISConf3,这对后来的Puppet开发工作产生了重要影响。

CFEngine简介

首先,来说一下大名鼎鼎的CFEngine,这是一款出生于1993年的老牌系统配置管理工具,CFEngine的作者Mark Burgess希望可以使简单的管理任务自动化,使困难的任务变得较容易。它的核心理念是使系统从任何状态都能收敛到一种理想状态。

这样的工具对当时还在使用零零散散的脚本来管理机器的系统管理员来说简直就是冬天的棉袄,夏天的雪糕,黑暗中的灯泡,饥饿中的面包。之后,CFEngine自然而然地成为了系统配置管理工具中的标杆。

CFEngine有两种工作模式:既可以使用standalone模式即通过cfagent来完成单台服务器的配置管理工作,也可以通过C/S架构(cfservd和cfagent)来管理整个集群的配置管理的分发工作。

CFEngine的工作方式是基于脚本分发:在配置文件中有一个参数称为shellcommands,用于配置要执行的命令或脚本,actionsequence则用于设置shellcommands的执行顺序。

再来看看CFEngine的版本更新:1993年,CFEngine1发布;1998年,CFEngine2发布,而十年后,直到2008年,CFEngine3姗姗来迟,第三版发生了巨大改变,可以通过使用DSL来定义系统状态,以至于其不能再兼容旧版本CFEngine2的配置语言。本文谈到CFEnigne时,是指CFEngine2。

ISconf简介

ISconf则是另外一款配置管理工具,它的核心理念是系统的最终状态是一致的,即使被管理的机器是关机状态,当它们完成启动之后,相关命令就会被执行,到达一致的状态。同时整个系统无需中心节点,命令可以在任何一台节点上执行并复制到所有节点上。ISconf总共经历了4代的演化。ISconf1和2是由shell脚本编写,Luke在2002年的时候开发和设计了ISconf3,并使用Perl在2的基础上进行了重写。ISconf3有三个核心特性:

确定性的执行顺序
执行中有失败时立即退出
状态维护
从上面的特性来看,是一个挺酷的产品。Luke在02年的时候完成了开发,并在03年的LISA(Large Installation Systems Administration)会议上发表一篇名为'ISconf: Theory, Practice, and Beyond'的paper,谈到了ISconf的特性,开发ISconf中获得的经验和教训,以及和CFengine的集成,分析ISconf 3的适用场景等等。不过ISconf社区在介绍ISconf3的历史时对Luke的论文颇有微词,你可以在ISconf的官网读到这篇文章。不过,ISconf止步于第四版,最后的版本发布时间停留在06年8月13日,原因未知。

萌芽:自造轮子

随着Luke的梦想越来越大,这些工具集也变得越来越庞大。而此时对这些现有的开源工具的修修补补已经不能满足他的需求了。最终,他意识到只有他自己,才能去创造自己想要的工具。作为一个多年的运维人员,他深深感受到了苦逼的系统管理员们需要有一个崭新的工具来使得他们的工作更高效,更便捷。因此,他开始考虑去开发一个新工具,首先这个工具是为系统管理员而设计的。那么怎么才能称为得上是为系统管理员设计的呢?

先来简单思考一下系统管理员对于配置管理工具的主要需求:学习成本低,开发高效,跨平台,代码可复用,安全,可扩展性高等等。

最好的情况就是系统管理员只需关心某个服务或者软件包的状态,例如我希望部署一个apache web服务器,我只关心apache的包是已安装的状态,服务是运行的状态,而不要让我去操心这个apache包是装在Ubuntu下的还是Redhat下,然后到底是要执行yum install还是apt-get install,然后还要操心这个apache进程到底是用init还是upstart管理的。

此外,还有如何对依赖关系进行处理。先前的配置管理工具都是关注在如何去完成每一项互相独立的工作,例如配置apache服务就是一段shell脚本而已,而没有去考虑它们之间是存在关联的,例如当apache的配置文件发生变更时,是应该重启apache服务来使之生效,而重启apache服务的前提是系统已经安装了apache。

这对于当时占据主流的以分发shell/perl脚本的配置管理软件来说,简直是天方夜谭。不过Luke就是这么设想的,他在构思Puppet的设计时,就希望将系统抽象成资源:采用面向对象的概念,将每个资源类型组成为一组属性的集合,每个属性都有相应的行为,并将资源类型和属性构造成类,最终使用这些属性来使得资源到达期望的状态,而不是用资源本身来完成这些工作。同时,将所有资源的依赖关系构建成一张有向图,通过这种依赖描述,系统管理员们可以实现复杂的业务逻辑的管理。

越想越兴奋,于是Luke开始动手coding了。Puppet的第一个原型写于04年夏天,但他并没有把此事放在最重要的位置上。于是在9月份的时候,Luke居然跑去了BladeLogic担任产品设计,这是一家专门做商业配置管理软件的公司,它的产品在当时已经取得了成功,然而Luke发现BladeLogic的品味仅仅是想卖软件给大公司而不是立志为系统管理员设计伟大的工具。在05年的2月份,Luke下决心继续搞Puppet的开发工作。于是,在BladeLogic呆够了7个月后,Luke选择了离开。BladeLogic也终于如愿以偿:被BMC收购了,当然这是后话。
enter image description here
艰难抉择: 开发语言和设计哲学
随后Luke回到了Reductive Consulting,也就是Puppetlabs 的前身,开始了Puppet的全职开发。不过他遇到了一个棘手的技术问题:身为一个Perl程序员,Luke痛苦地发现,Perl居然无法处理那些Puppet类之间的关系。那时Python被认为是系统开发的最佳选择,但是Luke同学接受不了的不是Python的缩进问题,而是print是一个语句而不是函数,len是一个函数而不是方法的事实,让他感觉“眼睛在流血”。这时候,有个朋友告诉他Ruby很酷,于是他在尝试了4个小时后,就写出了一个功能原型,从此不可自拔。不过他也有点担心,在当时Ruby还属于非主流,因为ROR(Ruby on Rails)都还没有出生,不过鉴于他的体验,觉得使用Ruby的开发效率非常高,因此他决定冒一次险。
在这个问题解决之后,Luke又面临另外一个难题:虽然在此之前他已经写了不少的小工具,积攒了丰富的经验,不过这些工具没有一个的代码量是超过1万行的。这也意味着在设计Puppet的架构的过程中,肯定得摔不少的坑。因此,Luke在开发Puppet的过程中始终要求自己和开发团队遵守两个指导思想:首先设计尽可能地做到简洁,程序的可用性总是高于新特性;此外Puppet首先是个框架其次才是一个应用。在解决了语言选型和设计哲学的问题后,Luke开始潜心于Puppet的开发。
然后呢
然后就没有然后了,随着Puppet的发布和版本的快速迭代,以及社区的火热发展,Puppet自然而然地就发展成了今天的模样。本来是要开始深入技术细节展开介绍,但是应广大群众要求保持纯八卦风格的呼声,下半部分在内部审批时被惨无人道地砍掉。对于Puppet和Luke的介绍到此告一段落,咱们再来八一下群众们喜闻乐见的热点事件。

投资风云
事情源于两年前,VMWare作为Puppetlabs的6家投资公司之一,向Puppetlabs投了850万美刀。在今年的2月份,VMWare宣布提高对PuppetLabs的投资:3000万。此外,VMware负责云架构和管理的执行副总裁Raghu Raghuram将进入Puppet Labs董事会。
这从资本市场的角度说明了Luke和Puppet的成功,叫好又叫座。但是也引发了人们的担忧:一些人认为Puppet的独立性是非常重要的,理由是DevOps的成功非常依赖于这个组织选择什么样的工具用于企业基础设施管理,Puppetlabs作为IT自动化管理领域里的领头羊,然而VMware对Puppet存在强大的话语权,目前Puppetlabs花了很大的精力在Puppet企业版本的开发上(Puppet PE),用于和VMWare vCloud Automation Center等产品的集成。这并不是一件好事,可能会使得社区版本和商业版本产生巨大的差距,甚至可能会发生Oracle和Mysql那样的故事。
再看看VMWare的老对手Amazon的反应,即使Amazon在开头提及的文档里承认Puppet是事实上的行业标准,但考虑到它的老朋友VMWare手握对Puppetlabs 2/3的投资,在其新推出的OpsWork服务中清一色地使用了Chef用于系统的配置管理,这是诞生于Puppet之后的另外一款开源的配置管理工具。
再来听听其他人的声音。Matt Asay与Luke是多年的好友,在Lukes与Andrew Shafer创立Puppet Labs后,Matt 曾经提出了许多商业化建议,包括进行融资,但Luke更希望公司保持独立。Matt淡定地回答记者:如果你了解Luke Kanies这个家伙,你就知道保持独立对于他而言是无比重要的事。他在田纳西州长大,不是那种出卖灵魂的人。
Luke在IM上和Matt表达了自己的看法:“向云端转换的趋势将给下一代系统平台管理工具带来无限的机会,对VMware如此,对PuppetLabs亦是如此。即便Puppetlabs被VMware掌控,但这些系统仍构建在开源的基础上,并赋予它们一定的自治权。Puppet拥有活跃的开源生态圈,就像OpenStack一样,是对投资很好的补充。”
最后谈谈我的看法,首先Puppet天生就是开源血统,其社区非常活跃,而且从2.7开始变为更为友好的Apache许可证(之前是严格的GPL)。因此,即使发生像MySQL那样的事情,照样会有另一家MariaDB出现,更何况还有后起之秀Chef在一旁虎视眈眈,VMWare理应不会下这步昏棋。同时,对于指责Puppet只关注于与VMware产品的集成是有失偏颇的,虽然最近PE的动静很大,但是Puppetlabs也花费了很大的精力投入到Puppet-Openstack社区中,在之后的Puppet系列博文中会对此进行阐述。所以,我并不担心Puppet是否会成为下一个MySQL。

我们学到了什么?
在前面洋洋洒洒的一堆八卦中,我简单地谈了一些关于Luke和Puppet的故事。每个人可能都会从中看到不同的东西。对我而言,Puppet之所以能取得成功,我认为有做自己最擅长的事:Luke拥有丰富的运维经验和配置管理工具的开发经验,在此基础上去开发Puppet是获得成功的基础之一;
取其精华:在调研同类工具和产品时,Luke不只看到了其中的不足,还吸收了它们的优点;
志存高远:Luke开发Puppet时候的动机是为系统管理员提供最棒的CMS工具,而不仅为了挣钱,被收购,上市。动机越单纯,成功的概率越大;
敢想敢做:现在去挑选手机,我们几乎不会去考虑手机是不是触摸屏的而是去看屏幕有多大,PPI多高,因为手机是触摸屏这是理所当然的,然而在iPhone之前,触摸屏手机还是很稀有的东西,大家都在往功能更多的方向越走越远;同样,现在在使用Puppet时,会觉得使用声明式配置语言是理所当然的事情,殊不知在Puppet诞生的同时代中,都是清一色的命令式或者过程式的配置语言。
Tags:
分页: 7/11 第一页 上页 2 3 4 5 6 7 8 9 10 11 下页 最后页 [ 显示模式: 摘要 | 列表 ]