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:
Sep 28
如何让history不记住你的执行记录,我们来看一下流程。

1. 通过history 命令查看命令列表
点击在新窗口中浏览此图片

2. 执行uptime ,然后通过history 查看记录
点击在新窗口中浏览此图片

3.通过history 可以查看到刚执行的uptime记录,下面让history 不记录执行的命令,如何操作呢。通过 ls命令前边加空格再次执行。
点击在新窗口中浏览此图片

4. 再次查看history记录,!!没有看到刚执行过的ls命令记录(欺骗成功)。
点击在新窗口中浏览此图片

5. 如果执行的命令前边加空格,默认history命令是不会记录历史的,如何才能让history命令记录加空格的命令呢? 我们可以修改系统的HISTONTROL环境变量来实现,详细看以下。

默认值

HISTONTROL=ignoreboth
改为
HISTCONTROL=ignoredups
再次执行空格加命令
点击在新窗口中浏览此图片
Tags:
Sep 26
作者:研究僧
clip0.02版本:http://blog.puppeter.com/read.php?71
文章地址:http://blog.puppeter.com/read.php?4
Github:https://github.com/puppeter/clip/tree/master/clip.0.01

名字由来
IP数字不容易记忆,所以聪明的人类发明了DNS。DNS把不容易记忆的数字,改为容易记忆的一串有规则的域名,域名又可以解析相应的IP,基于此思路,我们开发了近似DNS的名字服务系统。而在公司内部希望通过名字服务系统在cmdb基础之上把不同的业务(cpu、内存、磁盘和网卡)夹在一起,对于上层可以实现资源互补,对于下层可以方便核算业务成本。所以我们将这名字服务系统命名为“Clip”(夹子)。



什么是Clip
Clip是一款自动化运维工具,适用于海量服务器的管理场景,可以降低系统误操作风险,提高工作效率等。Clip将传统的IP管理纬度替换为String管理纬度,管理方式的改变使海量运维时更加的便捷、可靠与高效。



Clip架构
Clip是C/S架构,它将IP对应String关系保存在Server端,Client端可以下载SDK,通过SDK遍历Server端的String对应IP的关系,并在本地对获取的IP模块关系进行重新的组织与编排。另外,在此基础上Clip还提供了远程命令、文件拷贝、IP组织树遍历、历史命令查看、IP对应String关系正反解析与导入等功能。为海量服务器运维保驾护航,奠定基础。下面来详细介绍以下Clip这款自动换运维工具。

首先,传统服务器管理方式与String管理方式的相比,String管理方式的3点优势:
1) 传统为IP管理方式,IP由4组无意义的数字组成,比较难记忆。与传统方式相比String可以见名识意,方便记忆;
2)  管理海量服务时,IP相似经常会导致运营故障,譬如A模块(10.131.24.37 )和B模块(10.117.24.37) ,后两位数字一致,惯性的认为两个B模块就是A模块,发送配置导致线上故障。通过string管理方式可以很方便的规避此问题;
3) String 可以解析1个IP,也可以解析一组IP ,根据IP也可以反解析String对应关系,这让我们管理一组服务更加的方便。

我们再来看一下String的组成。String由(idc-product-modules-group) 4段组成,了解cmdb的同学会发现它与cmdb的结构很像,4级模块定位一个服务,但是随着业务的发展,笔者觉得4级服务已经无法定位到一个服务,譬如,在一台服务器上混合部署不同的业务模块,这里4级只能定位到服务的IP级别,而无法精确定位到真正的服务,所以Clip在此基础上增加了一级(idc-product-modules-group-port),port端口,通过5段定位一个服务,这也是Clip优势,灵活变换来定位一组服务,满足业务需求。

再来举一个实际的例子,上海机房,A模块使用80端口提供服务,目前有100多个机器 ,B模块使用8080端口提供服务,目前有100多个机器,由于业务流量下降,为了节约资源目前想将两个模块200台机器资源合并,但功能不合并 。我们可将两个服务表示到不通的String中,如A模块(sh-weixin-friend-a-80), B模块(sh-weixin-friend-b-8080),通过String就很容易的将两个服务分别开,并部署在相同的服务器上提供服务了。
刚介绍到Clip 为C/S架构 ,String对应的IP关系保存在server服务器中,Client 通过Clip的SDK获取IP ,其优势3点:
1) IP与String建议一次关系后,所有的的服务器上通过SDK都可以调用到。
2)SDK在解析IP的基础上提供了其他丰富的功能,如扫描服务器,远程命令,远程拷贝等。
3)Clip 提供简单清晰的API与SDK代码结构与文档,当Clip不能满足我们需求时,可以通过文档很容易的扩展Clip 满足自己的需求。

接着我们来看Clip SDK,目前SDK共有8个子命令:
点击在新窗口中浏览此图片
各SDK子命令功能如下:

scan:用于对String对应的IP进行端口存活状态扫描;
cstring: 用于对String对应IP解析,与IP对应String关系的解析;
ssh:用于对String对应IP,远程执行系统命令;
scp:用于对String对应IP,远程拷贝文件;
tree: 遍历String下的子节点;
history:显示历史执行过的命令;
import: 导入IP对应String关系;
lt: 从本地获取IP关系进行管理;
help: 显示Clip子命令。




传统方式vs clip管理方式
传统方式:
在 A 模块的100台服务器上,执行uptime命令,具体的操作步骤如下:
1) 找到要同步的A模块ip列表;
2) 编写脚本与ip列表中的服务器建立连接;
3) 连接服务器时输入账号密码;
4) 账号密码认证成功后拷贝文件;
5) 在每个IP重复以上步骤。

Clip 方式:
1)建立A模块ip列表与string对应关系,譬如为tj-qzone-qzoneini-access6;
2)clip ssh   -p 密码  root@tj-qzone-qzoneini-access6  “执行命令”,以下为结构。
点击在新窗口中浏览此图片



Clip Server安装
1)  安装Apache\PHP和MySQL

# yum install httpd  php msyql mysql-server

点击在新窗口中浏览此图片
2) 安装Clip WEB接口程序。(注: Clip WEB程序由Doitphp框架开发)
2.1) mkdir -p /data/webroot/  (创建http虚拟主机发布目录)
2.2)

wget  http://blog.puppeter.com/download/clip/clip_web.tar.gz

2.3)

tar -xvzf clip_web.tar.gz -C (Apache程序发布目录/data/webroot/)

2.4) 配置httpd.conf ,追加虚拟主机配置信息。

NameVirtualHost *:80
ServerAdmin wds@tencent.com
DocumentRoot /data/webroot/clip_server/
ServerName clip.puppeter.com
ErrorLog logs/clip.puppeter.com-error_log
CustomLog logs/clip.puppeter.com-access_log common


2.5) 启动httpd。
3)service mysqld start 启动Mysql
3.1)

wget http://blog.puppeter.com/download/clip/clip_db.tar.gz 下载表结构

3.2 ) mysql -u root -p  进入mysql,导入表结构

mysql-> create databases clip 创建clip库
mysql-> mysql -u root -p clip < clip.sql 导入数据表。
SET PASSWORD FOR ‘root’@’localhost’ = PASSWORD(‘newpass’); 设置mysql密码
FLUSH PRIVILEGES; 刷新mysql配置

4 ) 设置Clip WEB连接mysql
1) 编辑 /data/webroot/clip_server/application/config/clip.ini.php

Clip SDK安装
Cllip SDK 由Python开发,以下为Clip依赖环境安装过程:
1) 下载安装Python  (注:目前支持Python 2.6.*  和 2.7.*版本)  && expect

# yum install python expect

点击在新窗口中浏览此图片
# python源码安装,推荐2.6.6(下载页面:https://www.python.org/download/releases/2.6.6/)
2)  下载Clip SDK

# wget  http://blog.puppeter.com/download/clip/clip_latest.tar.gz

3) 安装Cllip SDK

# tar -xvzf  clip_p1.0.tar.gz -C /usr/local/servcers (注:指定安装目录)

4) 设置Clip。 编辑 clip/conf/clip.ini 文件,变更server_ip选项为Clip_webIP
点击在新窗口中浏览此图片
5) 导入环境变量

export PATH=$PATH:/usr/local/services/clip/ (安装路径)

或者

echo ‘export PATH=$PATH:/usr/local/services/clip/ ‘ >> /etc/profile && source /etc/profile

5) 执行Cllip命令 (见截图)
点击在新窗口中浏览此图片


Clip SDK使用
Clip SDK 功能用于获取Server上的IP关系,并在Client上重新组织编排IP关系。(注:目前clip也支持将IP存放到本地文件中管理)。目前Clip 提供8个子命令,以下Clip子命令的参数解释与演示(更多案例参考:Clip SDK 案例):
clip scan (用于对String对应的IP进行端口存活状态扫描)

--query_string(-q)# 根据String扫描IP的端口
--ip (-i) # 扫描指定IP的端口
--query_string (-q) *-test-*-*,*-docker-*-* # 多String扫描用逗号分隔
--append (-a) # 在原有String基础上,追加IP,追加多个(192.168.0.1,192.168.0.2)IP用逗号分隔
--remove_ip (-r) # 删除String原有IP列表的IP
--limit(-l)# 扫描String中指定范围的IP范围
--port (-P) # 指定自定义扫描端口(注:默认为80端口)
--log_disable(-o)# 默认日志会上报服务器,并通过history命令查看历史,通过此命令可以关闭日志上报,建议频繁使用clip关闭clip

clip scan 使用演示:
扫描*-puppet-*-* 对应开放的端口
点击在新窗口中浏览此图片

clip cstring(正解与反解String对应IP关系)

--query_string(-q)# 解析String对应的IP列表
--ip (-i) # 解析IP对应的String
--query_string (-q) *-test-*-*,*-docker-*-* # 解析多个String对应IP列表,多String用逗号分隔
--limit(-l)# 解析String中指定范围的IP范围
--append (-a) #在原有String基础上,追加IP,追加多个(192.168.0.1,192.168.0.2)IP用逗号分隔
--remove_ip (-r) # 删除String原有IP列表的IP
--join (-j) # 指定输出的格式,支持(“&#124;” “,” “\n”,space) 4种格式输出
--log_disable(-o)# 默认日志会上报服务器,并通过history命令查看历史,通过此命令可以关闭日志上报,建议频繁使用clip关闭clip
--count (-c) # 统计输出IP个数
--dryrun (-d) # 输出调用接口用例

clip cstring演示:
解析*-qq-*-* 对应的IP关系。
点击在新窗口中浏览此图片
解析192.168.0.7 对应的String。
点击在新窗口中浏览此图片

clip ssh (远程命令执行工具)

--password (-p) # 密码
--append (-a) # 在原有String基础上,追加IP,追加多个(192.168.0.1,192.168.0.2)IP用逗号分隔
--remove_ip (-r) # 删除String原有IP列表的IP
--limit(-l)# 解析String中指定范围的IP范围
--port (-P) #指定自定义端口(注:默认为22端口)
--dryrun (-d) # 输出调用接口用例
--log_disable(-o)# 默认日志会上报服务器,并通过history命令查看历史,通过此命令可以关闭日志上报,建议频繁使用clip关闭clip

clip ssh演示:
查看string(sh-docker-base_v1-*) 对应机器上负载.
点击在新窗口中浏览此图片
查看string(sh-docker-base_v1-*)的第一台服务器对应负载
点击在新窗口中浏览此图片

clip scp (远程命令执行工具)

--password (-p) # 密码
--append (-a) #  在原有String基础上,追加IP,追加多个(192.168.0.1,192.168.0.2)IP用逗号分隔
--remove_ip (-r) # 删除cstring原有IP列表的IP
--limit(-l)# 解析String中指定范围的IP范围
--port (-P) # 指定自定义端口(注:默认为22端口)
--dryrun (-d) # 输出调用接口用例
--log_disable(-o)# 默认日志会上报服务器,并通过history命令查看历史,通过此命令可以关闭日志上报,建议频繁使用clip关闭clip

clip scp演示:
将ip文件推送到string(sh-docker-base_v1-*)对应机器的/tmp目录上。
点击在新窗口中浏览此图片

tree(String关系遍历工具)

--query_string(-p) # 密码
--json (-j) # 指定输出的格式
--dryrun (-d) # 输出调用接口用例
--log_disable(-o)# 默认日志会上报服务器,并通过history命令查看历史,通过此命令可以关闭日志上报,建议频繁使用clip关闭clip

clip tree 演示:
遍历*-*-*-* 下的节点
点击在新窗口中浏览此图片

import(IP关系导入工具)

--insert (-i) # 将文件内的clip对应关系导入数据库
--bulid (-b) # 创建clip导入数据库,关系模板文件
--list_struct (-l) # 显示clip数据库结构

clip import 演示:
clip import -b 创建导入string与关系模板
点击在新窗口中浏览此图片

lt(Local tools 本地获取IP关系管理工具)

--password (-p) # 密码
--append (-a) # 追加IP,多个IP用逗号分隔
--remove (-r) # # 删除原有IP列表的IP
--port (-P) # 指定自定义端口(注:默认为22端口)

clip import 演示:
clip lt 根据本地文件IP文件,进行远程ssh command,其中root@“本地IP关系文件名”
点击在新窗口中浏览此图片


接口文档
见:https://github.com/puppeter/clip
Tags: , , , ,
Sep 23
作者:研究僧
文章地址:http://blog.puppeter.com/read.php?4

背景
由于历史的原因我们的机器目前还是单机或单集群对应一个业务模块的形式,优势应对爆发式增长扩容方便,成本结算简单。但是随着网民的饱和,相同业务模块下移动流量上涨,PC流量直线下降,很多业务出现了低负载情况,海量服务器运维中只要有1%的低负载(既机器利用率不饱和)规模也是惊人的,在实际运营中低负载+长尾模块机器数量可能达到了25%-30%之间,当然这里也不排除业务对流量做了冗余与灾备,但是多个业务模块的灾备就会出现浪费资源的情况。我们从运营中发现了这问题的存在,而运维的核心价值也是通过技术优化,能在(成本、质量、效率与安全)四块做优化达到一个很好的收益,所以从2014年中我们开始做离线业务部署项目。项目的思路是通过高负载业务(离线计算)与低负载业务进行混合部署,提升低负载机器利用率同时逐步下线高负载业务的机器为部门节约机器成本。不过经过半年多的运营中我们也发现了很多问题,离线业务的负载均衡权重统一,但是混合部署后的机器负载不均有高有低,混部的结果经常会导致部分机器高负载影响业务,可以看出这里缺少监控负载的和业务合理的手段,经常导致高负载业务影响低负载业务,接口超时影响用户的情况,这是我们不希望看到的,所以总结经验教训,在2015年上半年我们重新打磨项目开发了离线业务混合部署(琥珀自动调度系统)项目,新项目与老项目相比通过docker技术将混部业务控制在容器中,消除争抢资源对业务影响,同时对容器流量进行根据负载调度,在此基础上实现了分时调度等功能。见截图1
点击在新窗口中浏览此图片
希望通过技术架构优化与升级来充分扎干硬件资源,为公司节约服务器成本。在开发过程中,相关业务也向我们提出了以下需求(已经实现功能见图2):
1.机器主动与被动下线不影响在线业务;
2.可以方便的查看到系统运行状态;
3.可以连接到容器内部查询日志以及debug程序;
3.沉淀各系统日常数据,并根据沉淀的数据进行戳峰调度。
点击在新窗口中浏览此图片
系统访问逻辑及接入方式
根据系统需求,最终访问逻辑分为三部分(用户接入、程序逻辑、和容器生成),每层之前交互通过接口,尽量把复杂的逻辑对上一层透明,见图3。
点击在新窗口中浏览此图片

琥珀系统提供两种接入方式:
方式1:
  通过vip方式接入(推荐),用户不必关心底层系统。首次接入将业务环境打为docker,并测试。后续业务流量通过vip引入计算集群(注:计算集群与首次docker业务环境一致),用户不必关系集群内部机器数量与机器状态,系统保证相应的计算量已经容灾调度。见图4
点击在新窗口中浏览此图片
方式2:
  业务流量通过接口获取动态IP列表,并将流量下发到列表IP中。当机器下线接口主动通知业务流量踢IP。与方式1同样首次接入需要打docker镜像源。见图5
点击在新窗口中浏览此图片

系统架构
我们通过介绍开源软件(docker + haproxy + confd + etcd+ clip)来完整整个琥珀系统的架构,见图6
点击在新窗口中浏览此图片

其中开源软件(docker + haproxy + confd + etcd+ clip)介绍如下:如下:
1.Docker(官方网站:https://www.docker.com/)是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的 Linux 机器上,也可以实现虚拟化;
2.HAproxy (官方网站:http://www.haproxy.org/ )为负载均衡软件可以根据IP权重自动分发流量,支持8种负载均衡算法;
Confd(官方网站:https://github.com/kelseyhightower/confd)是一个轻量级配置管理工具,它可以从 etcd, consul, dynamodb, redis,zookeeper 或 env获取最新的数据更新本地模板文件;
3.Etcd (官方网站:https://github.com/coreos/etcd) 是一款高可用的键/储存储系统,主要用于服务发现与共享配置,同时聚焦;
   简单:支持 curl 方式的API (HTTP+JSON);
         安全:可选 SSL 客户端证书认证;
         快速:单实例可达每秒 1000 次写操作;        
         可靠:使用 Raft 实现分布式。
etcd是由CoreOS开发并维护使用Go语言编写,并通过Raft一致性算法处理日志复制以保证强一致性。目前很多大项目都使用了etcd,如:Google的Kubernetes、Pivotal的Cloud Foundry、Mailgun、Apache Mesos与Mesosphere的DCOS。除开这些大型项目,在GitHub上还有超过500个项目使用了etcd;
4.Clip是(cmdb + tools)的结合(官方网站:http://blog.puppeter.com/read.php?7)。将传统的对IP管理维度替换为String维度,其中String格式为(机房-产品-模块-组-端口),通过Clip可以对IP进行打标签,并根据便签对应属性形式区分服务来源。

程序安装
1)HAproxy安装

# wget http://www.haproxy.org/download/1.5/src/haproxy-1.5.14.tar.gz
# tar –xvzf haproxy-1.5.14.tar.gz  && cd  haproxy-1.5.14
# make install

HAproxy源码编译安装,启动和关闭建议采用以下方式。

# 重启
$ haproxy  -f /etc/haproxy/haproxy.cfg  -p /tmp/haproxy.pid
# 热重启
$ haproxy -D -f /etc/haproxy/haproxy.cfg -p /tmp/haproxy.pid -sf $(cat /tmp/haproxy.pid)


HAproxy 二进制命令参数

-d 前台,debug模式
-D daemon模式启动
-q 安静模式,不输出信息
-V 详细模式
-c 对配置文件进行语法检查
-s 显示统计数据
-l 显示详细统计数据
-dk 不使用kqueue
-ds 不使用speculative epoll
-de 不使用epoll
-dp 不使用poll
-db 禁用后台模式,程序跑在前台
-sf 程序启动后向pidlist里的进程发送FINISH信号,这个参数放在命令行的最后
-st 程序启动后向pidlist里的进程发送TERMINATE信号,这个参数放在命令行的最后
-d 前台,debug模式
-D daemon模式启动
-q 安静模式,不输出信息
-V 详细模式
-c 对配置文件进行语法检查
-s 显示统计数据
-l 显示详细统计数据
-dk 不使用kqueue
-ds 不使用speculative epoll
-de 不使用epoll
-dp 不使用poll
-db 禁用后台模式,程序跑在前台
-sf 程序启动后向pidlist里的进程发送FINISH信号,这个参数放在命令行的最后
-st 程序启动后向pidlist里的进程发送TERMINATE信号,这个参数放在命令行的最后

HAproxy优化

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_max_tw_buckets = 5000

2) confd安装
Confd的用途是监听etcd中键值变化,并根据变化更新模块中的数据。(注:这里confd 需要安装在HAproxy相同机器)

wget https://github.com/kelseyhightower/confd/releases/download/v0.6.3/confd-0.6.3-linux-amd64  
# mv confd /usr/local/bin/confd  
# chmod +x /usr/local/bin/confd  
# /usr/local/bin/confd -version  
# mkdir /etc/confd/{conf.d  templates}

在conf.d目录中创建haproxy.toml文件。haproxy.toml是confd的配置文件,其作用是当etcd中的数据发生变化,根据haproxy.toml中的(src)模板信息重新生成目标(dest) 模板,最后重新加目标程序配置文件。它支持所有带配置文件的软件,譬如(nginx,apache,haproxy,lighttpd)等。以下为haproxy.toml文件内容。

haproxy.toml
[template]
src = "haproxy.cfg.tmpl"
dest = "/etc/haproxy/haproxy.cfg"
keys = ["/app/servers/","/app/weiyun"]
reload_cmd = "/usr/local/services/hupo/haproxy-1.4.21/haproxy_reload"

在templates目录中创建haproxy.cfg.tmpl文件,内容如下(注:haproxy.toml中的keys与haproxy.cfg.tmpl模板中遍历的数组要一致):

global
   maxconn 2000
uid 99
gid 99
   daemon
   nbproc 10
   #debug
   #quiet
defaults
        retries 3
        option redispatch
        maxconn 10000
        contimeout      5000
        clitimeout      50000
        srvtimeout      50000
#       stats uri /haproxy-admin
listen  admin_stat 0.0.0.0:8080
        mode http
    stats refresh 70s
        stats uri /admin_stats
listen  tcp-in 0.0.0.0:1991
        mode tcp
        balance roundrobin

{{range gets "/app/weiyun/*"}}
        server {{base .Key}} {{.Value}} check inter 5000 fall 1 rise 2
{{end}}

{{range gets "/app/servers/*"}}
        server {{base .Key}} {{.Value}} check inter 5000 fall 1 rise 2
{{end}}


关于模板更多内容见(https://github.com/kelseyhightower/confd/blob/master/docs/templates.md)

3)etcd安装

# wget https://github.com/coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz
# tar -zxvf etcd-v0.4.6-linux-amd64.tar.gz
# cd etcd-v0.4.6-linux-amd64
# cp etcd* /bin/

启动

# etcd  -name ip_data   -addr IP:4001 -data-dir 数据文件地址 -bind-addr IP:4001

其中etcd常用参数如下:
-name:节点名称;
-addr : 客户端连接地址与端口;
-data-dir: 数据文件存储地址;
-bind-addr:绑定IP + 端口;
其中RESET-API例子

# 增
$ curl -L -X PUT http://127.0.0.1:4001/v2/keys/message -d value="Hello"
{"action":"set","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
# 查
curl -L http://127.0.0.1:4001/v2/keys/message
{"action":"get","node":{"key":"/message","value":"Hello","modifiedIndex":4,"createdIndex":4}}
#删
$ curl -L -X DELETE http://127.0.0.1:4001/v2/keys/message
{"action":"delete","node":{"key":"/message","modifiedIndex":19,"createdIndex":4}}


分页: 7/7 第一页 上页 2 3 4 5 6 7 最后页 [ 显示模式: 摘要 | 列表 ]