本人于2009年12月迁移至独立BLOG。
1、欢迎光临运维进行时,希望认识更多志向相同的朋友!
2、本站部分资源来源于网络,如有侵权请及时与我联系!
3、强烈建议使用Firefox、Opera、Safari及IE7以上的浏览器访问,以获得最佳浏览质量!
4、请勿发表与中华人民共和国法律、法规相抵触的言论,谢谢合作!
5、本人发布的文章与评论内容仅代表本人观点。
分页: 1/30 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]
        2016年12月3日,在深圳圣淘沙酒店,运维帮、云技术、Linux中国三大社区联合主办主办了运维世界大会OpsWorld,演讲内容全程无广告,只谈技术,受到了广大观众的一直好评。本文根据刘天斯老师演讲内容整理而成。
点击在新窗口中浏览此图片
        我分享的主题是“DevOps持续改进之道——布道”。我刚才已经做了简单的介绍,这里再罗嗦一下,我叫刘天斯,现在是在腾讯互动娱乐负责大数据的运营。在互联网行业已经从业了13年,也算是一个老鸟,之前在天涯,工作了6年多。PPT右侧是我的两本著作,第二本是关于Docker的,如果大家关注Docker,可以在网上购买这本书来看看。我个人最近关注的方向有自动化运维、云计算、大数据、Docker  DevOps等。
点击在新窗口中浏览此图片
        这是我今天分享的大纲,总共分四大块,第一块是跟大家简单介绍一下我的DevOps观,第二点我会介绍我们布道平台在持续集成与交付这块是怎么做的。第三点会介绍布道在线服务运营能力。最后给大家做一个总结。
点击在新窗口中浏览此图片
        可能大部分人都认为DevOps无非是基于文化+技术这两个点在企业里面落地,这是大部分人之前的思维,在2015年底举行的全球DevOps峰会上,Gartner把DevOps做了进一步的划分,在文化和技术后面又细化出了过程和人。DevOps并非目标,但它可帮助您实现目标,企业的目标是更快地交付价值,DevOps是辅助我们完成这样一个目标的手段。
        DevOps产生的价值,我比较认同IBM给出的解释,总共有三点,第一,它认为这个会增强客户的体验。这是比较容易理解的,第二点是提高创新能力,这个不好理解,创新和它有什么关系呢?它的说法是这样的,通过DevOps去实践,通过精益的方法论去减少我们的浪费、返工,将我们现有的价值及精力投入到更有价值的事情,创新是其中的一个非常重要的点。第三个就是更快的实现价值。
        DevOps应该是永无止境的,它是一个持续改进的过程,它没有终点,它的目的是对影响交付质量的对象进行持续的改进,包括我们的技术、流程、团队,甚至企业的文化等。
        那我们怎么去检验我们的软件交付过程是不是高效的?我个人总结了一个“短”五个“快”。短就是我们交付软件的开发周期要短,快就是排错、解决问题、测试、部署、反馈这个闭环一定要快,不知道大家认不认可这样的观点,一会儿我们可以讨论一下。
点击在新窗口中浏览此图片
        Gartner在去年底提出DevOps的模型,它分为四个点,除了文化、技术,它还延伸出了过程和人这两个角色。我们首先从【技术】来看,这里面加亮的部分是重点要关注的,一个是【基础设施即代码】,第二个是【一键安装程序构建,测试、部署】,第三个是【监控一切】,第四个是【连续监控】。在【过程】里面,我认为应该关注的是【持续集成】、【测序】、【交付】这几个方面,另外还要关注到【自动化的构建】,包括【自动化发布】。我觉得【失败总结】这一点是比较重要的,当我们过程失败之后,必须要知道失败在哪里,要进行总结。另外一个是一切都要工具化,一切都要版本化。除了代码以外,我们的脚本或者是配置文件都要通过版本化进行管理。在文化这部分,我认为比较重要的就是协作的文化,还有持续的改进,还有学习的文化,这三个都不难理解,但是我认为,这里面是不是还遗漏了一点?我觉得少了信息的共享、透明,我认为这是非常关键。为什么这个很重要?在我们内部定期都会组织相关的讨论会,去讨论我们项目中碰到的问题以及风险,这些都是需要关注的,另外一点就是IBM提出的一个概念,运维要“左移”,意思是运维要在开发的生命周期阶段提前介入。这样做有什么好处呢?好处是有助于运维的问题提前在开发阶段提前暴露,我认为这是非常关键的一点。
        下面简单介绍一下我们服务的背景,我们为谁服务,服务什么样的平台。大家看一下我们的规模,当前的数据量每天入库7600亿条日志,大概80T,占公司总存储的26%。
点击在新窗口中浏览此图片
        这是我们的服务精细化的场景,这个背景是怎么来的?因为我们已经具备了海量的游戏数据,我们也在思考,怎么通过数据去驱动我们做精细化的运营。这也是我们目前不断在思考的。DataMore是我们思考出来的一个解决方案,它目前包括三个层次,第一个是大数据H5应用,比如说我们经常看到朋友圈大家分享的自己玩游戏的对局信息,这些数据都是由我们这边提供的。第二个是场景化的标签服务,我们会针对不同玩家打标签,打完标签就通过我们的精细化触达平台,针对性的做一些触达和营销活动。第三个是应用产品,比如说我们的游戏助手、官网,甚至是游戏里面的个人中心,大家会看到自己在游戏中的状态、成长轨迹、对战信息等,这些都可以看到,这就是游戏业务典型的一个服务化的场景。
点击在新窗口中浏览此图片
        下面再介绍一下我们的数据服务的架构,这个其实也没有太多的技术含量,基本上都是业界主流的能力,包括最左侧的游戏的数据源,它有两类,一类是游戏内的,一类是游戏外的。平台组件有三大块,一是数据接入,数据接入包括实时传输、离线传输,第二个是数据处理,包括实时计算引擎、离线引擎,第三个是数据储存,包括KV存储、DB存储、位图索引、HDFS等。我们的服务引擎这一块包括数据分析引擎、数据接口中心、运营规则引擎、用户触达中心,业务应用就是报表统计、数据分析、触达运营,总体来讲就是包括这样三块:数据采集、存储计算、应用落地。
点击在新窗口中浏览此图片
        这是我们的DataMore体系的技术架构,整个架构层次也比较简单,最上层是STGW,这是腾讯非常强大的一个负载均衡平台,再下面是二级代理。逻辑层我们现在有GoServer  PHP Server。实时数据层用的都是业界主流数据库存储技术,比如TRedis、Hbase、Postgresql等。最低层是数据计算层,包括实时计算引擎、离线计算引擎。当前整个服务的PV大概是6.35亿,日发布变更15次,单次发布时间是10秒,也就是一个容器起启的时间。
        下面介绍一下今天的主角“布道”。布道是我们数据服务全流程解决方案,采用了DevOps的思想实现软件的快速迭代、快速试错,最终提升软件交付的质量和达到持续改进的目的。它有几个特点,第一个是基于腾讯蓝鲸PaaS平台快速构建。蓝鲸本身就是一个PaaS平台,我们基于蓝鲸之上构建服务层的SaaS,本身布道就是基于最上层的SaaS服务。第二个是建立在DevOps的思想实践。我们这个实践思路来源于我刚才分享的Gartner发布的DevOps模型。各关键节点间之间的联系都是我们参考的样本。第三是面向运维、开发、测试、项目PM。第四个是具备持续集成、交付、部署等快速迭代的能力。第五是具备服务质量跟踪、用户舆情、持续反馈能力。
点击在新窗口中浏览此图片
        这是布道的能力体系,大家可以看一下,实际上包括两大块,一个是持续集成交付,另外一个是在线运营。其中服务质量和持续改进是贯穿整个服务生命周期。点击在新窗口中浏览此图片
        这是布道服务层的架构,刚才提到了这一块,第一块持续集成&交付是采用业界主流的架构,且比较通用,我就不详细再讲了。我们的在线运营是基于HECD的架构,实现Docker的发现注册与发现,最上层就是我们的接入层,比较简单高效,因为没有太多其它逻辑关联耦合的节点。这里的TDocker是部门内部基于Docker构建的容器服务解决方案。
        以DevOps形成的运营服务闭环,它的内涵及核心就是实现持续改进。首先通过我们的CICD的快速通道,实现软件平台的快速迭代,在质量管理方面,我们通过监控、安全、故障自愈、BUG修复等方式进行质量管理。在用户反馈方面,我们建立一个通道,会收集并响应用户的反馈,包括来源于客服和对外网舆情的采集,会将这些信息反馈给开发人员,开发人员收到反馈之后,会在功能或者bug这一块做功能修复,最终就会形成一个持续改进的闭环,而且是一个良性的闭环。
点击在新窗口中浏览此图片
        再简单介绍一下我们持续集成&交付的架构,刚才已经有提到,这里就简单说一下里面的几点细节。首先采用Docker架构具有一些优势,它可以保持跨环境一致性,天然易移植性,还有易于版本控制。然后CI&CD在流程方面做到编译并构建版本镜像,推送镜像仓库,触发交付作业并快速实现预览。
        以上介绍的是行业的主流做法,各家的方案都是大同小异的,我们在这个过程中加入了一些独特的东西,一个是代码扫描的工具coverity,它能够发现比较深层次代码逻辑问题,比如内存泄露、溢出、数组越界、未初始化等等,且目前支持的语言也比较多。
        另外一个是通过引入外网的流量,帮助我们实现压测,甚至做到一定BUG定位,它能达到百分之百的仿真的效果,具体的细节大家简单看一下PPT,整个步骤也非常简单,不是很复杂,它的特点是可以达到真实的模拟测试验证,有助于提前发现问题,有效降低发布风险。
点击在新窗口中浏览此图片
        这是一个案例,开发人员提交他的版本,然后进行预发布,在预发布里面有预览校验软件功能,也可引入外部的流量来进行预览,出现BUG会这个过程中被发现。我们在实践过程中碰到几点问题,在这里也跟大家一起分享。第一点是在容器中做源码的编译合不合理,不知道大家是怎么做的,我们给的结论是不合理。每个项目它用的第三方包或者功能组件是不一样的,可能A项目用的是A、B、C组件,B项目用的是1、2、3组件,不同的组件你在编译的时候去部署它的编译环境,这样会使我们的容器越来越臃肿,所以我们把这个环境迁移到另外一种角色(jenkinsslave),让它做源码的编译,编译完了就打包成镜像,保证镜像中没有太多无用的数据文件。第二点是容器性能的监控最优方案。我们使用Docker的时候有没发现一个问题?在容器中无论我们执行free、top、uptime、vmstat等命令,看到的都是主宿机的性能信息,原因是由于Docker的隔离性做得不够彻底导致。我们可以通过LXCFS这个组件帮助我们增强Docker的隔离性,它可以提供一个虚拟的PROC文件系统,另外也提供了容器自身的Cgroup的目录树,跟容器中的PORC目录是一一对应的。如何使用?我们Dockerrun的时候,通过“-v”参数,实现容器proc文件与Lxcfsproc的映射,效果是容器中看到的只是容器本身的内存、CPU等信息。比如说我们看CPU核数,看到的只是分配好的0、1、2、4的核数。第三点是容器在CI阶段的网络选择。这里只是给个建议,我们生产环境Tdocker使用的网络模型SRIOV,是通过硬件虚拟网卡的方式实现,然后Docker再通过IPlink做映射,但是我们在CI阶段,它是一个隔离的开发专区,它跟普通的IDC是不一样的,由于硬性相对比较老久,硬件虚拟化兼容性差,因此我们使用了Docker Macvlan方案,原理是通过创建网卡子接口与容器接口之间做映射,缺点是要求Linux Kernel 3.10.0及Docker>=1.12.0的环境。
        这是我们的线上服务。项目上线的时候,每个PM都有一个习惯,都会最大化去的申请资源,在极端情况下还会远远超过他的预估值,这个时候怎么办?只需要评估扩容的需求量为多少,什么样的机型配置,提交Tdocker在线扩容就可以了,后面的事情就交给布道去处理。
点击在新窗口中浏览此图片
        在告警方面我也分享一些思路,在腾讯已经有一套非常成熟的告警系统,我们在这里只是提供一些跟我们业务逻辑相关的策略,我们的思路首先是统一日志规范,每个人的开发水平和习惯都不一样,我们给他们统一一个规范,这个规范叫Tlog,另外引入基础+特性这两个指标。看到的这个DEMO,它通过XML的模式描述日志的结构。特性是跟业务绑定相关的,我这里有一些服务,这个服务我发了一些金币,发到某个区间可能出现问题了,我们就需要开发人员把这个发放的数值打印出来,我们好做一个曲线的跟踪。采集完之后就会进入一个日志采集环节,这个架构也很简单,就是LVS+Keepalive,采集完之后,这里就分两条线,一个是实时,一个是离线的。我们采用的是蓝鲸的实时数据平台,能够实现特性指标多维度的配置。
        这是蓝鲸的智能监控的界面。它是实时流,内部用的是Storm做实时分析,然后支持定义灵活的配置,有支持SQL的函数,比如支持某个字段的累加、求和,这个频率可以控制为10分钟、15分钟。
点击在新窗口中浏览此图片
        下面是我们安全这一块做的东西,首先是安全防御,在腾讯内部,安全这一块已经做得非常强悍,为什么我还讲安全呢?因为在公司层面做的安全防护更多是通用性或者基础类的防护,WAF更侧重在业务逻辑层,它的架构非常简单,通过布道做一些规则的下发到WAF,例如XSS、CC、UA、URI的规则等等,然后开启日志追踪,通过传输、实时分析防护日志,最终做到防护报告实时展示。
        规则校验步骤与大家简单介绍一下,目前采用Nginx+LUA结合的方式,它的防护流程是在检查端口及域名是否匹配规则,匹配就下发规则,然后检查黑白IP名单,后面再开启CC防护,以及开启userAgent检查,最后是开启URI检查注入、XSS、SSRF等。
        下面是舆情监控这一块,我们在这里特点就是关键词的实时监控、定时报送推送。从下面这个图可以看到,某一款游戏在某此活动期间的口碑展示情况,有多少是正面的,有多少是负面的报告。
点击在新窗口中浏览此图片
        最后做一个总结,在线运营的运营经验,第一个是资源评估,我们要定一个标准,根据实际服务场景来做出评估,而不是拍脑袋做。这个评估有一个公式:设计数量=(PV/86400)×2/单机承载最大QPS/0.8。
        第二个是灰度+热力度对蓝绿发布。蓝绿发布的目的是让我们的用户没有感知,我们做蓝绿发布,操作的步骤很多,一旦人工接触多了,就容易出现误操作。我们采用的是热更新方式,原理是服务A进程收到关闭信号量之后,启动B进程来接收已经创建的连接或新连接,当A进程连接完全释放之后就会自动关闭,整个过程用户无感知。灰度实际就是放量检验这个效果及功能,如中间没有出现问题,只需两步就完成变更。
        第三个是修复了Supervisor一个bug。Supervisor没办法对进程fork子进程进行管理,所以我们修复了这个bug,如大家碰到同样的问题可以私下找我,我会给大家具体的解决方法。
        最后是一个数据流向监控的实现思路。首先简单介绍一下为什么要做这个流向监控。数据的流向监控在业界目前没有较好的方案,当我们的数据链、处理链、服务链拉得很长的时候,如何感知当数据源头有发生变更或异常,影响到我们的最终服务,这是非常难度的,而且它跟我们的业务特点关系非常大。同样我们逆向推导也是成立的,我发现玩家的某个对局数据不对,本来是胜局结果变成了负局,怎么确认数据是从哪个节点负责计算或存储的?这个非常有挑战性,这需要我们的数据服务能力一步一步做叠加,需要不断做扩展与关联,才能够达到某一个层次的服务水平。目前我们做的还没那么完美。首先我们要具备元数据管理,还有元信息的管理,这是非常重要的两层。第二个是要有数据字典管理,我们给数据表名称、字段说明,结构性的定义及标签。第三个就是血缘关系,能够定义到任务之间的关系。第四个是数据服务的注册,这是比较核心的一点,怎么注册,我们怎么知道你用了哪个数据源呢?这很关键,我们内部开发了一个通用组件,比如说你要引用后端的数据层,你必须使用这个组件接入,这样关系才能够建立起来,所以应用配置文件也是单独生成的。而最上游我们会提供一个数据流向查询,我们用了A数据,查下来就知道它在这个过程经过了哪些关键点,有可能是存储、计算、分析、接口等。点击在新窗口中浏览此图片
        最后快速做一个总结,这是我们的持续服务的体系,在持续运营状态下,我们具备质量监控、舆情监控、容量管理、安全管理、故障治愈、故障修复等能力,同时收集用户服务体验、产品、BUG、新功能、吐槽点,将这些信息反馈给产品人员、开发人员和运维人员。再通过持续集成交付、发布变更管理,做到快速迭代及部署,最后就形成了良性的、持续改进的闭环。

1、【提问】:你刚才提到了资源分配的公式,你们那个公式是怎么总结出来的?那个公式的基础是以什么样的结果作为标准的?
【刘天斯】:这个公式也不是我们发明的,也是借鉴了很多前辈思路,我们只是在这个基础上做改进,结合我们自己的业务场景,包括我们服务是什么样的类型,因为服务类型不同,它的要求不一样,配置不一样,它的生命周期也不一样,它能够反映出来的效果和能力、访问量都不一样,比如服务到底是CPU型还是内存或IO型,完全不一样。这就带来一个问题,我们怎么定一个标准?我们目前聚焦在接入这块的逻辑层,供参考的是8核、4G内存,硬盘100到150G的配置。

2、【提问】:我是来自创维公司负责运维的。今天讲的是DevOps,DevOps要快速迭代到什么样的程度才行?像您现在做的一个平台一天发布15次,我不知道你在前面需要进行多长时间的准备?比如说线上的实时导流导多长时间是合适的?这个度我们一直拿捏不准,能帮我们解答一下,提点好的建议吗?【刘天斯】:在互联网行业我们大部分都是采用敏捷开发的模式,这样会产生技术的债务,这是必然的。你是传统行业吗?
【提问】:我们前身是传统行业,现在我们是互联网电视,相当于做电视上的服务,我们是非常快捷的,每天都发布,每天改bug,不停地迭代,而且需求也特别多,开发也忙不过来,我们运维也感觉到准备不足。
【刘天斯】:互联网这种快速发展的模式,势必会带来很多技术的债务,我觉得这是正常的。我们的互联网发展很快,必须要先要有一个雏形产品出来,然后再不断地迭代,这是大部分互联网公司或者是刚刚转型公司采用的模式,这种模式出现的问题我认为是很正常的问题,包括在腾讯也一样有这样的问题,他评估不到我在某个阶段要花多长时间去检验我们是否够快、是否高效。我们在布道这个环节下一步就是预发布,预发布追求的并不是快,而是能不能在临门一脚之前发现一些致命的问题,因此,可以在持续交付阶段追求快,而不应在预发布阶段。

导言
最近比较关注大数据、云计算、Docker、DevOps等几个方向,一会也简单围绕这几点跟大家做个交流。
聊运维人生这个主题有点大,^_^就先从个人怎么入运维这行说起吧。

人在天涯
2003年毕业后的第一份工作是当php、java程序员,人力紧张时还要兼顾美工设计的工作。
工作中一次偶然的机会看到导师在黑压压的界面中敲入不同指令,第一感觉非常震撼,很COOL,联想到《黑客帝国》电影中的画面,与之前接触到的Windows系统完全不一样,后来才晓得是Redhat9(红帽9)。此时还是一名普通码农。
2005年的10月,进入第二个东家-天涯社区,人生的第一个转折点在此酝酿。
由于赶上了公司快速发展的阶段,接触到了很多开源技术,包括LVS、Squid、Haproxy、MongoDB、Mysql、Cfengine等等,也不断应用在生产环境,取得了非常不错的效果,重点业务的高可用持续保持在99.99%。

如何高效运营?
随之新的问题也陆续出现,包括如何更好整合各类开源组件,发挥其最大效能,另一个是如何高效运营。不可否认,具有开发背景的运维人员有着先天性的优势,可以在不同角色之间进行思考,视野被放大。
事实上在天涯6年就做一件事,即主导并实施天涯社区从Windows技术路线往开源架构改造,驱动这个事情有两原因,一个是运营管理成本、另一个是正版化给企业带来的高额成本(视窗+Sqlserver License)。
改造最大难点是没有可参考及借签的对象,文档资料不全。完全依靠原有人员的技术储备,不断摸索。经过“试错 -> 失败 -> 回滚 -> 再尝试”的过程,个人能力在此期间也得到了一次升华。
对Linux环境下的C++做了深入的研究学习,具备这样的知识对开源软件的架构、分层理解及故障定位有很大的帮助。改造后的天涯新架构在当时比较具有代表性且通用。

架构图如下:
点击在新窗口中浏览此图片

2010年天涯IT管理架构
点击在新窗口中浏览此图片

天涯期间的开源项目
点击在新窗口中浏览此图片
取之开源,同样也回馈开源,以下为个人在天涯期间的开源项目,其中开源后的“LVS管理平台”第一时间被国内某证卷公司采用,当时感觉很有成就感。
比较有意思的“服务器机柜模拟图平台”项目,不少公司在此基础上陆续出升级版本,平台截图如下:
点击在新窗口中浏览此图片
可以通过下面网址,访问在线版本
http://blog.liuts.com/idc/

后面也将内部的运维管理平台原型做了开源,同时也在《Python自动化运维实践》书籍中做了介绍,下面为OMServer平台截图
点击在新窗口中浏览此图片
源码托管在:
http://github.com/yorkoliu/pyauto

小经验:
05年开始写博客,当时目的比较单纯,即当笔记本来用,后来慢慢演变成交流沟通的平台,收到很多同行的评论、邮件,也认识了很多业界大牛,很多好友到现在还保持联系。

坚持写博客是一件非常困难的事。但在荣获了2010年度《十大杰出IT博客》的同时,也让我领悟到每写一篇博客其实就是个人对工作、生活的一次总结。不但可以锻炼你的语言组织、逻辑思维、表达等能力,还可以给你增加人气,提升个人影响力 ^_^。

腾讯CDN运维之旅
2011年加盟腾讯,主要负责了腾讯静态、下载类的CDN运维,截止当前已有400+加速节点(包括静态内容平台、游戏下载平台、UGC加速平台、流媒体平台、动态加速平台等),总带宽突破10Tb,覆盖了腾讯QQ、微信、QQ空间、腾讯视频等业务。
流量调度主要通过GSLB来实现,部分业务基于httpDNS来实现。
腾讯自建CDN除了强大的资源部署外,软实力方面做得非常不错,比如:协议栈优化TCP传输、DiskTank解决小文件读写瓶颈与碎片、链路实时调整等,其中链路实时调整依赖全网拓扑的实时测速的数据作为依据,调整事件是通过调用公司的GSLB接口进行刷新。

调度示意图如下:
点击在新窗口中浏览此图片

What happened?

运维期间碰到最头疼的问题还是小运营商的域名、内容劫持,表现形式为TTL、目标指向、内容劫持等几个方面。

Why?:运营这样做的初衷是什么?

减少运营商LDNS设备的性能负载;
减少运营商跨网结算成本;
嵌入捆绑广告营销策略等。
How?:解决的一些思路,发现问题:

主动:遍历域名在所有运营商LDNS的解析结果,与公司的威权GSLB记录做比较,存在异常的解析可以立马被定位;
被动:产品投拆、网友论坛反馈等渠道。目前还没有彻底解决问题的方案,原因是站在运营商的角度,适当的劫持是合理的,不过可以通过商务去推动解决(局部),关于内容劫持比较好的解决方案就是上HTTPS。

腾讯数据运营大舞台

2013 年至今负责腾讯游戏大数据运营体系的建设,支撑百余款游戏的数据接入、传输、ETL分析、大数据基础平台运维等工作,确保日7000亿条(50T)日志流水传输,以及日均10万次计算任务调度质量。
在IT基础服务方面,利用Docker技术及DevOps理念,对游戏数据应用实施持续交付流程、服务弹性调度的落地,以及开发团队与运维团队融合制度的定制。

数据运营简介

当前腾讯游戏数据传输、存储规模:
点击在新窗口中浏览此图片

游戏大数据服务架构图:
点击在新窗口中浏览此图片

其中存储与计算都采用公司级的数据服务平台-TDW(基于Hadoop+Hive构建),传输采用自研的TDBank平台,类似于开源Flume+Kafka的技术方案。
数据采集采用自研的Tglog方案,更轻量、传输效率更高,支持UDP及TCP版本,两个特点:
耦和度低、标准开放接口、接入成本低;
统一化数据运营标准协议XML、数据本地化容灾。
Tglog简介:

也简单介绍下Tglog日志格式的定义吧,分两部分,一为日志描述,二为实体日志。

下图为日志格式描述文件(XML格式):
点击在新窗口中浏览此图片

下图为采集原始日志格式(表名|字段值1|字段值2|… …):
点击在新窗口中浏览此图片

支撑数据应用-iData(腾讯智能化游戏数据分析平台),提供了游戏生命周期管理,且每个环节都结合了数据挖掘算法,做到精准玩家触达,精细化运营的目的。
点击在新窗口中浏览此图片

运维支撑难点:

如何保障海量游戏日志的采集、传输质量达到99.999% 的SLA标准?
需要从几个维度入手,包括元数据管理、数据地图、数据字典、血缘关系、数据对账、安全审计等。同时要确保与各类数据变更的强联动,感兴趣今后可以展开来讨论哈。
二级数据分析集群我们采用Flume+Spark,调度使用Mesos来实现,同时也结合kubernetes来实现长服务组件的调度,有兴趣今后可展开讨论。

我的DevOps观
Why DevOps?
DevOps是开发者和运维之间的高度协同与融合,这个过程贯穿整个软件开发生命周期,从业务规划到创建、交付再到反馈。
需要注意一点是,不仅仅包括是开发和运维团队,真正的 DevOps 方法需要业务部门、测试人员、企业高管、合作伙伴和供应商等配合完成。
主流观点
为什么要DevOps,国内认同度比较高的几个观点,更多可搜索老王分享过的一些文章。

改善团队协作;
帮助控管风险、成本、减少浪费;
提升软件品质;
提高软件迭代速度。
个人观点
个人更趋向于IBM的诠释,即增强客户体验、提高创新能力、更快实现价值。

建立一种机制,从所交付软件应用的所有利益相关方快速获取反馈,利益相关方包括客户、业务部门、用户、供应商、合作伙伴等等;
目标是减少浪费和返工,并将资源转移给价值更高的活动;
将软件快速、高效和可靠地交付于生产的文化、实践和自动化,快速达成目标,实现价值。
How?
怎么去做DevOps?
调整考核和激励机制;
绑定开发、测试、运维,共同输出价值;
全面自动化,减少人工干预;
开展培训和组织开发活动;
制定新体系结构标准。
持续集成、交付、部署是一个非常好的切入点,DevOps全景图:
点击在新窗口中浏览此图片
So What is it?
Devops就是:

CALMS - Culture(文化)
Automation(自动化)
Lean (Lean[精益]理论,其思想源于消除浪费)
Measurement(量化)包括监控、指标、分析
Sharing(分享)
补充概念
很多人会混淆持续交付(Continuous Delivery)、持续部署(Continuous Deployment)两个概念。
简单说明下,持续交付并不是指软件每一个改动都要尽快的部署到产品环境中,它指的是任何的修改都已证明可以在任何时候实施部署,而持续部署是将所有通过了自动化测试的改动都自动的部署到产品环境里。

DEVOPS最终目标及原则方向:

运维要成为一等公民;
让开发人员完成一切;
谁构建,谁运行。
经验点:

前期的沟通铺垫很重要,一定要了解公司内部利益相关方,包括开发负责人、运维主管、项目主管、产品负责人等的诉求及关注点,尽可能共同捆绑目标及输出价值,不同角色区别只在于分工。
其次是让大老板了解DevOps的收益,且要得到老板的支持,因为DevOps落地是一项长期工作,不可能在短期内看到收益。
量化的指标一定要清晰,且直观易懂,包括业务监控平台、分析报告,同时需要提供至少一种产品或用户反馈的途径,可以是产品官网、在线客服,这对提升平台的品质,直接影响产品口碑。这里直接使用了公司现有的非常完善的基础组件及渠道。
持续集成、交付、部署,我们使用了SVN+Jenkins+Docker+应用商店(镜像)。
第一期自动化部署我们采用了HECD架构实现,第二期计划是与蓝鲸平台打通,通过APP形式来实现从集成至部署的封环,很大程度提高了软件迭代的速度及频率,对提升软件品质及运维服务水平至关重要。
此项工作一定要做好,这也是让相关利益方切身感受变化的关键一环。

小知识
什么是HECD架构:构建一个高可用及自动发现的Docker基础架构-HECD
http://blog.liuts.com/post/242/

从业经验

最后再简单分享个人在运维领域从业的两个小经验:

1、一步一个脚印,切忌一步到位。
关于运维自动化这件事情,几乎所有的IT企业都在做,看似是一件非常好的事情,忽略了前提条件,往往付出更大的代价及运营成本。
之前所提到的前提条件便是运维体系“标准化”、“流程化”、“规范化”的建设,覆盖企业中资源、版本、业务发布、监控、事件管理等环节。有了这些作为基础铺垫,运维自动化的建设才会很顺利实施,达成预期。
自动化程度的高低很大程度是随公司所处不同发展阶段,不断去演变而来,不要想着去复制BAT的架构,一步到位是一个很大的误区。

2、运筹帷幄,主动耦合。
对业务的生命周期进行管理,是运维扮演的角色。
一个产品在规划之初运维人员须第一时间介入参与,根据产品特点,提供业务平台前期架构设计、资源评估等数据。
当产品进入开发阶段,须与开发人员保持密切沟通与互动,提供业务接入、缓存、存储、监控、安全等方面规范,以便在编码阶段更好磨合与对接,避免上线后反复做不必要的版本迭代,也使得开发出来的产品具备更高的可运维性。
待业务上线后,务必定期同步相关运营数据给产品与开发人员侧,为后续优化、改进的工作提供数据支持,这也恰恰能体现运维人员的专业性及团队合作意识。

一个感悟

运维体系中各个环节的工作犹如散落在地上的珠子,每个珠子分别代表事件、资源、监控、安全、自动化、日常工作等。
看似是七零八落的,我们需要利用“流程”这条线将所有的珠子串起来。珠子的前后顺序及间隔由“标准规范”来控制。
这样就形成了一条完整的链子,是一个有机的整体,最后会促使运维工作开展得井井有条。这条链子扣在三个点子上,就是“质量”、“效率”、“成本”。

如何保持竞争力?

很喜欢乔希·维茨金在《学习之道》书中一句名言:追求卓越的关键在于,要坚持充满活力,长期的学习过程,不再满足于原地踏步、平平庸庸。
作为一名优秀的运维工程师,应该将学习成果与日常工作相结合,独立及深入思考发现的问题,善于发现不同问题之间的联系,并把它们升华为方法论,最后再做总结与传承。
我的感悟:不断学习才是保持竞争力的唯一途径,不断思考和总结会成为你潜意识的行为;
我的行动:坚持每天1~2小时的学习时间,从未停止。

那么问题来了:
如学习的动力不源于兴趣或好奇心怎么办?
这里跟大家分享我与团队小伙伴探讨的一个观点:
首先应该静下心好好思考,自己5、10年后想过什么样的生活,可以预见的状态是上有老下有小、背着沉重的房贷、车贷。
如此时再去与一个毕业生竞争同一工作岗位,必然会丧失了所有的优势与竞争力,被行业所淘汰只是时间问题。
因此,想过衣食无忧生活,在职业发展过程中处于不败之地,那么,从现在开始就应该怀着空怀心态,不断打怪升级,使自己变得更加强大。
引用萧帮主一分享主题:“危机前的自我拯救”,没有这个勇气或行动是否考虑该转行了?

如何挖掘专利?

再聊聊运维人员如何写专利,在很多人眼里,写专利是一件非常复杂且很难做到的事情,甚至会认为这是开发人员更擅长的领域。
其实写专利并不像大家想象的那么遥远,只要是一个可以实现的方法或思路就能写成专利。比如运维平台当中的一个功能点、一个快速安全扫描的方法、一项容灾传输的技术、自动化测试案例思路、一种有效服务监控的手段等。这些点子都可以写成一个发明专利。
当然,创新及新颖性非常重要,可以先对比现有的技术实现,突出该发明的优势及亮点,就可以开始写交底书了。
如真的没有一点头绪,大家也可以参考个人写过的一些专利,访问中国专利局网,检索发明人:“刘天斯”
http://www.pss-system.gov.cn/sipopublicsearch/search/searchHome-searchIndex.shtml

一则小广告^_^:
点击在新窗口中浏览此图片
在个人著作《Python自动化运维:技术与最佳实践》中也分享一些运维自动化的实现方法与实践案例,供大家参考。
另一著作《Docker深入详解》预计8月上市,敬请关注!谢谢大家的聆听。

Q&A

Q1:自行研发tglog对于海量日志传输是否主要走的udp协议?如果是走的udp协议,怎么去解决一些数据包传输中数据乱序以及数据反序列化问题,或者做了哪些协议层面的优化?
A: 是的,主要走的是UDP协议。tglog同时也是一套数据日志的规范,约束开发人员打日志的标准。
目前未碰到数据乱序以及数据反序列化问题,以前面临一个比较大的问题是丢包情况,尤其在流量高峰期时段更为明显。
后面在内核、IO优化得到缓解,但无法规避,所以我们对比较重要的日志采用TCP传输。比如玩家消费流水。

Q2:规范化、标准化遇到最大问题是什么?我们遇到就是无法行政干涉开发如何写代码?有什么好的方式去引导规范?尤其是开发有很繁重的开发任务.
A: 这已经不是运维层面推动的事情,必须升级到运维及开发的上层领导,开发任务繁重不是理由,上线后出问题一样得不偿失,提前抛出风险,让开发人员认真做好上线前的评估。

Q3:Docker化应用,是否面临胖容器还是瘦容器问题,即每个容器单进程还是多进程,你们这块是如何使用的?
A: 这块没有统一的标准,看实际业务场景来决定,我们遵循一个原则是:最大化解耦。
另外一个需要考虑的点:是否为原子调度单元。
        在运营系统中经常用到异步方式来处理我们的任务,比如将业务上线流程串成任务再写入队列,通过后台作业节点去调度执行。比较典型的案例为腾讯的蓝鲸、织云、云智慧等平台。本译文结合Django+Celery+Redis实现一个定期从Flickr 获取图片并展示的简单案例,方便大家理解实现异步对列任务的过程。
        刚接触django的时候,我经历过的最让人沮丧的事情是需要定期运行一段代码。我写了一个需要每天上午12点执行一个动作的不错的函数。很简单是不是?错了。事实证明,这对我来说是一个巨大的困难点,因为,那时我使用Cpane类型的虚拟主机管理系统,它能专门提供一个很友好,很方便的图形用户界面来设置cron作业。
       经过反复研究,我发现了一个很好的解决方案 - Celery,一个用于在后台运行任务的强大的异步作业队列。但是,这也导致了其它的问题,因为我无法找到一系列简单的指令将celery集成到Django项目中。
       当然,我最终还是设法成功搞定了它 - 这正是本文将介绍的内容:如何将celery集成到一个Django项目,创建周期性任务。
       该项目利用Python3.4,Django的1.8.2,celery3.1.18和Redis3.0.2.

一、概述
       由于大篇幅的文字,为了您的方便,请参阅下表中的每一步的简要信息,并获取相关的代码。
步骤      概要           Git标签
样板      样板下载          V1
建立      集成Celery和Django      V2
Celery任务    添加基本的Celery任务    V3
周期性任务    添加周期性任务        V4
本地运行    本地运行我们的应用程序    V5
远程运行    远程运行我们的应用程序    V5

二、什么是Celery
       “Celery是一个异步任务队列/基于分布式消息传递的作业队列。它侧重于实时操作,但对调度的支持也很好。”本文,我们将重点讲解周期性执行任务的调度特点。
       为什么这一点有用呢?
      •回想一下你不得不在将来运行某一特定任务的经历。也许你需要每隔一小时访问一个API。或者,也许你需要在这一天结束时发送一批电子邮件。不论任务大小,Celery都可以使得调度周期性任务变的很容易。
      •你永远不希望终端用户等待那些不必要的页面加载或动作执行完成。如果你的应用程序工作流的一部分是一个需要很长时间的程序,当资源可用时,你就可以使用Celery在后台执行这段程序,从而使你的应用程序可以继续响应客户端的请求。这样可以使任务在应用程序的环境之外运行。

三、构建项目
       在深入了解Celery之前,先从Github库中获取开始项目。确保激活一个虚拟的环境,安装必要的软件,并运行迁移。然后启动服务器,通过你的浏览器导航到http://localhost:8000/。你应当能看到‘恭喜你的第一个Django页面’。完成后,关闭服务器。
       接下来,我们开始安装celery。

       现在,我们通过简单的三步将celery集成到django项目中。
步骤一:创建celery.py
在“picha“目录下,创建celery.py,代码如下:

       请注意代码中的注释。
步骤二:引入celery应用
为了确保在django启动时加载了celery应用,在settings.py旁边新建__init__.py,并添加以下代码到__init__.py中。

完成以上步骤后,你的项目目录应该是这样的:

步骤三:安装 Redis作为Celery的“中间件”
    Celery使用中间件在django项目与celery监控者之间传递消息。在本教程中,我们使用redis作为消息中间代理。
首先,从官方下载页面或通过brew(BREW安装Redis)安装Redis,然后打开你的终端上,在一个新的终端窗口,启动服务器:

你可以通过在终端中输入如下命令测试Redis是否正常工作。

       Redis应该回复PONG - 试试吧!
       一旦Redis正常启动了,把下面的代码添加到你的settings.py文件中:

       你还需要添加Redis的作为Django项目的依赖:

       就是这样了!你现在应该能够在Django中使用Celery。有关设置Celery与Django的更多信息,请查看官方Celery文档。
在继续下面步骤之前,让我们进行一些完整性检查,以确保一切都是正常的。
测试Celery worker已准备好接收任务:

       使用CTRL-C杀死该段程序。现在,测试Celery任务调度程序是否已经准备好:

       在上述完成时再次终止该进程。

1、Celery任务
       Celery利用celery调用的常规Python函数作为任务。
       例如,让我们把这个基本函数变为celery的任务:

       首先,添加一个装饰器。

       然后你可以通过以下方式利用celery异步运行该任务:

       很简单,对不对?
所以,这对于解决类似你要加载一个网页,而不需要用户等待一些后台程序的完成这些类型的任务来说是非常完美的。
      让我们来看一个例子...
让我们再回到Django项目的版本3,它包括一个接受来自用户的反馈的应用程序,人们形象地称之为反馈:

       安装新的必要软件,启动应用程序,并导航到http://localhost:8000/feedback/。你应该看到如下结果:
点击在新窗口中浏览此图片
让我们连接celery任务。

2、添加任务
       基本上,用户提交反馈表后,我们希望让他继续以他舒服的方式往下进行,而我们在后台进行处理反馈,发送电子邮件等等。
要做到这一点,首先添加一个叫tasks.py的文件到“feedback”目录:

       然后按照如下内容更新forms.py:

       大体上,send_feedback_email_task.delay(email, message)的函数过程,并发送反馈电子邮件等都是在用户继续使用该网站的同时作为后台进程运行。
注:在views.py中的success_url被设置为将用户重定向到/ 目录,这个目录还不存在。我们会在下一节设置这个终点启动。

3、周期任务
       通常情况下,你经常需要安排一个任务在特定的时间运行 - 例如,一个web scraper 可能需要每天都运行。这样的任务,被称为周期性任务,很容易建立利用celery启动。
       celery使用“celery beat”来安排定期任务。celery beat定期运行任务,然后由celery worker执行任务。
例如,下面的任务计划每15分钟运行一次:

       让我们通过往Django项目中添加功能来看一个更强大的例子。
回到Django项目版本4,它包括另一个新的应用程序,叫做photos,这个应用程序使用 Flickr API获取新照片用来显示在网站:

       安装新的必要软件,运行迁移,然后启动服务器,以确保一切都是好的。重新测试反馈表。这次,它应该重定向好了。
       下一步是什么?
       既然我们需要周期性的调用Flickr API,以获取更多的照片添加到我们的网站,我们可以添加一个celery任务。

4、添加任务
往photos应用中添加一个tasks.py。

       在这里,我们通过在一个task中包装这个函数,来实现每15分钟运行一次save_latest_flickr_image()函数。该@periodic_task装饰器抽象出代码来运行celery任务,使得tasks.py干净,易于阅读!

5、本地运行
       准备开始运行了?
       在Django应用程序和Redis运行的前提下,打开两个新的终端窗口/标签。在每一个新的窗口中,导航到你的项目目录,激活你的虚拟环境,然后运行下面的命令(每个窗口一个):

       当你访问http://127.0.0.1:8000/ 网址的时候,你现在应该能看到一个图片。我们的应用程序每15分钟从Flickr 获取一张图片。
点击在新窗口中浏览此图片
点击在新窗口中浏览此图片
通过photos/tasks.py查看代码。点击“Feedback”按钮发送一些反馈意见:
点击在新窗口中浏览此图片
点击在新窗口中浏览此图片
       以上是通过celery任务运行的。更多的请查看feedback/tasks.py
       就这样,你成功的启动并运行了 Picha项目!
       当你本地开发Django项目时,这是一个很好的测试,但是当你需要部署到生产环境- 就像 DigitalOcean时,就不那么合适了。为此,建议你通过使用Supervisor在后台作为一个守护进程运行celery worker和调度器。

6、远程运行
       安装很简单。从版本库中获取版本5(如果你还没有的话)。然后,SSH到远程服务器,并运行:

       然后,通过在远程服务器上“/etc/supervisor/conf.d/” 目录下添加配置文件来告知Supervisor celery的workers。在我们的例子中,我们需要两个这样的配置文件 - 一个用于Celery worker,一个是Celery scheduler。
在本地,在项目的根目录下创建一个“supervisor”的文件夹,然后添加下面的文件。
Celery Worker: picha_celery.conf

Celery Scheduler: picha_celerybeat.conf

       注:确保更新这些文件的路径,以匹配你的远程服务器的文件系统。
基本上,这些supervisor 配置文件告诉supervisord如何运行并管理我们的'programs'(因为它们是由supervisord调用)。
       在上面的例子中,我们已经创建了两个名为“pichacelery”和“pichacelerybeat”的supervisord程序。
现在,只需将这些文件拷贝到远程服务器的/etc/supervisor/conf.d/目录下。
       我们还需要在远程服务器上创建上面脚本中提到的日志文件:

       最后,运行以下命令,使 Supervisor 知道它所管理的程序的存在 - 例如,pichacelery和pichacelerybeat:

       运行以下命令停止,启动,和/或检查pichacelery程序的状态:

       你可以通过阅读官方文档获取Supervisor的更多信息。

7、最后提示
       1. 千万不要传递Django模型对象到celery任务。为了避免模型对象在传递给celery任务之前已经改变了,传递celery的主键给celery。然后,在运行之前使用主键从数据库中获取对象。
       2. 默认celery调度会在本地创建一些文件存储它的调度表。这些文件是“celerybeat-schedule.db”和“celerybeat.pid”。如果你在使用版本控制系统,比如Git(你应该使用!),请忽略这个文件,不要将它们添加到你的代码库中,因为它们是为本地运行的进程服务的。

8、下一步
       以上就是将celery集成到一个django项目的基本介绍。
想要更多?
1. 深入研究官方celery用户指南,以了解更多信息。
2. 创建一个Fabfile来设置Supervisor和配置文件。确保添加命令到reread和 update Supervisor。
3. 从repo中获取这个项目,并打开一个Pull 请求来添加一个新的celery任务。
编码快乐!

原文:https://realpython.com/blog/python/asynchronous-tasks-with-django-and-celery/

一、前言
        Kubernetes 是Google开源的容器集群管理系统,基于Docker构建一个容器的调度服务,提供资源调度、均衡容灾、服务注册、动态扩缩容等功能套件,目前最新版本为0.6.2。本文介绍如何基于Centos7.0构建Kubernetes平台,在正式介绍之前,大家有必要先理解Kubernetes几个核心概念及其承担的功能。以下为Kubernetes的架构设计图:
点击在新窗口中浏览此图片
1. Pods
        在Kubernetes系统中,调度的最小颗粒不是单纯的容器,而是抽象成一个Pod,Pod是一个可以被创建、销毁、调度、管理的最小的部署单元。比如一个或一组容器。
2. Replication Controllers
        Replication Controller是Kubernetes系统中最有用的功能,实现复制多个Pod副本,往往一个应用需要多个Pod来支撑,并且可以保证其复制的副本数,即使副本所调度分配的主宿机出现异常,通过Replication Controller可以保证在其它主宿机启用同等数量的Pod。Replication Controller可以通过repcon模板来创建多个Pod副本,同样也可以直接复制已存在Pod,需要通过Label selector来关联。
3、Services
        Services是Kubernetes最外围的单元,通过虚拟一个访问IP及服务端口,可以访问我们定义好的Pod资源,目前的版本是通过iptables的nat转发来实现,转发的目标端口为Kube_proxy生成的随机端口,目前只提供GOOGLE云上的访问调度,如GCE。如果与我们自建的平台进行整合?请关注下篇《kubernetes与HECD架构的整合》文章。
4、Labels
        Labels是用于区分Pod、Service、Replication Controller的key/value键值对,仅使用在Pod、Service、 Replication Controller之间的关系识别,但对这些单元本身进行操作时得使用name标签。
5、Proxy
        Proxy不但解决了同一主宿机相同服务端口冲突的问题,还提供了Service转发服务端口对外提供服务的能力,Proxy后端使用了随机、轮循负载均衡算法。

        说说个人一点看法,目前Kubernetes 保持一周一小版本、一个月一大版本的节奏,迭代速度极快,同时也带来了不同版本操作方法的差异,另外官网文档更新速度相对滞后及欠缺,给初学者带来一定挑战。在上游接入层官方侧重点还放在GCE(Google Compute Engine)的对接优化,针对个人私有云还未推出一套可行的接入解决方案。在v0.5版本中才引用service代理转发的机制,且是通过iptables来实现,在高并发下性能令人担忧。但作者依然看好Kubernetes未来的发展,至少目前还未看到另外一个成体系、具备良好生态圈的平台,相信在V1.0时就会具备生产环境的服务支撑能力。

一、环境部署
1、平台版本说明
    1)Centos7.0 OS
    2)Kubernetes V0.6.2
    3)etcd version 0.4.6
    4)Docker version 1.3.2

2、平台环境说明
点击在新窗口中浏览此图片

3、环境安装
    1)系统初始化工作(所有主机)
    系统安装-选择[最小化安装]
    
引用

    # yum -y install wget ntpdate bind-utils
    # wget http://mirror.centos.org/centos/7/extras/x86_64/Packages/epel-release-7-2.noarch.rpm
    # yum update
    

    CentOS 7.0默认使用的是firewall作为防火墙,这里改为iptables防火墙(熟悉度更高,非必须)。
    1.1、关闭firewall:
    
引用

    # systemctl stop firewalld.service #停止firewall
    # systemctl disable firewalld.service #禁止firewall开机启动
    

    1.2、安装iptables防火墙
    
引用

    # yum install iptables-services #安装
    # systemctl start iptables.service #最后重启防火墙使配置生效
    # systemctl enable iptables.service #设置防火墙开机启动
    

    2)安装Etcd(192.168.1.10主机)
    
引用

    # mkdir -p /home/install && cd /home/install  
    # 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/  
    # /bin/etcd -version  
    etcd version 0.4.6  
    

    启动服务etcd服务,如有提供第三方管理需求,另需在启动参数中添加“-cors='*'”参数。
    
引用

    # mkdir /data/etcd  
    # /bin/etcd -name etcdserver -peer-addr 192.168.1.10:7001 -addr 192.168.1.10:4001 -data-dir /data/etcd -peer-bind-addr 0.0.0.0:7001 -bind-addr 0.0.0.0:4001 &
    

    配置etcd服务防火墙,其中4001为服务端口,7001为集群数据交互端口。
  
引用

    # iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 4001 -j ACCEPT
    # iptables -I INPUT -s 192.168.1.0/24 -p tcp --dport 7001 -j ACCEPT
  


    3)安装Kubernetes(涉及所有Master、Minion主机)
    通过yum源方式安装,默认将安装etcd, docker, and cadvisor相关包。
    
引用

    # curl https://copr.fedoraproject.org/coprs/eparis/kubernetes-epel-7/repo/epel-7/eparis-kubernetes-epel-7-epel-7.repo -o /etc/yum.repos.d/eparis-kubernetes-epel-7-epel-7.repo
    #yum -y install kubernetes
    

    升级至v0.6.2,覆盖bin文件即可,方法如下:
    
引用

    # mkdir -p /home/install && cd /home/install
    # wget https://github.com/GoogleCloudPlatform/kubernetes/releases/download/v0.6.2/kubernetes.tar.gz
    # tar -zxvf kubernetes.tar.gz
    # tar -zxvf kubernetes/server/kubernetes-server-linux-amd64.tar.gz
    # cp kubernetes/server/bin/kube* /usr/bin
    

    校验安装结果,出版以下信息说明安装正常。
    
引用

    [root@SN2014-12-200 bin]# /usr/bin/kubectl version
    Client Version: version.Info{Major:"0", Minor:"6+", GitVersion:"v0.6.2", GitCommit:"729fde276613eedcd99ecf5b93f095b8deb64eb4", GitTreeState:"clean"}
    Server Version: &version.Info{Major:"0", Minor:"6+", GitVersion:"v0.6.2", GitCommit:"729fde276613eedcd99ecf5b93f095b8deb64eb4", GitTreeState:"clean"}
    

    4)Kubernetes配置(仅Master主机)
    master运行三个组件,包括apiserver、scheduler、controller-manager,相关配置项也只涉及这三块。
4.1、【/etc/kubernetes/config】

4.2、【/etc/kubernetes/apiserver】

4.3、【/etc/kubernetes/controller-manager】

4.4、【/etc/kubernetes/scheduler】

    启动master侧相关服务
    
引用

    # systemctl daemon-reload
    # systemctl start kube-apiserver.service kube-controller-manager.service kube-scheduler.service
    # systemctl enable kube-apiserver.service kube-controller-manager.service kube-scheduler.service
    

    5)Kubernetes配置(仅minion主机)
        minion运行两个组件,包括kubelet、proxy,相关配置项也只涉及这两块。
    Docker启动脚本更新
    # vi /etc/sysconfig/docker
    添加:-H tcp://0.0.0.0:2375,最终配置如下,以便以后提供远程API维护。
    OPTIONS=--selinux-enabled -H tcp://0.0.0.0:2375 -H fd://

    修改minion防火墙配置,通常master找不到minion主机多半是由于端口没有连通。
    iptables -I INPUT -s 192.168.1.200 -p tcp --dport 10250 -j ACCEPT

    修改kubernetes minion端配置,以192.168.1.201主机为例,其它minion主机同理。
5.1、【/etc/kubernetes/config】

5.2、【/etc/kubernetes/kubelet】

5.3、【/etc/kubernetes/proxy】

启动kubernetes服务
    
引用

# systemctl daemon-reload
# systemctl enable docker.service kubelet.service kube-proxy.service
# systemctl start docker.service kubelet.service kube-proxy.service
    

3、校验安装(在master主机操作,或可访问master主机8080端口的client api主机)
  1) kubernetes常用命令
    
引用

# kubectl get minions    #查查看minion主机
# kubectl get pods    #查看pods清单
# kubectl get services 或 kubectl get services -o json    #查看service清单
# kubectl get replicationControllers    #查看replicationControllers清单
# for i in `kubectl get pod|tail -n +2|awk '{print $1}'`; do kubectl delete pod $i; done    #删除所有pods
    

    或者通过Server api for REST方式(推荐,及时性更高):
    
引用

# curl -s -L http://192.168.1.200:8080/api/v1beta1/version | python -mjson.tool    #查看kubernetes版本
# curl -s -L http://192.168.1.200:8080/api/v1beta1/pods | python -mjson.tool    #查看pods清单
# curl -s -L http://192.168.1.200:8080/api/v1beta1/replicationControllers | python -mjson.tool    #查看replicationControllers清单
# curl -s -L http://192.168.1.200:8080/api/v1beta1/minions | python -m json.tool    #查查看minion主机
# curl -s -L http://192.168.1.200:8080/api/v1beta1/services | python -m json.tool    #查看service清单
    

注:在新版kubernetes中,所有的操作命令都整合至kubectl,包括kubecfg、kubectl.sh、kubecfg.sh等

  2)创建测试pod单元
   # /home/kubermange/pods && cd /home/kubermange/pods
   # vi apache-pod.json

    # kubectl create -f apache-pod.json
    # kubectl get pod
引用

NAME                IMAGE(S)            HOST                LABELS              STATUS
fedoraapache        fedora/apache       192.168.1.202/      name=fedoraapache   Running

    启动浏览器访问http://192.168.1.202:8080/,对应的服务端口切记在iptables中已添加。效果图如下:
点击在新窗口中浏览此图片
    观察kubernetes在etcd中的数据存储结构
点击在新窗口中浏览此图片

    观察单个pods的数据存储结构,以json的格式存储。
点击在新窗口中浏览此图片

二、实战操作
    任务:通过Kubernetes创建一个LNMP架构的服务集群,以及观察其负载均衡,涉及镜像“yorko/webserver”已经push至registry.hub.docker.com,大家可以通过“docker pull yorko/webserver”下载。
    
引用

    # mkdir -p /home/kubermange/replication && mkdir -p /home/kubermange/service
    # cd /home/kubermange/replication
    

1、 创建一个replication ,本例直接在replication模板中创建pod并复制,也可独立创建pod再通过replication来复制。
【replication/lnmp-replication.json】

    执行创建命令
    #kubectl create -f lnmp-replication.json
    观察生成的pod副本清单:
[root@SN2014-12-200 replication]# kubectl get pod
引用

NAME                                   IMAGE(S)            HOST                LABELS               STATUS
84150ab7-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.202/      name=webserver_pod   Running
84154ed5-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.201/      name=webserver_pod   Running
840beb1b-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.202/      name=webserver_pod   Running
84152d93-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.202/      name=webserver_pod   Running
840db120-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.201/      name=webserver_pod   Running
8413b4f3-89f8-11e4-970d-000c292f1620   yorko/webserver     192.168.1.201/      name=webserver_pod   Running

2、创建一个service,通过selector指定 "name": "webserver_pod"与pods关联。
【service/lnmp-service.json】

    执行创建命令:
    # kubectl create -f lnmp-service.json

    登录minion主机(192.168.1.201),查询主宿机生成的iptables转发规则(最后一行)
    # iptables -nvL -t nat
引用

Chain KUBE-PROXY (2 references)
pkts bytes target     prot opt in     out     source               destination        
    2   120 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.254.102.162       /* kubernetes */ tcp dpt:443 redir ports 47700
    1    60 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.254.28.74         /* kubernetes-ro */ tcp dpt:80 redir ports 60099
    0     0 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.254.216.51        /* webserver */ tcp dpt:8080 redir ports 40689

    访问测试,http://192.168.1.201:40689/info.php,刷新浏览器发现proxy后端的变化,默认为随机轮循算法。
点击在新窗口中浏览此图片
点击在新窗口中浏览此图片

三、测试过程
    1、pods自动复制、销毁测试,观察kubernetes自动保持副本数(6份)
删除replicationcontrollers中一个副本fedoraapache
[root@SN2014-12-200 pods]# kubectl delete pods fedoraapache
I1219 23:59:39.305730    9516 restclient.go:133] Waiting for completion of operation 142530
fedoraapache
引用

[root@SN2014-12-200 pods]# kubectl get pods
NAME                                   IMAGE(S)            HOST                LABELS              STATUS
5d70892e-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.201/      name=fedoraapache   Running
5d715e56-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running
5d717f8d-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running
5d71c584-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.201/      name=fedoraapache   Running
5d71a494-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running

#自动生成出一个副本,保持6份的效果
引用

[root@SN2014-12-200 pods]# kubectl get pods
NAME                                   IMAGE(S)            HOST                LABELS              STATUS
5d717f8d-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running
5d71c584-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.201/      name=fedoraapache   Running
5d71a494-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running
2a8fb993-8798-11e4-970d-000c292f1620   fedora/apache       192.168.1.201/      name=fedoraapache   Running
5d70892e-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.201/      name=fedoraapache   Running
5d715e56-8794-11e4-970d-000c292f1620   fedora/apache       192.168.1.202/      name=fedoraapache   Running

2、测试不同角色模块中的hostPort
    1)pod中hostPort为空,而replicationcontrollers为指定端口,则异常;两侧都指定端口,相同或不同时都异常;pod的hostport为指定,另replicationcon为空,则正常;pod的hostport为空,另replicationcon为空,则正常;结论是在replicationcontrollers场景不能指定hostport,否则异常,待持续测试。
    2)结论:在replicationcontronllers.json中,"replicaSelector": {"name": "webserver_pod"}要与"labels": {"name": "webserver_pod"}以及service中的"selector": {"name": "webserver_pod"}保持一致;

请关注下篇《kubernetes与HECD架构的整合》,近期推出。

参考文献:
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/fedora/fedora_manual_config.md
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/DESIGN.md
http://www.infoq.com/cn/articles/Kubernetes-system-architecture-introduction

转载请注明来源 http://blog.liuts.com/post/247/

        主控端是OMServer的核心角色,负责接收加密的协议串且进行解密,解析成OMServer调用的任务模块,同时结合角色中的saltstack、ansible或func组件,向目标业务服务器集群(被控机)发送执行任务,执行完毕后,将返回的执行结果加解密处理,最后逐级返回给系统管理员,角色所在位置见以下架构图:
点击在新窗口中浏览此图片
一、环境部署
1、部署saltstack、ansible或func组件,详细见本书相关章节,此处省略;

2、安装rpyc模块

3、下载主控端源码
#cd /home
download github地址:https://github.com/yorkoliu/pyauto/tree/master/第十三章/OMServer

修改OMServer/config.py主配置文件

4、编写任务模块
    1)在WEB前端点击【添加模块】,指定模块名称、描述、参数接口信息,提交后记录生成的模块ID(数字);
    2)在主控端OMServer/modules目录存放了各个组件的模块,以不同目录名作为区分,任务模块名称由“Mid_”+模块ID组成,与前端生成的模块ID进行关联,如Mid_1007.py,可参考现有示例进行修改。

5、启动服务


二、校验环境
        最后,打开浏览器访问http://omserver.domain.com(自定义域名,可通过修改hosts实现),效果图如下。
点击在新窗口中浏览此图片

三、基于Python构建可扩展的自动化运维平台(WOT分享主题)

       《python自动化运维:技术与最佳实践》书籍发布已经1个月有余,根据读者反馈,在部署OMServer平台时遇到很多困难及问题,尤其是第一次部署Django环境的读者。因此,作者对书籍中OMServer环境部署章节的内容进行扩充,以便让每位读者都可以轻易完成平台搭建。OMServer平台涉及两个角色,其中一个为Web服务端,运行在Django及rpyc环境,另一角色为主控端,需要部署saltstack、ansible或func主控端环境,本文介绍Web服务端的部署详细步骤。

---环境版本说明---
* Python  版本  2.6.6
* Django  版本   1.4.9
* nginx  版本  1.5.9
* pcre  版本  8.34
* rpyc  版本  3.2.3
* uwsgi  版本  2.0.4
* django-debug-toolbar  版本  0.8.5

一、Django环境部署

1、安装pcre,pcre是一个轻量级的正则表达式函数库,Nginx的HTTP Rewrite模块会用到,最新版本为8.34(对于OMServer平台环境来说是非必选项)。

2、安装Nginx,Nginx是最流行的高性能HTTP服务器,最新版本为1.5.9。

3、安装 MySQL-python,MySQL-python是Python访问MySQL数据库的第三方模块库,最新版本为1.2.3c1。

4、rpyc模块安装,用于平台与主控端做数据通讯交互。

5、安装uwsgi。uwsgi是一个快速的、纯C语言开发的、自维护、对开发者友好的WSGI服务器,旨在提供专业的Python web应用发布和开发,最新版本为2.0.4。

出现如下代码成功安装:
################# uWSGI configuration #################
pcre = True
kernel = Linux
malloc = libc
execinfo = False
ifaddrs = True
ssl = True
zlib = True
locking = pthread_mutex
plugin_dir = .
timer = timerfd
yaml = embedded
json = False
filemonitor = inotify
routing = True
debug = False
capabilities = False
xml = False
event = epoll
############## end of uWSGI configuration #############
total build time: 17 seconds
*** uWSGI is ready, launch it with ./uwsgi ***

6、安装Django,Django是一个Python最流行的开源Web开发框架,最新版本为1.6.5。考虑到兼容与稳定性,本案例使用1.4.9版本进行开发。

创建一个demo项目,以便验证环境是否正确安装部署。

7、django-debug-toolbar的安装(Django调试利器)

8、配置Nginx,修改/usr/local/nginx/conf/nginx.conf,最终完整配置如下:

* uwsgi_param UWSGI_SCRIPT wsgi;参数值wsgi对应项目目录中的wsgi.py,此处文件前缀与参数值要保持一致。

9、配置uwsgi,创建uwsgi配置文件/usr/local/nginx/conf/uwsgi.ini,详细内容如下:

---关键参数及说明---
1)chdir 指定项目目录;
2)pythonpath 指定项目目录上一级
3)processes 指定进程数
4)workers 分配CPU的核数
5)limit-as 子进程分配的内存大小
6)max-requests 分配最大的请求数

    启动uwsgi与nginx服务,建议配置成服务自启动脚本,便于后续的日常维护。详细启动脚本这里不展开说明,有兴趣的读者可参阅互联网上已经存在的相关资源。
    最后启动uwsgi与nginx服务

        访问http://demo.domain.com,出现如图所示的页面说明Django+uwsgi环境部署成功!
点击在新窗口中浏览此图片

二、OMServer项目部署
1、修改Nginx配置
添加OMServer项目站点配置,[server]域具体内容如下:


  1)切记修改UWSGI_SCRIPT为django_wsgi;
  2)监听uwsgi端口修改成127.0.0.1:9001;    #多个站点使用不同端口区分


2、添加omserver项目uwsgi配置

3、项目源码配置
  1)项目源码:
    # cd /data/www
    下载地址:https://github.com/yorkoliu/pyauto/tree/master/第十三章/OMserverweb
  2)导入数据库结构(Mysql)
    下载地址:https://github.com/yorkoliu/pyauto/blob/master/第十三章/SQL/OMServer.sql
  3)修改setting.py(数据库信息)

   4)修改主控端rpyc主机IP
    OMserverweb/autoadmin/views.py
    
启动项目uwsgi及Nginx服务

4、访问http://omserver.domain.com,出现以下系统界面说明部署成功!
点击在新窗口中浏览此图片

下一步配置《python自动化运维:技术与最佳实践》之OMServer平台环境部署详解【主控制端】

补:平台涉及开源组件包下载:
Django-1.4.9.tar.gz 下载
uwsgi-2.0.4.tar.gz 下载
rpyc-3.2.3.tar.gz 下载
pcre-8.34.tar.gz 下载
nginx-1.5.9.tar.gz 下载
MySQL-python-1.2.5.zip 下载
django-debug-toolbar-master.tar.gz 下载
【当当】 http://product.dangdang.com/23593858.html
【京东】 http://item.jd.com/11571426.html
【亚马逊】 http://www.amazon.cn/%E5%9B%BE%E4%B9%A6/dp/B00P5VKZWW
【天猫】 http://detail.tmall.com/item.htm?spm=a1z10.3.w4011-7555161747.28.SgDdii&id=42141530490&rn=3a7da8b28eea552fb6ebb6ed43ab024d&abbucket=18
【China-pub】 http://product.china-pub.com/3804188

《python自动化运维:技术与最佳实践》附带示例及案例源码
【国内镜像】(JD云汇)https://code.jd.com/yorkoliu/pyauto
【国外镜像】(Github)https://github.com/yorkoliu/pyauto
【源码打包下载】(zip)http://share.weiyun.com/9e4bfc70a9af8840927b92910ab80d8b

点击在新窗口中浏览此图片
一、内容简介
        本书在中国运维领域将有“划时代”的重要意义:一方面,这是国内第一本从纵、深和实践角度探讨Python在运维领域应用的著作;一方面本书的作者是中国运维领域的“偶像级”人物,本书是他在天涯社区和腾讯近10年工作经验的结晶。因为作者实战经验丰富,所以能高屋建瓴、直指痛处,围绕Python自动化运维这个主题,不仅详细介绍了系统基础信息、服务监控、数据报表、系统安全等基础模块,而且深入讲解了自动化操作、系统管理、配置管理、集群管理及大数据应用等高级功能。最重要的是,完整重现了4个来自实际生产环境的不同功能运维平台的综合案例,展示了完整的平台架构及开发流程。
        全书一共16章:基础篇(1-4章)详细介绍了系统基础信息、业务服务监控、定制业务质量报表、系统安全等基础和常用模块;高级篇(5-12章)深入讲解了批量运维管理器pexpect、paramiko、Fabric,集中化管理平台Ansible、Saltstack,统一网络控制器Func等高级功能,涵盖自动化操作、系统管理、配置管理、集群管理及大数据应用等主题;案例篇(13-16章)详细介绍了4个来自不同平台的运维案例,如何从零开始打造一个B/S自动化运维平台、如何打造Linux系统安全审计功能、如何构建分布式质量监控平台、如何构建桌面版C/S自动化运维平台,这4个案例均来自实际生产环境。

二、目录
前  言
第一部分 基础篇
第1章 系统基础信息模块详解 2
1.1 系统性能信息模块psutil 2
1.1.1 获取系统性能信息 3
1.1.2 系统进程管理方法 6
1.2 实用的IP地址处理模块IPy 7
1.2.1 IP地址、网段的基本处理 8
1.2.2 多网络计算方法详解 9
1.3 DNS处理模块dnspython 11
1.3.1 模块域名解析方法详解 11
1.3.2 常见解析类型示例说明 12
1.3.3 实践:DNS域名轮循业务监控 14
第2章 业务服务监控详解 17
2.1 文件内容差异对比方法 17
2.1.1 示例1:两个字符串的差异对比 17
2.1.2 生成美观的对比HTML格式文档 19
2.1.3 示例2:对比Nginx配置文件差异 19
2.2 文件与目录差异对比方法 21
2.2.1 模块常用方法说明 21
2.2.2 实践:校验源与备份目录差异 25
2.3 发送电子邮件模块smtplib 27
2.3.1 smtplib模块的常用类与方法 27
2.3.2 定制个性化的邮件格式方法 28
2.3.3 定制常用邮件格式示例详解 29
2.4 探测Web服务质量方法 34
2.4.1 模块常用方法说明 35
2.4.2 实践:实现探测Web服务质量 36
第3章 定制业务质量报表详解 39
3.1 数据报表之Excel操作模块 39
3.1.1 模块常用方法说明 41
3.1.2 实践:定制自动化业务流量报表周报 48
3.2 Python与rrdtool的结合模块 50
3.2.1 rrdtool模块常用方法说明 51
3.2.2 实践:实现网卡流量图表绘制 53
3.3 生成动态路由轨迹图 56
3.3.1 模块常用方法说明 56
3.3.2 实践:实现TCP探测目标服务路由轨迹 57
第4章 Python与系统安全 60
4.1 构建集中式的病毒扫描机制 60
4.1.1 模块常用方法说明 61
4.1.2 实践:实现集中式的病毒扫描 61
4.2 实现高效的端口扫描器 64
4.2.1 模块常用方法说明 64
4.2.2 实践:实现高效的端口扫描 66
第二部分 高级篇
第5章 系统批量运维管理器pexpect详解 70
5.1 pexpect的安装 70
5.2 pexpect的核心组件 71
5.2.1 spawn类 71
5.2.2 run函数 74
5.2.3 pxssh类 75
5.3 pexpect应用示例 76
5.3.1 实现一个自动化FTP操作 76
5.3.2 远程文件自动打包并下载 77
第6章 系统批量运维管理器paramiko详解 79
6.1 paramiko的安装 79
6.2 paramiko的核心组件 81
6.2.1 SSHClient类 81
6.2.2 SFTPClient类 82
6.3 paramiko应用示例 85
6.3.1 实现密钥方式登录远程主机 85
6.3.2 实现堡垒机模式下的远程命令执行 85
6.3.3 实现堡垒机模式下的远程文件上传 88
第7章 系统批量运维管理器Fabric详解 91
7.1 Fabric的安装 91
7.2 fab的常用参数 92
7.3 fabfile的编写 93
7.3.1 全局属性设定 93
7.3.2 常用API 94
7.3.3 示例1:查看本地与远程主机信息 95
7.3.4 示例2:动态获取远程目录列表 96
7.3.5 示例3:网关模式文件上传与执行 97
7.4 Fabric应用示例 98
7.4.1 示例1:文件打包、上传与校验 98
7.4.2 示例2:部署LNMP业务服务环境 99
7.4.3 示例3:生产环境代码包发布管理 101
第8章 从“零”开发一个轻量级WebServer 104
8.1 Yorserver介绍 104
8.1.1 功能特点 104
8.1.2 配置文件 105
8.2 功能实现方法 106
8.2.1 HTTP缓存功能 107
8.2.2 HTTP压缩功能 111
8.2.3 HTTP SSL功能 111
8.2.4 目录列表功能 114
8.2.5 动态CGI功能 114
第9章 集中化管理平台Ansible详解 118
9.1 YAML语言 119
9.1.1 块序列描述 120
9.1.2 块映射描述 120
9.2 Ansible的安装 121
9.2.1 业务环境说明 121
9.2.2 安装EPEL 122
9.2.3 安装Ansible 122
9.2.4 Ansible配置及测试 122
9.2.5 配置Linux主机SSH无密码访问 123
9.3 定义主机与组规则 124
9.3.1 定义主机与组 124
9.3.2 定义主机变量 125
9.3.3 定义组变量 125
9.3.4 分离主机与组特定数据 126
9.4 匹配目标 127
9.5 Ansible常用模块及API 127
9.6 playbook介绍 132
9.6.1 定义主机与用户 132
9.6.2 任务列表 133
9.6.3 执行playbook 134
9.7 playbook角色与包含声明 135
9.7.1 包含文件,鼓励复用 135
9.7.2 角色 136
9.8 获取远程主机系统信息:Facts 141
9.9 变量 142
9.9.1 Jinja2过滤器 143
9.9.2 本地Facts 143
9.9.3 注册变量 144
9.10 条件语句 145
9.11 循环 146
9.12 示例讲解 147
第10章 集中化管理平台Saltstack详解 155
10.1 Saltstack的安装 156
10.1.1 业务环境说明 156
10.1.2 安装EPEL 156
10.1.3 安装Saltstack 156
10.1.4 Saltstack防火墙配置 157
10.1.5 更新Saltstack配置及安装校验 157
10.2 利用Saltstack远程执行命令 158
10.3 Saltstack常用模块及API 161
10.4 grains组件 166
10.4.1 grains常用操作命令 167
10.4.2 定义grains数据 167
10.5 pillar组件 170
10.5.1 pillar的定义 171
10.5.2 pillar的使用 173
10.6 state介绍 174
10.6.1 state的定义 174
10.6.2 state的使用 175
10.7 示例:基于Saltstack实现的配置集中化管理 177
10.7.1 环境说明 177
10.7.2 主控端配置说明 177
10.7.3 配置pillar 179
10.7.4 配置state 180
10.7.5 校验结果 183
第11章 统一网络控制器Func详解 185
11.1 Func的安装 186
11.1.1 业务环境说明 186
11.1.2 安装Func 186
11.2 Func常用模块及API 189
11.2.1 选择目标主机 190
11.2.2 常用模块详解 190
11.3 自定义Func模块 194
11.4 非Python API接口支持 198
11.5 Func的Facts支持 199
第12章 Python大数据应用详解 202
12.1 环境说明 202
12.2 Hadoop部署 203
12.3 使用Python编写MapReduce 207
12.3.1 用原生Python编写MapReduce详解 208
12.3.2 用Mrjob框架编写MapReduce详解 212
12.4 实战分析 216
12.4.1 示例场景 216
12.4.2 网站访问流量统计 217
12.4.3 网站HTTP状态码统计 219
12.4.4 网站分钟级请求数统计 220
12.4.5 网站访问来源IP统计 221
12.4.6 网站文件访问统计 222
第三部分 案例篇
第13章 从零开始打造B/S自动化运维平台 226
13.1 平台功能介绍 226
13.2 系统构架设计 227
13.3 数据库结构设计 228
13.3.1 数据库分析 228
13.3.2 数据字典 228
13.3.3 数据库模型 229
13.4 系统环境部署 230
13.4.1 系统环境说明 230
13.4.2 系统平台搭建 230
13.4.3 开发环境优化 233
13.5 系统功能模块设计 235
13.5.1 前端数据加载模块 235
13.5.2 数据传输模块设计 237
13.5.3 平台功能模块扩展 240
第14章 打造Linux系统安全审计功能 245
14.1 平台功能介绍 245
14.2 系统构架设计 246
14.3 数据库结构设计 247
14.3.1 数据库分析 247
14.3.2 数据字典 247
14.4 系统环境部署 248
14.4.1 系统环境说明 248
14.4.2 上报主机配置 248
14.5 服务器端功能设计 252
14.5.1 Django配置 252
14.5.2 功能实现方法 253
第15章 构建分布式质量监控平台 256
15.1 平台功能介绍 256
15.2 系统构架设计 257
15.3 数据库结构设计 258
15.3.1 数据库分析 258
15.3.2 数据字典 258
15.3.3 数据库模型 259
15.4 系统环境部署 260
15.4.1 系统环境说明 260
15.4.2 数据采集角色 260
15.4.3 rrdtool作业 261
15.5 服务器端功能设计 263
15.5.1 Django配置 263
15.5.2 业务增加功能 264
15.5.3 业务报表功能 266
第16章 构建桌面版C/S自动化运维平台 269
16.1 平台功能介绍 269
16.2 系统构架设计 270
16.3 数据库结构设计 271
16.3.1 数据库分析 271
16.3.2 数据字典 272
16.3.3 数据库模型 272
16.4 系统环境部署 273
16.4.1 系统环境说明 273
16.4.2 系统环境搭建 273
16.5 系统功能模块设计 274
16.5.1 用户登录模块 274
16.5.2 系统配置功能 275
16.5.3 服务器分类模块 277
16.5.4 系统升级功能 280
16.5.5 客户端模块编写 284
16.5.6 执行功能模块 287
16.5.7 平台程序发布 289

三、书摘与插画
点击在新窗口中浏览此图片

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

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

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

       2014年11月21日至22日,51CTO传媒主办的2014WOT全球软件技术峰会·深圳站将在深圳召开,技术人员和企业实践用户将齐聚深圳。WOT是由51CTO传媒主办的国内最具有影响的技术峰会,自2012年以来,秉承专注技术、服务技术人员的理念,获得了广大IT从业者和技术爱好者的一致认可,成为了业界重要的技术分享交流平台以及人脉拓展平台。
    本次2014 WOT·深圳站将邀请国内外顶级的互联网及创新企业技术负责人,首次对外公开其当下最in技术,分享涵盖六大主题,共有30+课程,移动游戏运营、运维开发、Web安全、数据挖掘、团队管理等以及未来两三年的技术趋势。点击报名>>

本次采访对象是本次2014WOT深圳站<自动化运维>论坛的演讲人刘天斯,目前为腾讯的高级运维工程师

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

1、您目前在贵公司负责哪些事情?能否先简单谈谈您在运维领域的从业经验,和您对此运维的理解?

        从事运维方面的工作刚满10年,前6年负责天涯社区的系统架构及运维的工作,2011年入职腾讯,先后负责静态类、大游戏下载业务的CDN运营,以及负责公司所有游戏的大数据接入、分析、提取等工作。

        简单分享个人在运维领域从业的两个经验:

        1)关于运维自动化这件事情,几乎所有的IT企业都在做,看似是一件非常好的事情,忽略了前提条件,往往付出更大的代价及运营成本。所提到的前提条件便是运维体系“标准化”、“流程化”、“规范化”的建设,覆盖企业中资源、版本、业务发布、监控、事件管理等环节。有了这些作为基础铺垫,运维自动化的建设才会很顺利实施,达成预期。

        2)业务的生命周期管理,运维扮演的角色。当一个产品在规划之初运维人员须第一时间介入参与,根据产品特点,提供业务平台前期架构设计、资源评估等数据。当产品进入开发阶段,须与开发人员保持密切沟通与互动,提供业务接入、缓存、存储、监控、安全等方面规范,以便在编码阶段更好磨合与对接,避免上线后反复做不必要的版本迭代,也使得开发出来的产品具备更高的可运维性。待业务上线后,务必定期同步相关运营数据给产品与开发人员侧,为后续优化、改进的工作提供数据支持,这也恰恰能体现运维人员的专业性及团队合作意识。

        运维体系中各个环节的工作犹如散落在地上的珠子,每个珠子分别代表事件、资源、监控、安全、自动化、日常工作等,看似是七零八落的,我们需要利用“流程”这条线将所有的珠子串起来,珠子的前后顺序及间隔由“标准规范”来控制。这样就形成了一条完整的链子,是一个有机的整体,最后会促使运维工作开展得井井有条。这条链子扣在三个点子上,就是“质量”、“效率”、“成本”。

2、能否讲讲这么多年运维工作的变化与演进?

云计算给IT行业带来的巨大冲击,从最初的不信任逐渐到认可,到最后各类云计算应用的落地普及。当然,这也给运维人员带来非常大的挑战,尤其承担企业私有云的建设,运维人员除了具备传统运维的能力外,还需要深入理解业务资源使用的特点,例如区分是计算性、内存型、IO型还是存储型,同时需要对资源进行合理的规划及定义扩容规则。私有云作为资源的一个大池子,如何保持其弹性,需要具备一套精准的监控手段,配合自动化运维工具来保障,包括自动化安装部署、配置管理、存储管理、故障处理、备份容灾等。实现业务快速上线,资源快速扩容,同时具备高可用的能力。在这种大背景下,运维人员除了会用“云”,且要求用好“云”,才能给企业带来价值。另外基于容器实现的虚拟化(Docker)已经兴起,将给业务的打包、部署、迁移、测试等都会带来革命性的变革,运维准备好了吗?

3、随着如今大数据的爆发,这给运维工作带来了怎样的冲击与改变?

大数据在企业做精细运营方面发挥了巨大的作用,作为底层服务支撑的运维,需要掌握大数据生态圈中关键技术点,包括Hadoop、hive、hbase、spark、storm等平台的日常运营,需要解决包括资源调度、数据接入、快速扩容、节点故障处理、高可用、数据存储生命周期管理等问题,这给运维人员提出了更高的要求,同时也给运维工作带来了新的机遇,一典型案例是将所有告警接入storm实时计算分析,过滤出有效告警,同时将信息入库Hadoop,以便做历史档的离线分析,让运维人员更懂业务。

4、贵公司在监控上用了哪些技术?使用开源的还是自主研发?

公司内部使用了自研方式实现监控体系的构建,局部会使用开源工具作为补充。

5、您认为目前国内的自动化平台以及数据可视化平台建设如何?还需要加强哪方面发展?

        自动化运维是每个企业都在追求的终极目标,做到一键触发业务上线、故障自愈、资源自动调度、高质量数据报表及业务智能分析等,既然是目标,说明大部分都还在路上,即使国内一线的互联网企业也未能达到该理想的状态。自动化之路是一个复杂的系统工程,是一个长期积累、沉淀且不断优化的过程。由于互联网行业的特殊性,包括新技术不断涌入及快速迭代,另一方面是互联网业务日新月异,各种颠覆性的产品层出不穷。作为服务支撑,这也给自动化运维带来变数及挑战。

        在国内需要加强的部分还是资源与技术的共享,很多时候大家都在同一件事情,贡献一个成熟且通用的组件对业界的影响是深远的,阿里在这方面做得就非常好。在个人著作《Python自动化运维:技术与最佳实践》中也分享一些实现方法与实践案例,可作参考。

6、您认为一名合格的运维工程师是如何定义的?需要具备哪些因素?

        我认为一名合格的运维工程师需要具备高度的责任心,有一定的沟通及协调能力,同时需要具备发现问题及解决问题的能力,平时要多思考,多总结,多输出,以便将现有的沉淀更好传承下去,即使人员变动也不会出现断层。另外对资源、质量要非常敏感,有一定的规划及ITIL能力。对运营的业务要做到全面性的了解,包括提供的服务、总体架构、技术实现原理以及存在的问题等。在技能方面需要熟悉主流的运维相关技术,包括网络、设备、操作系统、负载均衡、缓存、数据库、云计算技术等方面,并关注最新技术发展动向,评估并思考如何运用到实际工作当中,解决工作中碰到的问题。同时,需要具有很好的开发能力,理由是没有人比我们更清楚我们需要什么的平台或工具,在与产品或开发沟通时,才有更多的发言权,甚至是主导权。

原文:【2014WOT深圳站讲师专访】刘天斯:Docker的到来,运维准备好了么?
Tags: , , ,
分页: 1/30 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]