容器运维不再重造轮子:企业级容器平台VIC

刀客info阅读(1309)评论(0)

2016VMworld大会发布更完整的企业级容器平台VIC,包括新增的Harbor Registry和管理平台Admiral。本文和大家分享一些技术细节。另,Harbor项目在北京招募开发和测试工程师,有兴趣的朋友按文后方式联系。

今年的VMWorld大会从旧金山移师赌城拉斯维加斯举行。和旧金山相比,拉斯维加斯这座沙漠之城少了些科技的氛围,不过在一片休闲娱乐气氛中召开用户大会,令人十分放松,本次参会人数达到创记录的23000人。

20160912093649

VMWorld大会现场

 

在第二天的主题演讲上,核心平台部门的CTO Kit Colbert介绍了VMware云原生的技术新进展,在去年vSphere Integrated Containers(VIC)的基础上,增加了企业级容器Registry和容器应用管理门户,使得企业级容器平台更加完整,整个平台计划于年底正式发布。VIC由三个开源项目组成,分别是容器引擎VIC-engine,容器镜像仓库 Harbor registry 和容器管理门户 Admiral 。其中,VIC 的 Registry 用的是由我们中国团队研发的开源项目Harbor,已经被广大中国用户所熟悉。VIC项目的地址为:

https://github.com/vmware/vic-product

20160912093658

Kit Colbert演示VIC中的Harbor Registry

 

容器是对开发者非常友好一种技术,比虚拟机更轻量更灵活,把应用封装在容器之中,就可无差别地部署运行。因此,以Docker为代表容器技术自推出之后,在开发者中迅速流行起来。

另一方面,当我们把容器部署在生产系统上运行时,却发现依然需要解决一系列基础设施的问题,如存储、网络等资源怎样提供给应用?高可用性怎样实现?数据怎样持久化?这些问题在虚拟化时代都已经很好地解决过了,这回换上了更“先进”的容器,运维人员却失望地发现必须再次解决这些问题,犹如踏破铁鞋,又回到了原点,要辛辛苦苦地重造轮子。这就是容器应用目前的尴尬!容器的落地问题,关键在于解决各种生产系统中部署(day 1)和运维(day 2)问题。

20160912093706

容器开发环境与生产环境的差别

VIC优势之一,就是帮助企业在生产环境中运行容器应用,利用已有工具,无差别地同时运行容器和虚拟机应用。用户可通过 Docker run 等命令,直接在vSphere创建容器虚拟机(containerVM),同时,传统的虚拟机应用可在同一个平台上运行。这样做的好处,是把原有的高可用性(HA)、动态负载均衡(DRS),资源监控等功能完全重用,像 VSAN 和 NSX 这样的软件定义存储( SDS )和网络(SDN)的基础设施也可供容器直接使用。VIC真正把开发人员喜爱的Docker API和运维人员熟悉的vSphere管理工具完美地集成起来,成为开发运维一体化平台。

20160912093714

容器应用与网络、存储等基础设施完美融合

 

在VIC的三大组件中,有关VIC容器引擎的原理已经给读者介绍过多次,提供在vSphere平台上直接运行Docker镜像的容器运行时(runtime),无需从Linux宿主机上通过Docker engine来执行。vSphere管理员可创建虚拟容器主机VCH(Virtual Container Host)分配给不同的人员使用。每个VCH包含若干台ESX主机组成的集群,在集群中提供一个支持Docker API的接入节点(Endpoint VM),Docker run命令可直接发向这个接入节点,从而启动容器虚拟机(Container VM)。VIC更详细的架构,可参考《企业容器和虚拟机融合技术》。

20160912093723

VIC的架构

 

大部分企业运行容器应用都需要配备私有的镜像仓库,VIC内置了大家熟知的Harbor Registry,可使用存放在Harbor之中的镜像,方便了使用。Harbor提供的RBAC镜像权限管理,使得镜像的访问更加安全可控。Harbor还提供远程镜像同步功能,实现多数据中心、跨云的镜像同步。参见《玩转容器镜像-镜像仓库的管理和运维》。

20160912093733

笔者在VMworld分会场介绍Harbor

 

VIC还新增了容器管理门户Admiral(海军上将),通过可视化界面定义容器应用的模板,可定制单个或多个容器的应用,最终可把模板中的应用部署到VIC的容器引擎中。 Admiral还可获得容器的运行的各种信息。Admiral也被集成到了vRA(vRealize Automation)的管理平台中,可提供容器即服务(Container as a Service)的能力,将于年底发布该容器管理功能。

20160912093742

VIC的容器管理界面

 

VIC的三个组件都是开源项目,可在Github上获得统一的入口地址并下载试用:

https://github.com/vmware/vic-product

你以为是微服务或Docker?其实是组织架构!

刀客info阅读(1145)评论(0)

今日洞见

文章作者、图片来自ThoughtWorks:肖然。部分图片来自网络。本文版权属ThoughtWorks公司所有,如需转载请加其官方微信在后台留言联系。

It’s Microservices …It’s docker …It’s organization structure

微服务和容器毫无争议的成为了这个时代的主旋律,大家争先恐后地让自己的团队和企业去尝试这样的旋律,但往往发现曲高和寡,难以在整个组织内形成共鸣。

在本文中,我们尝试揭开微服务和容器技术背后映射出的组织结构的变迁,以及组织结构对落地微服务和容器化架构所带来的反向制约,最后用INVEST原则来看看支撑这样松耦合架构的组织结构应有的特质。希望能够帮助迷茫中的企业和组织重新思考自己的微服务之路。

Microservices(微服务)和docker(容器)成了近一年来软件行业的新宠,每次参加相关活动总会感到康威老先生站在背后邪邪地笑着:“我早告诉你们了”。

尽管Martin Fowler在“定义”微服务时十分小心的警告了大家所要付出的代价,但好像微服务的优点太过于吸引人,以至于大部分软件开发组织和企业都把微服务这种架构方式作为了未来的必选,大家都觉得我就是那个高个子(I’m that tall!)。

20160908210937

 

Martin Fowler对伴随微服务架构的高工程实践能力的比喻

随着容器技术到达生产应用的临界点,这种化学效应好像一触即发,我们仿佛看到了未来一个不一样的软件微服务大集市在逐步展开!

在这个集市里会有淘宝这样的平台,为中小服务卖家搭起一个在线商城,买家可以根据自己的需要搜索及购买琳琅满目、各式各样的服务,在线或是二进制、代码质量及自动化覆盖率等指标成为同类服务评级的重要标准。

杀手级的服务如区块链或者量子加密可能成为皇冠销量服务。最后掀起一大波程序猿开微服务店的热潮~ 很期待那是怎样的卖家秀和买家秀啊!

这种几乎接近于科幻的描述可能只适合作为微信上的谈资,但微服务和容器技术的流行却并非偶然。康威老先生用自己的定律揭示了一个更深刻的道理:

这不是一次技术架构或者基础设施的革命,而是为了保持组织灵活性的必由之路。

换句话说,软件开发组织或企业开始意识到一切的管理和技术实践都必须为保持尽可能高的组织灵活性服务。一定会有人问为啥要保持“尽可能高”的灵活性呢?铁打的营盘流水的兵、稳定的规章制度不也缔造出了历史上那么多成功的组织和企业吗?

论尽可能高的组织灵活性

所以我在前面加了定语“软件开发”,当然现在我们有一个更广泛的提法:科技企业。通常我们认为产品或服务的技术含量比较高,具有核心竞争力,能不断推出适销对路的新产品,不断开拓市场的企业为科技企业。

在我们所处的软件时代,大量的科技企业都跟软件沾上了边。但历史上我们可以回想大生产时代炼钢也曾是高科技,信息时代发邮件也是高科技。

前两波的“科技企业”给我们的印象可不是灵活的:几大钢铁巨擘让人联想到的应该是当年国家呼唤生产力全民建设的宏伟场景;信息时代佼佼者如Microsoft和IBM让人联想到的应该是动辄千人的大型工业软件开发队伍,一个部署都得来一个专家队伍。

那么为啥现在咱们的科技企业必须灵活,而且必须尽可能高呢?

这里我们再次使用康威老先生的定律来做推论,康威定律说:

“一个产品或系统的设计(架构)受到其生产组织自身交流沟通结构的制约”,

换句话说如果你有一个前端展现团队、一个后端服务团队和一个数据库团队,那么我们可以肯定,搞出来的系统会分前后台和数据库的设计。这本身是一个悲观的定律,所以前面的团队发现新需求来了必须沟通三次,前后台团队关心新需求对自身架构的影响,数据库设计关心对现有数据结构的冲击,最后总是会在各方的争执中得到一个别扭的解决方案。

很多团队早已经习惯了这样的痛苦,数字化时代的变化频率将这样的痛苦逐渐推向了顶峰。举例感受一下:达到100亿产值,首钢用了71年,联想用了13年,这个时代的小米用了仅仅3年!而今年的小米已经不是站在浪潮之巅的科技新贵了。

如果要保持产品的持续竞争力,就要保持组织的灵活性。——康威

曾经有人跟我争辩说:“我们做的是数字化时代的后台系统,不直接面对市场,需求很稳定,搞那么灵活成本反而高。”于是我指着他们有着千万行代码的系统说:“你们至少有30%代码是冗余的,这就是组织缺乏灵活性的另外一个恶果。”

20160908210955

这里我们先收缩范围到软件开发,非常有意思的是在咱们这个行业里,针对同一份需求,没有两个开发人员实现出来的代码是一样的(也许Hello World例外)。甚至,当我发现两个程序员使用的变量命名一样的时候我会怀疑他们抄袭了。这说明软件开发从需求提出到写代码实际都是在做设计,不同的人设计出来的东西就会不同,像大家的签名一样。

设计甚至延续到了后面的软件测试和部署,同样的应用在不同的网络拓扑结构下表现可能是完全不一样的。那些追求稳定的组织希望尽早结束设计这个高度不确定性的活动,从而能够通过标准化来提高效率。

即使在敏捷开发主流化的今天,很多团队仍然是架构师“画图”,码农堆砌代码。所以这样的组织很快发现自己深陷二进制的泥潭,进退维谷。我经常跟这样的团队讲:你们缺乏“代码的响应力”。而响应力对组织的要求就是灵活,能够从前到后驾驭设计活动带来的不确定性。

小结一下:数字化时代的市场变化是迅猛的,康威老先生已经告诉我们,处在这样时代背景下的科技企业保持组织灵活性是十分重要的。而软件(广义讲新科技领域)本身由于强设计而带来的不确定性又加重了对组织灵活性的诉求。

于是在这个时代我们看到了如Google、海尔这样已然成功的企业开始大刀阔斧地改革自己的组织结构,这种对灵活性的极致追求成就了这些组织持续保持市场领先水平的核心竞争力。毫无疑问,微服务架构的优点也正反向映射出了组织结构的灵活性,而容器技术的运用降低了这种松散集市结构的运营成本,就如同淘宝平台的出现给千千万卖家和买家搭建了一个基础的交易平台。

弹性伸缩的容器化计算资源加上松耦合的微服务架构必然会吸引追求组织灵活性的企业去打败康威定律,保持组织活力。

组织结构的INVEST原则

前面咱们辩证了数字化时代科技企业保持组织灵活性的必要,那么灵活的组织结构应该满足什么原则呢?

下面我们就借用敏捷开发中赫赫有名的需求管理原则INVEST来剖析一下怎样的组织结构才能够真正落地微服务架构和容器技术带来的灵活性优势,或者从另外一个角度看支撑微服务架构的运用。

20160908211003

两种组织结构对比示意

独立的:Independent

按照微服务架构的团队应该对外提供一种或多种服务,服务和服务之间应该是松耦合的,所以背后的团队也应该是相对独立的。遵循康威定律,如果一个大型组织没有能够划分出服务导向的相对独立团队,那么最后对外提供的产品或系统的内部结构也不可能是简单的服务组装,而会是我们常说的“意大利面”,内部结构纠缠不清以至于最后响应市场新需求越来越慢。

便于沟通的:Negotiable

“小”服务团队的结构必然造成整个组织的集市化、社区化。如果没有建立良好的团队间的沟通机制,很难想象这样的组织里会有任何的产出。Amazon被认为是一个微服务架构运用的成功典范,其2pizza团队的原则成为了业内的标杆。

但这样服务导向小团队集合的底层是长期磨合形成的良好团队间沟通机制,甚至当我们问到Amazon各个团队如何发现其它服务或要求其它团队协助完成需求时,团队都说不出具体的流程机制,一切都变得很自然,全然像我们走进自己熟悉的超市一样,能够很自然的找到日常所需。

有价值的:Valuable

毫无疑问,每个团队必然是面向价值交付的。敏捷开发方法的提出其实很早就指出了传统方式下按照功能部门划分的瀑布交付模式的原罪,即每个功能部门都不对最终的价值交付负责(Output over Outcome,输出大于结果)。这样的组织结构必然造成对市场变化响应的滞后。

值得一提的是面向价值交付的团队往往也是跨职能的,按照微服务的架构,团队需要负责服务从需求到部署运营的全生命周期(Outcome over Output,结果大于输出)。这也是为什么在基础的工程交付平台及实践上团队必须是一个“高个子”。

可估计的:Estimable

这样的服务团队交付周期应该是很短且可以准确估计的,上线应该是家常便饭,而不是过去短则数月、长则一年的大爆炸模式。持续交付在这样的组织里应该是标准实践,让软件系统时刻处于可发布状态是团队的共同责任。从Amazon和Netfliex这样的现代科技企业身上我们已经看到了这样组织结构下逐步形成的工程能力优势,并最终转换成了业务服务上的巨大成功。

 短小:Small

前面提到了Amazon的2pizza团队,人数10人以内,经典的敏捷管理框架Scrum也建议5~9人的团队,可见小团队成为组织灵活性的一个必要条件。中国俗语有“船小好调头”朴实地揭示了小的灵活性,但为什么不再小一点呢?比如两个人结对一个团队。

显然大家很容易发现软件开发本身的复杂性决定了要端到端交付价值两个人的团队是搞不定的。从整个组织的健壮性来讲,过小的团队也会增加企业形成单点依赖的风险。虽然没有正式确认,但我们交流中发现Amazon这样的微服务组织里其实也是存在服务冗余的,这样的重复保证了组织在切割成小团队后风险得到适当的规避。

可测试的:Testable

在面对市场情况高度不确定性时,我们应该直面试错这件事情。传统职能型的大组织结构往往是不能容错的,错误的代价就是整个企业走偏了方向,或者一个部门在企业里失去了话语权。

在灵活性高的组织里我们却应该是能够很容易进行这样的“测试”,企业更能够利用这样的结构进行动态的投资组合管理,像Google著名的7:2:1投资比例,最后的一成就是利用组织的灵活性进行创新的测试。测试的结果往往是失败的,但正是这样的不断测试创造了Google历史上很多著名的“黑天鹅”。

 

打破康威定律

最近很多以精益(LEAN)为关键字的理论框架在咱们这个领域冒了出来,也包括我前期撰文提到的精益企业(Lean Enterprise),于是有朋友揶揄说又开始炒概念了。我却很严肃地澄清正是不希望炒概念,所以才回到了上个世纪就论证和发展起来的理念:精益。

20160908211016

来源于丰田制造的精益总结出了很多的原则和实践,但有意无意中丰田完成了自身组织持续灵活性打造这项超越同期其它企业的伟业。其结果就是在响应需求多样化时展现出的更强适应能力。

如果用我们前面的INVEST原则来看待精益组织,你会很快找到对应的原则和实践,即使在传统的工业流水线上,丰田也在形成一个个的小团队(cell,单元生产),也在通过员工的多技能培养来完成小团队内部的“跨职能”。其持续改进(Kaizen)的核心思想有力保证了团队面向价值的工作方式和良好的跨团队沟通文化。

某种意义上讲精益在康威定律定义之前就打破了康威定律!

微服务和容器技术无疑是这个时代工程架构方面支撑组织灵活性的重要一步,然而我们不能忘记一个组织是五脏俱全的,如精益企业提到的,组织的财务审计、人力资源、采购合规等功能如何有效的“微服务”化和如何能够合力构建一个弹性的“容器”支撑平台仍然需要诸君努力!

Docker容器生态之争中的炮灰(上)

刀客info阅读(1356)评论(0)

话说天下大势,分久必合,合久必分。周末七国分争,并入于秦。及秦灭之后,楚、汉分争,又并入于汉。汉朝自高祖斩白蛇而起义,一统天下,后来光武中兴,传至献帝,遂分为三国。

上了度娘引经据典展示了本人渊博的学识之后,再次回归挨踢狗的正身…

Docker容器生态之争中的“三国”就目前来看分为互联网大佬Google领衔的Kubernetes,Apache开源基金会扶持的Mesos和Docker超新星原生的Swarm。

作为一名初入Docker容器界还不到三年的菜鸟,想要入门这些闻所未闻的高大上技术的第一步总是盲目的。我想很多人或曾经或现在的跟我一样,到底哪个最牛逼?到底学哪个才好?

随后查资料,听分享,群交流,问大拿…斩获无数有价值的信息,但由于这些信息都太有价值,结果还是不知道到底哪个好。特别是在没有实际项目驱动的自学情景下,我活像个国内外各大容器云提供商布道过程中的一枚炮灰…哦,不对,是一粒炮灰。

时间慢慢过,彷徨失措的内心总有沉寂下来明确方向的一天。以下是我个人的一些想法,希望能够有人入坑:

Kubernetes的狂拽炫酷屌炸天我并不知道,因为到现在也没有初步学习过,但是有Google这个名头,那就一定会是狂拽炫酷屌炸天。但是,个人感觉上手太难,试问我在连docker run后面的参数都没全弄明白的情况下,如何再去接触一个跟docker命令或者配置有着一定差异的Kubernetes?所以,学肯定要学,但现在还不是时候。

Mesos的定位大而全——DCOS,由于本人资质愚钝,到现在也不知道DCOS到底是个啥。但是想想,我想要学习的是容器编排的工具,DCOS的定位会不会太大?万一哪天人家重心不放在容器编排了,那该怎么办?而且还有个什么马拉松的要去接触。全马得42.195公里…光想想都觉得难,不适合我这种懒人,果断放弃。

Swarm,最终只剩下这位兄弟了。但是作为一名对技术宁缺毋滥的节操搬砖人员,如果是个烂玩意宁可不学也罢。接触之后发现Swarm还比较简单且容易上手,功能也不赖,跟Docker Engine本身的一些命令或调用也比较容易过渡。关键是,Swarm是Docker亲儿子啊!于是,就决定先从Swarm开始着手了,毕竟Docker这一波浪潮,还是得跟上去的。

磕磕绊绊,当搭建了第一个swarm+etcd集群时的心情是鸡冻的,以致于一条命令在两台Docker宿主机(虚拟机)上面跑了20多个RancherVM管理的容器虚拟机。是的,你没看错,就是虚拟机里面跑容器,然后到跑的容器里面再跑虚拟机那种方式。

结果可想而知,因为多重嵌套的I/O问题导致Docker Engine在多个VM同时有读写操作的时候直接挂掉,那可是万能的重启大法都不管用的挂掉啊!不过这并没有什么关系,这并非是Swarm的问题,而是我这颗猪脑子的问题。挖坑把自己埋了之后,更加坚定了跟Swarm一起走下去的决心。

这一走就不得了,前好长一段时间出现了一篇Swarm性能秒杀Kubernetes的评测文章。当时的我是鸡冻的,看来机制的我并没有选错,连老大哥的编排工具都被“干”了。但是在现在看来,这篇文章估计也是生态之争到达一个阶段的产物…

随后发现Docker的野心之大,大到不可想象。要开源我的东西没有问题,要统一游戏规则我也没话说,但是我要牢牢把握住生态。所以Docker在前段时间推出了Swarm Kit,并将这个玩意儿集成到了Docker Engine 1.12之中。这一集成可不得了,原生内置支持编排,无需外界任何辅助,集群模式开箱即用,看样子Docker这是准备Carry全场的节奏?

识时务者为俊杰,于是小炮灰又开始了Swarm Mode的学习…恰逢久仰的Shit叔叔在Pycon2016上偷学到了在Swarm Mode集群环境部署运维Docker币的全套功法,随之便糖衣炮弹好酒好肉招待,诚心邀请在本人的订阅号发几篇高质量的Docker Swarm Mode集群实战文章,也好为自己寒酸的订阅号攒攒人气。

到这里,一切都是那么的美好,直到…

数人云发布国内首个基于SwarmKit的容器管理面板Crane

刀客info阅读(1446)

9月6日,数人云发布基于Docker SwarmKit的容器管理面板Crane。该工具是国内首个基于最新Docker SwarmKit套件的容器管理工具,采用轻量化架构,具有Docker原生编排功能,可以帮助开发者快速搭建DevOps环境,快速体验Docker的各项最新功能。只需一条命令,几分钟即可完成安装。

数人云容器管理面板Crane具有应用治理、镜像管控、集群运维,以及镜像仓库认证管理四大功能,可管理大规模集群,实现应用的弹性扩缩。插件化架构设计使其具有 Docker 灵活的插拔存储与网络驱动,可按需启停用户管理。

数人云CTO肖德时指出,“Docker公司推出了SwarmKit套件,把Swarm的精华注入到Docker中,使开发者可以非常方便地获取集群能力。数人云为了帮助广大技术爱好者对Docker新版本有快速直观的感受,制作了一款基于最新Swarm特性的容器管理工具,使有一定容器开发经验的开发者在第一时间体验Docker的新特性。数人云Crane在开发者和数人云之间建立了一条新的纽带,将集结越来越多的技术爱好者把Docker这项技术更好地发展应用下去。”

 易用稳定 覆盖不同用户群体

数人云容器管理面板Crane结合Docker 最新的集群功能,对应用、服务、任务与容器间的逻辑关系进行了全新阐述。通过一个DAB文件,即可驱动整个应用的跨主机编排,并保证应用内服务的自动发现;同时,该工具实现JSON文件、向导表单、应用目录、命令行工具多种应用下发模式,可满足中高级不同用户群体的需求,只需输入两个关键字就可下发一个应用。

数人云容器管理面板Crane可以在固定时间内并行更新任务数,避免更新峰值影响集群吞吐。该工具提供服务 Docker 镜像更新的Webhook,可与上游镜像构建对接,触发镜像更新回调。运行中的服务可以随时进行扩容缩容,用户可以按照业务需要增减任务个数,并为每个任务设置CPU内存的资源跨度,保证全局的资源隔离。

用户不仅可以配置任务的失败重启策略来达到服务容错,还可以设置任务的重启间隔,固定时间窗口内的重启次数,避免异常任务频繁调度消耗集群资源,进而保证集群的整体稳定性。集群中的每个节点都可以分摊流量、引导至服务的每个任务,这不仅提高了服务的可用性和吞吐量,更消除了负载均衡单点。落地过程中,用户可以使用前置的 F5 硬负载对接部分甚至整个后端集群的主机。

数人云容器管理面板Crane提供多种分发模式,固定任务数与一主机一任务模式,结合长时任务批处理任务,定时任务可实现多种任务分发组合满足不同应用场景。

 同时提供私有镜像和公有镜像功能

数人云容器管理面板Crane的应用目录可以帮助用户打造企业内部的镜像市场,可一键下发公共应用,提高运维效率。该工具提供了私有镜像功能和公有镜像功能:私有镜像实现了用户管理与镜像管控的闭环,通过对接企业内部用户系统,用户可以使用内部账号/密码无缝推送镜像到私有镜像仓库,拉取亦然。而公有镜像则结合用户管理功能,用户可以将自己的镜像公开给他人使用,实现组内资源共享。

 集群运维 一键实现任务调度

数人云容器管理面板Crane可以查看集群内各主机的配置、状态,可随时快速添加主机,一键将某主机上的任务调度至其它机器以停止维护该主机。该工具还可以为主机打标签来配合任务调度,或者依此划分生产、测试环境。

数人云容器管理面板Crane内置Overlay网络,实现应用网络隔离和独立的网络规划能力,用户也可以通过 Docker网络插件功能无缝对接多种Overlay网络方案。

此外,该工具还提供容器的实时监控,帮助用户从全局和底层单元多角度监控主机和服务的运行状况,实时日志功能实现了容器级别的服务级别实时日志收集。

 镜像仓库认证管理

通过数人云容器管理面板Crane镜像仓库认证管理,用户可以管理自己多个镜像仓库的认证信息,在发布应用时,利用认证信息拉取相应仓库的镜像到集群中进行部署。

数人云容器管理面板Crane是基于SwarmKit技术的最新工具,目前已登录数人云官网,欢迎申请试用体验版。

 

关于数人云

数人云创始团队来自谷歌、红帽和惠普,在今年3月初公司完成A轮融资,由云启资本领投,思科、策源以及唯猎跟投。作为领先的云计算创新技术实践者,数人云致力于为客户提供领先的企业级容器解决方案,帮助传统企业实现IT业务转型,更好地应对业务变化。数人云重点聚焦于打造轻量级PaaS平台,使用户能够在云主机、虚拟机甚至物理机上快速建立并稳定运行一个高扩展性的生产环境,将应用弹性做到极致。数人云操作系统基于领先的容器技术,实现了一站式的微服务架构集群系统,最大化地帮助客户实现应用业务在云端的快速部署,解决应用上云的最后一公里。

微服务访问安全设计方案全探索

刀客info阅读(2528)

今天给大家带来的是数人云工程师文权在高效运维线上群的分享实录。从传统单体应用架构到微服务架构,安全问题一直是人们关注的重点,文权与大家分享了关于微服务访问安全设计方案的探索与实践。

文权

数人云资深售前工程师

我们首先从传统单体应用架构下的访问安全设计说起,然后分析现代微服务架构下,访问安全涉及的原则,接着讨论目前常用的几种微服务架构下的访问安全设计方案。最后,详析Spring Cloud微服务架构下如何解决访问安全的问题。

一、传统单体应用的访问安全设计

20160831203434

上面的示意图展示了单体应用的访问逻辑。用户通过客户端发出http或者https请求,经过负载均衡后,单体应用收到请求。接着经过auth层,进行身份验证和权限批准,这里,一般会有跟后端数据库的交互。通过后,将请求分发到对应的功能逻辑层中去。完成相关操作后,返回结果给客户端。

传统单体应用的访问安全设计——原则

20160831203442

从以上分析可以看到,传统单体应用的访问安全设计原则为:

第一,每次的用户请求都需要验证是否安全,这里可以分两种情况:

一种是没有session的请求,需要经过几个步骤完成session化。一般为验证当前用户的credential,获取当前用户的identity,这两步都需要访问数据库等持久化对象来完成,最后一步是为当前可用创建session,返回给客户端后,启用该session。

另一种是有session的请求,只需验证请求中当前session的有效性,即可继续请求。

第二,用户的操作请求都在后端单个进程中执行完成,完全依赖后端调用方法的可靠性。一旦出错,应用是无法再次重复请求。

传统单体应用的访问安全设计——优势和注意点

20160831203449

小结,传统单体应用由于设计相对简单单一,暴露给外界的入口相对较少,从而具有被攻击并造成危害性的可能小的优势。

也正是由于单体应用简单单一的特点,需要注意相关问题:

  1. 应用后端保存了所有的credential等敏感信息
  2.   一旦入侵了对这个应用的请求,就有可能拿到所有的保存在后端的信息
  3.  应用的每次操作一般都需要和数据库进行交互,造成数据库负载变高

二、微服务架构下,访问安全设计原则

20160831203455

先来看下这张典型的微服务设计架构图,如图所示,有以下几点特征:

  1. 每个服务只有权限去操作自己负责的那部分功能。
  2.  用户请求的身份验证和权限批准都由独立的gateway服务来保障
  3.  对外服务的LB层无法直接与提供业务服务的应用层进行访问

20160831203504

从上面的特征分析来看,想要给出一份访问安全设计的原则说明,就要看看微服务架构下,访问安全有哪些痛点,以下罗列了几点:

  1. 单点登录,即在微服务这种多独立服务的架构下,实现用户只需要登录一次就能访问所有相互信任的应用系统
  2. 微服务架构下的应用一般都是无状态的,导致用户的请求每次都需要鉴权,可能引发Auth服务的性能瓶颈
  3. 微服务架构下,每个组件都管理着各自的功能权限,这种细粒度的鉴权机制需要事先良好的规划
  4. 微服务架构下,需要考虑到那些非浏览器端的客户请求,是否具有良好的可操作性

根据实际情况,还有一些其他痛点,这里不再一一赘述,而这些痛点,就形成了我们在为微服务架构设计访问安全的原则。

三、微服务架构下,常用的访问安全设计方案

  1. HTTP Basic Authentication + Independent Auth DB
  2. HTTP Basic Authentication + Central Auth DB
  3.  API Tokens
  4. SAML

这里列出4种,首先简单介绍下,然后一一叙述。

第一种,使用HTTP Basic Auth协议,加上独立的Auth数据库。

第二种,也是使用HTTP Basic Auth协议,跟第一种不同的是,使用集中式的Auth数据库

第三种,API Tokens协议,这种大家应该比较熟悉,很多公有服务(比如Github、Twitter等)的API都是用这种方式。

第四种,SAML,即Security Assertion Markup Language,翻译过来,是『安全声明标记语言』,它是基于XML的一种协议,企业内使用得较多。

下面一一做介绍。

微服务常用访问安全设计方案——Basic Auth + Independent Auth DB

20160831203512

第一种,如上示意图所示,使用Basic Auth协议,配合每个服务自己都拥有存储Credential敏感数据的数据库(或者其他持久化仓库)。

简单介绍下Basic Auth协议,它是在用户的请求中添加一个Authorization消息头,这个消息头的值是一个固定格式:

Basic base64encode(username+“:”+password)

完整的消息头列子为:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Basic Auth协议基本上被所有流行的网页浏览器都支持。

这种方案的特点:

  •  每个提供功能的服务都拥有自己独立的鉴权和授权机制
  • 每个提供功能的服务都拥有自己独立的数据库,来保存敏感信息
  • 每次用户请求都需要携带用户的credential来完成操作

小结下使用这种方案的好处:

  1. 微服务的应用可以实现100%无状态化
  2. 基于Basic Auth开发简单

同时,小结下使用这种方案需要注意的地方:

  1. 由于每个服务都有自己存储credential的机制,需要事先为每个服务设计好如何存储和查找用户的Credential
  2. 由于每次用户请求都会携带用户的Credential,需要事先设计好如何管理鉴权机制

微服务常用访问安全设计方案——Basic Auth + Central Auth DB

20160831203518

第二种,如上示意图所示,使用Basic Auth协议,与第一种方案相比,每个服务共用有同一个Auth DB。

第二种方案的特点和第一种很相似:

  • 每个提供功能的服务都拥有自己独立的鉴权和授权机制
  • 每个提供功能的服务共用同一个DB,来保存Credential等敏感信息
  •  每次用户请求都需要携带用户的credential来完成操作

小结下使用第二种方案的好处:

除了拥有第一种方案相似的好处外,由于共用了同一个持久化仓库来管理用户信息,简化了原来独立管理的机制

同时,小结下使用这种方案需要注意的地方:

  1. 中心化Auth DB会被每次用户请求来访问连接,可能引发AuthDB性能瓶颈
  2. 需要在每个服务中实现对共有Auth DB查找用户信息的逻辑

微服务常用访问安全设计方案——API Tokens

20160831203526

第三种,如上示意图所示,使用Token Based协议来对用户请求进行操作鉴权。

简单介绍下最基本的Token Based的交互方式:

  • 用户使用包含用户名和密码的credential从客户端发起资源请求
  • 后端接受请求,通过授权中心,生产有效token字符串,返回给客户端
  • 客户端获得token后,再次发出资源请求
  •  后端接受带token的请求,通过授权中心,获取相关资源,返回给客户端

业界常用的OAuth就是基于Token Based这套逻辑,实现的互联网级的鉴权机制。

第三种方案的特点明显:

  1. 使用token来进行鉴权,替换用户本身的用户名和密码,提高了交互安全性
  2. 每次用户请求需要携带有效token,与Auth服务进行交互验证

小结下使用第三种方案的好处:

由于使用了token来鉴权,业务服务不会看到用户的敏感信息

同时,小结下使用这种方案需要注意的地方:

Auth服务可能需要处理大量的生产token的操作

微服务常用访问安全设计方案——SAML

20160831203535

第四种,如上示意图所示,使用SAML协议来对用户请求进行操作鉴权。它是一个基于XML的标准,用于在不同的安全域(security domain)之间交换认证和授权数据。在SAML标准定义了身份提供者(identity provider)和服务提供者(service provider),这两者构成了前面所说的不同的安全域。

以上图Google提供的Apps SSO的机制,简单介绍下SAML鉴权的交互方式:

  1. 用户请求访问自建的google application
  2.  当前application 生成一个 SAML 身份验证请求。SAML 请求将进行编码并嵌入到SSO 服务的网址中。
  3.  当前application将重定向发送到用户的浏览器。重定向网址包含应向SSO 服务提交的编码 SAML 身份验证请求。
  4. SSO(统一认证中心或叫Identity Provider)解码 SAML 请求,并提取当前application的 ACS(声明客户服务)网址以及用户的目标网址(RelayState 参数)。然后,统一认证中心对用户进行身份验证。
  5. 统一认证中心生成一个 SAML 响应,其中包含经过验证的用户的用户名。按照 SAML 2.0 规范,此响应将使用统一认证中心的 DSA/RSA 公钥和私钥进行数字签名。
  6. 统一认证中心对 SAML 响应和 RelayState 参数进行编码,并将该信息返回到用户的浏览器。统一认证中心提供了一种机制,以便浏览器可以将该信息转发到当前application ACS。
  7. 当前application使用统一认证中心的公钥验证 SAML 响应。如果成功验证该响应,ACS 则会将用户重定向到目标网址。
  8. 用户将重定向到目标网址并登录到当前application。

目前SAML在业界也有相当的使用度,包括IBM Weblogic等产品。

第四种方案的特点有:

  1. 由Identity Provider提供可信的签名声明
  2. 服务的访问安全由可信的Identity Provider提供

小结下使用第四种方案的好处:标准的可信访问模型

同时,小结下使用这种方案需要注意的地方:

  1. 基于XML协议,传输相对复杂
  2. 对非浏览器客户端适配不方便

四、Spring Cloud Security解决方案

Spring Cloud Security特点有:

  1. 基于OAuth2 和OpenID协议的可配置的SSO登录机制
  2.  基于tokens保障资源访问安全
  3. 引入UAA鉴权服务,UAA是一个Web服务,用于管理账户、Oauth2客户端和用户用于鉴权的问题令牌(Issue Token)。UAA实现了Oauth2授权框架和基于JWT(JSON web tokens)的问题令牌。

20160831203546

下面简单介绍下UAA,事实上,它是由CloudFoundry发起的,也是CloudFoundry平台的身份管理服务(https://docs.cloudfoundry.org/concepts/architecture/uaa.html)。

主要功能是基于OAuth2,当用户访问客户端应用时,生成并发放token给目标客户端。

UAA认证服务包含如下几个方面的内容:

  1. 认证对象。如用户、客户端以及目标资源服务器
  2. 认证类型。主要有授权码模式、密码模式以及客户端模式
  3. 认证范围,即认证权限,并作为一个命名的参数附加到AccessToken上。

接下来,结合实例,一起来看下UAA在Spring Cloud中的实践。

20160831203553

如图所示,这是一个简单的基于Spring Cloud微服务架构的例子,它的主要组件有:

  1.  Eureka组件提供服务发现功能
  2. 独立的Config组件提供类似配置中心的服务,持久化层可以是文件系统,也可是git repository
  3.  Auth组件提供基于UAA的鉴权服务
  4. Account组件保存用户的业务信息
  5.  其他组件不一一介绍了

这里主要讲Auth组件和Account组件是如何基于UAA服务进行认证和授权。

20160831203600

图一为Auth组件业务代码中定义了不同客户端的认证类型和认证范围,其中:

  •  浏览器端的认证类型是password,认证范围是ui
  • account组件端的认证类型是client_credentials,认证范围是server

图二为config组件(配置中心)定义的请求路由的规则,其中:

  • 使用/uaa/**来转发基于uaa的认证请求至auth组件
  • 使用/accouts/**来转发请求至account组件,并标记serviceId为account-service,与图一中的withClient对应。

Q20160831203607

图一为浏览器打开应用入口后,输入用户名和密码后,发出的认证请求:

  1. 认证url为/uaa/oauth/token,这是uaa模式下标准的请求获取token的url
  2. 表单中包含了字段scope(认证范围)和字段password(认证类型)

图二为图一发出认证请求的返回结果:

Access_token为有效认证token,将来被其他请求使用

图三为发出获取当前用户的信息的请求:

在请求里的Authorization的值为图二中获得的access_token

20160831203614

图一为Account组件在Config组件(配置中心)定义的OAuth2协议下获取token的方式,这里定义了:

  1.  clientID和clientSecret
  2.  accessTokenUrl,这里指定了auth组件的uaa获取token的url
  3.  grant-type,即认证类型,这里指定为client_credentials
  4.  scope,这里指定了server,说明是这个认证请求只适用在各微服务之间的访问。

图二为Accout组件业务代码中定义了需要使用Auth组件进行事先鉴权的方法:

  1. 使用@PreAuthorize
  2.  annotation中可以指定认证范围的具体条件,这里是限定了server或者是demo账户,才有权限发起认证。

20160831203621

最后小结下Spring Cloud Security的特点:

  1. 基于UAA,使用OAuth2协议。不会暴露用户的敏感信息
  2.  基于认证类型和认证范围,实现细粒度的鉴权机制
  3.  非浏览器客户端下良好的操作性

Docker企业级管理平台开放下载 好雨云|云帮

刀客info阅读(3449)

云帮是什么?

云帮是一款基于容器技术的(应用管理/Docker管理/高效运维)PaaS平台。社区版针对个人、企业完全免费,您可以自由的下载与传播,但需要遵循我们的社区版协议。

云帮从哪里来?

云帮是北京好雨科技有限公司结合容器技术整合的一套管理平台。从2015年3月开始,历经18个月,云帮已经帮助30余家传统企业完成由传统IT架构向容器技术架构的迁移。同时,近千家互联网企业接受并体验了我们的公有云服务,解决了他们在开发、测试、交付、运维等整个应用生命周期中遇到的诸多问题。

如今,我们宣布云帮社区版免费,希望能有更多的企业和个人爱好者享受到容器及云计算技术所带来的高效与便利。

云帮的技术栈

云帮以容器作为最基本的计算单元,对Kubernetes(K8S)与 Docker 进行了深度整合,并针对企业级服务特性自主研发了应用引擎、运维平台、持续交付引擎、自动化运维、云应用市场等功能模块,底层的分布式存储、SDN、日志收集、实时统计则采用了扩展性极强的插件式设计,增强了平台的灵活性和扩展性。

20160831153748

云帮能解决什么问题?

1、新一代企业PaaS平台

让开发人员轻松地开发、部署和运维应用,让架构师和IT运营人员利用熟知和可靠技术打造一个受控的运行环境。有助于加速企业级应用服务于市场,实现 IT内部资源的有效利用。

2、Docker管理平台

虽然目前市场上出现了许多的开源容器管理平台,但是在容器的管理、容器集群的管理上,尚需投入较大的成本。若想在生产环境中使用,甚至成体系的支撑业务系统,投入的人员、技术、资源就更不可量度了。这也是目前大面积使用容器的用户都是技术性大企业。

一个简单易用、功能强大、性能稳定的Docker容器管理平台拉近容器与用户的距离,使更多的企业享受到容器及云计算技术带来的便利。

3、多环境多资源池的DevOps开发流

在产品研发阶段,云帮支持多达8种的常见开发语言,并遵循云原生应用12法则,实现基于源代码的自动化构建,通过代码即环境的特性及基于容器的多环境多资源池 DevOps实践,在高效持续交付的同时,屏蔽环境不一致带来的内耗。

4、自动化运维与性能监控

云帮支持代码既环境的特性,有效解决环境不一致问题,统一流程,减少内耗。

通过云帮发布的应用原生支持高可用,通过内建服务发现机制,自动调度容器,保障业务持续性。

云帮支持自动与手动弹性扩展,可根据预设阀值或实际业务运行状况,灵活扩展业务集群,更支持有状态的服务水平伸缩。

通过在线实时日志展示与分析、实时业务监控和实时性能分析,云帮可以做到业务性能预知分析与智能弹性伸缩,分析应用运行瓶颈及自动感知应用负载,不需要准备提前量,轻松应对大并发,保障业务服务质量。

5、提供企业级云应用市场

云帮链接了企业级云应用市场产品:云市,云市中已经发布上百种企业级云原生应用及企业中间件,后续更有多家SaaS软件供应商接入,为企业信息化建设提供庞大的应用群。

云帮可以为企业批量部署标准应用,也可以一键部署定制化应用。云帮核心支持微服务架构,软件提供商只需通过云帮的DevOps流程定制化交付核心业务应用,企业即可进行自动化批量部署。

对于企业内部业务,可通过云帮一键共享至公有云市或私有云市,轻松实现按需取用、一键部署。

6、IT架构无缝升级微服务架构

云帮核心支持微服务架构,任何应用部署即微服务,原有技术架构可直接迁移,支持各种分布式架构。

云帮的微服务架构是多语言混合的微服务,协议透明,灵活性高,支持任何类型的服务,可以根据业务需求更加高效、安全、灵活的设计业务架构。

通过注入环境变量,自动配置管理和自动服务发现,可动态调整服务间依赖关系,通过内置服务断路器机制,提高服务容错性。

兼容dubbo,spring cloud等常见微服务架构。

7、快速开发上线,应对大并发

云帮提供高效的软件开发运营流程,快速交付产品,支持灰度发布与AB版本测试,保证需求的快速交付。

提供业务级的监控,借住平台的性能预知分析与智能弹性伸缩,分析应用运行瓶颈及自动感知应用负载,轻松应对大并发,为应用的高质量服务提供基础保障。

云帮的快速弹性伸缩可在秒级完成上千个业务节点的弹性扩展,对于业务的突增大并发实时智能伸缩,在保障服务质量的同时有效节省运营成本。

分类 功能 说明
CI/CD 源码部署 支持java,php,python,ruby,nodejs,golang等主流的开发语言
Dockerfile构建 兼容官方的Dockerfile镜像构建
支持 12factor 满足云原生应用的12要素原则
可定制的开发和交付流程 根据用户使用场景可以灵活的定制开发和发布流程
代码滚动上线 独特的代码滚动上线功能,现有业务不会因上线而中断
一键代码回滚 支持代码的一键回滚功能,且不影响现有业务
对接各类Git仓库 可以对接私有和共有的Git仓库
高效运维 手工伸缩(垂直,水平) 支持应用的手工垂直、水平伸缩
实时日志查看/下载 支持应用实时日志的输出、查看和打包下载
服务高可用 提供单点与多节点的服务高可用机制
负载均衡 应用原生支持负载均衡
应用高级管理 应用支持端口/域名/环境变量/对内对外服务的高级管理选项
实时业务监控 提供实时的业务级监控
实时性能分析 支持实时的HTTP/MySQL协议性能分析
应用控制 支持应用的停止、启动
应用市场 私有应用市场 企业分享和使用的内部应用市场
公有应用市场 支持对接好雨应用市场,一键部署更多应用(ELK/Gitlab/MongoDB/Kafka……)
应用发布 支持将运行的应用发布到私有/公有应用市场
应用一键部署/升级 私有/公有应用市场的应用支持一键部署和升级功能
微服务架构 服务自动发现 支持依赖服务的自动发现机制
自动配置管理 支持应用配置与环境变量管理
动态服务编排 借助于自动服务自动发现功能,可以实现服务的动态编排
混合微服务架构 支持多语言的混合微服务架构
支持任何服务协议 支持现有的服务协议
支持开源微服务架构 支持 dubbo,spring cloud 等主流的开源微服务架构
平台 开放API 接口 支持平台全功能的API接口
团队权限管理 支持灵活的团队和应用管理权限
SDN 高级网络组建 基于Overlay 网络组件
基础网络组件 基于全路由的网络组件
SDS NAS 支持NAS存储方式,如NFS/GlusterFS
SAN-CEPH 支持SAN-CEPH分布式存储
SAN-scaleIO 支持SAN-scaleIO分布式存储
支持 社群支持 社区、文档、QQ/微信群

基于云基础设施的微服务(下)

刀客info阅读(2032)评论(0)

 目 录

简介

服务术语解释

微服务

微服务最佳实践

微服务和基础设施

微服务和基础设施设计原则

乐高积木方法

微服务基础设施 – 乐高积木蓝图

由此产生的概念模型

微服务基础设施 – 合理的实现步骤

总结

 

上篇请点击《[译]基于云基础设施的微服务(上)》

乐高积木方法

微服务需要基础设施服务能遵守之前列出的关键服务相关需求。这意味一个需求基础设施服务的个人(或微服务),遵循乐高积木原则,通过使用「简单」的购物单和交付实用型服务,应该能够构建和消费基础设施功能。

20160828193729

基础设施服务应该有标准的积木(比如服务、存储和网络),以及由这些积木构成的附加组件(比如Web服务器、预生产环境等)。每个标准的积木和附加组件必须不做任何修改就可以满足不同的 SLA(服务级别协议)和 KPI(关键性能指标)。

例如:

Web 服务器

  • 一个简单的 Web 服务器符合青铜级别
  • 一个 Web 服务器符合白金级别

数据存储解决方案

  • 标准数据库存储优化
  • 提供最大容量
  • 高可用和高实施

完整的应用程序环境

  • 进一步开发应用程序
  • 进行满负荷性能测试
  • 为最终用户进行关键技术培训

20160828193738

「基于乐高积木方法购物单」的关键组件是服务级别特点。每个客户环境都是不同。然而,每个客户端都将会有一个特定的服务级别:从白金(99.999%)到青铜(99%)。当然一整套不同的非功能性需求将会影响底层的基础设施。

例如:

  • 可扩展性:确保解决方案支持当前和预计的业务量。
  • 以可靠性为核心:确保解决方案提供一个适当级别的鲁棒性,以支持业务流程。
  • 可管理性:确保解决方案可以高效和有效的管理维护。
  • 可用性:确保解决方案提供了所需的服务级别。

从铂金到青铜的服务级别和非功能性需求都可以转化为非常具体的基础设施相关的需求,从而可以定义基于乐高积木的标准基础设施组件。

以标准或预定义「行为」提供每个预组装的基础乐高积木,每个基础的乐高积木将满足一定的可用性、稳定性、性能和安全相关需求(所谓的服务特点)。

如上所述,主要有4个类别:白金、黄晶、白银和青铜,如何下图所定义(每个客户环境是不同的,因此这里提供的细节仅是范例。):

20160828193745

注意:这个分组和详细的业务特点仅是范例。每个客户环境是不同的,对于一些黄金级业务服务(或 IT 应用程序)可能有长达 6 小时恢复时间目标和 45 分钟恢复点目标。

微服务的世界,基础设施服务必须可重复、自动和简单地消耗。当构造基础设施服务时,非功能性需求是关键因素,因为这些将作为功能性基础设施需求实施创建、使用、移动、扩容、缩容和删除。

微服务基础设施 – 乐高积木蓝图

根据乐高积木原则,每个使用基础乐高积木的组件会遵循不同的蓝图以满足所需的各种非功能性需求和行为。和真正的乐高积木一样,有着无数的选择以建造任何所需要的飞机、房子或城堡。唯一的限制是物理尺寸和特征。

20160828193752

在基础设施环境中使用乐高法则,同样的原则适用于:一套 ILB 用来创建一个预生产环境,同样也可以用来创建一个高可用的生产环境。关键是要使用标准 LIB 并在清晰的蓝图上基于目标进行构建。

由此产生的概念模型

基于微服务的基础设施必须适合企业级架构模型(这同样适用于 SOA,但也有一些关键的不同之处),覆盖就如本文所述的所有相关基础设施。

Infrastructure Lego® based approach

20160828193800

当使用微服务时,特别在有些方面如云环境中的分段、编排、自动化、池化和安全是团队应该考虑的关键理论能力。这样一个概念模型可以作为从 SOA 到基于微服务方法转换的一部分,协助精准的产品选择。

微服务基础设施 – 合理的实现步骤

没有客户环境能一步实现微服务(当然除非实现「绿色领地」),为了确保现有的基础设施服务可以支持和提供基于微服务的能力,应该考虑以下的四个步骤:

20160828193809

总结

微服务并不总是最佳选择:基于单体和 SOA 的解决方案在 IT 领域仍有(并将持续有)一席之地。然而,微服务是使用最先进技术的软件模式,并持续影响基础设施的设计、构建和运营。

从基础结构的角度来说成功的关键是使用基于遵循「塞、玩和编排」方法的乐高积木原则构建基础设施服务,实现「隐形」的微服务。

然而,通往基于微服务的基础设施布局并非直线,必须克服服务的复杂性、实践成本、现有架构以及不断变化的新环境。使用基于微服务基础设施的成功团队遵循以下四个步骤的实现计划:统一化、自动化、面向服务和编排。

原文:Microservices in cloud-based infrastructure – Paving the way to the digital future

作者:Gunnar Menzel

基于云基础设施的微服务(上)

刀客info阅读(1859)

原文:Microservices in cloud-based infrastructure – Paving the way to the digital future

作者:Gunnar Menzel

目 录

简介

服务术语解释

微服务

微服务最佳实践

微服务和基础设施

微服务和基础设施设计原则

乐高积木方法

微服务基础设施 – 乐高积木蓝图

由此产生的概念模型

微服务基础设施 – 合理的实现步骤

总结

附录:参考文献

由于篇幅限制,本文后半部分将在下期推送。

简介

微服务需要一种新的基础设施构建方式:微服务意识(microservices-aware)必须遵循乐高积木方法。

一切事物都具周期性。早在 2005 年,我们讨论、定义、开发了基于面向服务架构(SOA)解决方案(2005 年 Capgemini 的 SOA 观点、论文、白皮书已经提出了「一切即服务」的概念)。如今,当被问及什么是一流的软件蓝图时,我们倾向于推荐微服务(2011 年 5 月,「微服务」一词最早由威尼斯附近的一个软件架构师小组提出)。两者都基于同一简单的概念:将设计和开发独立开来,基于效用的服务可以驱动并提供灵活性、安全性、敏捷性。我们正在从第二代平台过渡至第三代平台(第一代平台架构指的是主机时代(单体应用),第二代平台指的是基于 Client/Server 的运算,第三代平台是原生 Web 格局,用户可以在任何时间任何地方使用任何设备访问应用程序和数据)。在应用程序、数据、自动化为王的时代,越来越多的团队开启了「数字化」的格局。

10 年前推出的时候,微服务是设计和构建应用程序的方法之一,基于单体或 SOA 的方案都仍是合理的选择。然而,基于微服务设计的应用程序正在持续增长,特别是使用第三方平台功能的团队。微服务需要一种新的基础设施构建方式:微服务意识(microservices-aware)必须遵循乐高积木方法。由此产生了基础设施平台必须完全基于软件。这意味着,数据中心将由软件实现完全自动化,以便通过软件管理硬件、网络、存储配置。这与硬件和驱动定义基础设施的传统数据中心形成了鲜明的对比。

为了实现全面数字化,加快数字化进程,团队的基础设施布局必须遵循一套明确的设计模式,比如易用性、自助性、敏捷性和灵活性。然而,浏览所有相关项将会变得非常棘手,所以微服务将提供一些指引,本文的主要两个目的:深度分析微服务对基础设施产生的影响;调查如何设计如今基于微服务的基础设施。

服务术语解释

现在有相当多的专业架构术语,比如面向服务架构(SOA)、事件驱动架构,微服务架构和软件定义数据中心(SDDC)。一些常见的观点认为「服务」是业务、技术功能、物理产品或架构方法,并没有标准的定义。事实上,「服务」这个词根据不同的环境有许多抽象概念:

20160826195505

  • (面向)服务架构:设计模式主要与企业架构及其业务、信息、信息系统和技术基础设施的整合方式相关。
  • 业务服务:业务运营模式结合业务流程和业务事件,评估缩容价值的设计方式。
  • 应用程序服务:通过各种技术解决方案和标准为「业务服务」提供应用程序支持(这是微服务主要涉及的领域)。
  • Web 服务:通过标准的 Web 服务协议进行大量访问的特殊应用服务,特别是用以接受和返回 XML 文件,比如定义协议;但是普遍标准不同。
  • 信息服务:通过各种技术解决方案和标准,实现为应用程序服务提供信息的设计方法。
  • 基础设施服务:为应用程序、Web、信息服务提供支持的独享或共享的基础设施服务。
  • 基于服务的方法主要是为了开发或构建能被应用在不同环境的细粒度功能。

微服务

微服务涉及的设计模式是一系列的独立应用程序服务使用独立,低耦合,自包含(没有外部依赖)的业务功能进行交付。遵循 SOA 的风格(见下文),微服务更自主、独立,比 SOA 更小或更细粒度。

微服务架构可以视为面向组件架构和面向服务架构结合的产物。软件是一套由负责各自具体业务领域的许多小型业务组件构成的系统。他们通过明确定义服务的 API 对外提供接口。

20160826195521

服务的所有权是微服务从 SOA 彻底脱离的一个方向:使用微服务,只需要一个团队或个人就可以开发和更新已有服务的代码,Netflix 就是使用这种模式的公司。微服务得以发展壮大是因为其彻底贯彻了 Eric Evans 的领域驱动设计 [1]- 因为其可以由小型的独立团队进行开发和维护。

低耦合的服务可以彼此独立更新;一组必须同时更新的服务并不能称之为微服务,因为其并非低耦合,这也适用于服务之间共享同一数据库的情况,更新一个特定的服务意味着改变整个模式(schema),或对共享模式(schema)的更新将牵动一个以上的微服务 – 称之为「反模式」。

微服务最佳实践

实用的基础设施服务是一个交付服务解耦的共享基础设施并支持先前定义的设计原则的计量服务。

如之前所说,微服务与 SOA 有许多共同之处。SOA 主要是关于「暴露」应用程序的离散组件,作为 Web 服务和基于 SOA 的应用程序包含由适用于不同环境的更低耦合的组件。SOA 是从第一代平台过渡到第二代平台的关键模式,微服务是团队迁移至第三代平台的关键。

持续开发和提供基于微服务应用程序的详细定义,不在本文的讨论范围之内。然而,理解基础设施架构布局需要遵从什么特性以支持基于微服务的应用程序,定义微服务的设计原则非常重要。微服务的关键设计标准都与服务说明有关。

「好的」微服务:

1、拥有无状态(无状态在特定的体系架构中越来越罕见。2015 年 Strange Loop 上有一则关于有状态微服务的演讲。无状态所以无法确定什么是「微服务」。然而,除非绝对必要,需要避免这种想法)且「愚蠢」的细粒度功能。

2、拥有定义明确的用于隐藏服务如何运行的接口(也就是说,我只关心接口,而不是服务是如何在内部运行)。

3、使用低耦合方法(某个服务的更新不会影响其他服务)。

4、「一次性的」、「脱离 ESB(企业服务总线)」、「笨水管和智能服务」。

5、自主、明确版本、高度独立。

6、简单思考,即「专注做一件事,并做到极致」。

7、明确的成本和价值定义。

遵循这个设计原则引出基于微服务的架构风格;开发和实现基于微服务的应用程序,必须覆盖方方面面。从基础设施的角度来说很重要的一点是,基于微服务的应用程序必须要遵循基于效用的方法,对于微服务来说意味着基础设施需要「隐形」。基于效用的基础设施服务的交付物是封装后的基础设施资源,相当于传统公共服务(如电、水、天然气、电话网络)的计算、存储、数据传输、类似于计量服务等。换句话说,实用的基础设施服务是一个交付服务解耦的共享基础设施并支持上述定义的设计原则的计量服务。

微服务和基础设施

为了实现微服务,底层基础设施性能必须支持微服务的设计模式,并专注于所有相关的非功能性特征(可用性、稳定性、可靠性、性能和安全)。微服务需要开箱即用并可以使用「乐高积木」方法构建的基础设施 [2]。

基础设施相关能力如计算、存储、网络,和基础设施相关功能如负载均衡、主从复制等一样,必须遵循「即插即用」的方法,并且微服务的实现必须是透明的。

透明的关键推动者显然是「云」。采用云基础设施的方法,将加速基于微服务应用程序的实现。

20160826195530

软件模式和相关基础设施建设蓝图的基础设施,更准备地说是技术基础设施,是所有在特定的环境通过信息系统(应用程序)对使用或消费的数据进行存储、处理和传输的技术组件的组合;有一定的性能特征和一系列所谓的非功能性需求。

为了构建「隐形」的微服务,基础设施服务必须符合特定的特征。走近细看,这意味着微服务开发人员不仅必须拥有构建、使用、迁移、扩容、缩容、删除和计算的能力,还需要有网络和存储能力。这包含所有客户面临的基础设施服务。就像融合、超融合和全融合的基础设施(或更好的软件基础)使用私有云、公有云或混合云部署或备份概念,这将是很多团队使用微服务的模板。

微服务和基础设施设计原则

基于微服务的基础设施平台必须软件化。这意味着将由软件实现数据中心的全自动化,以便通过软件管理硬件配置、存储供给,网络配置。这与通常使用硬件和驱动管理,需要手动操作进行更改基础设施的传统数据中心不同。

20160826200208

附录:参考文献

[1] Eric Evans,2003,《领域驱动设计:软件核心复杂性应对之道》;Capgemini 2005,面向服务的企业:如何使业务快速、灵活、响应

Docker正方登场——未来正在远方

刀客info阅读(1064)评论(0)

周一时候小数与大家分享了一篇关于Docker的反方言论——《一份Docker的反方辩论——我还是用Heroku好了》,一周之后,同样的作者,又为Docker正名,写了一篇正方言论。Docker的未来在何处?且看下文分解——

之前我写了一篇《It’s the Future》的文章,点评了容器生态系统,顺带嘲弄了下Docker、Google、CoreOS和一系列其他技术。许多Docker爱好者非常喜欢结尾那个玩笑,但是也有很多人喜欢那句“我告诉你们它们都是渣渣”。

不难理解为什么人们会认为容器生态系统是“渣渣”,尤其是从我上篇的角度来看。毕竟,匆忙的一瞥很难弄清楚Docker到底是什么。容器化有点像虚拟化,但是并不完全一样。它有一个类似Chef的Dockerfile,但是是和一个和分层相关的文件系统结合的。它和AWS 、Heroku 、 VMware 和Vagrant一样解决类似的问题,但是又有些不同。它有27个彼此有竞争关系的工具,很难说上来它们具体干嘛用,名字也都非常有意思——比如machine、 swarm 、 flannel 、 weave 、 etcd 、 rkt 、 kubernetes 、 compose 和 flocker等等。它一定程度上和新兴的微服务有关联,但是要去考虑如何让单一服务首先跑起来又显得很蠢。

如果仔细看过了Docker和容器,仍然认为它是渣渣,那么也可以理解——除非它不是。

好吧,它确实不是,它是我们搭建应用的未来。

为什么讨厌它?

许多看了《It’s the Future》的人觉得文章写的非常准确,并没有讽刺和夸张,然后质疑了容器这个事物,为什么呢?

Docker和其容器生态系统(之后简称“Docker”)正在改变应用开发世界的一些基础,比如虚拟化、面向服务的架构和操作系统,然后把它们以不同的目标和优势重新交付。但同时,也触怒了开发者社区的一些人——守旧而讨厌新事物的顽固派。

软件行业可能与想象中不同,其实充满了抵制进步的人们——就如同当米开朗琪罗完成了他的创作,那群走进西斯廷教堂的人们却开始声称他们已经有了很好的上帝画作,他们更喜欢天花板是纯白的,米开朗琪罗的壁画一点都不美好。

同时,大部分的软件行业像高中学生一样做着决策:他们着迷地搜索着他们小团体内更酷的东西,看看Instagram和 Facebook上都有什么,然后盲目地追随着他们的引导者。这些技术形成了各自的派系,精心雕琢着各自的技术——甚至会在笔记本上贴上属于他们的标志和颜色,并且排斥和抱怨他们陌生或者不同的技术。

而进入的那个世界的Docker——几乎所有的工作方式都是新的。它抛弃了各种旧规则——包括操作系统、部署、运维、 封装、防火墙、PaaS等等。一些开发者立刻爱上了它,有时候是因为它有效解决了一些问题,有时候是因为它是闪亮的玩具——让他们在其他孩子玩到它之前显得很酷。另一些开发者则讨厌它,讨厌它大肆的宣传和炒作,认为它就和其他之前新出的技术一样,并没有什么不同,却被人人谈论着。

因此,很多人对于Docker的感受并不是源于技术本身。许多Docker的反感者并不是厌恶Docker在重要和复杂问题上的解决能力。如果他们没有花足够的时间去了解大规模系统的扩缩,绝大多数问题他们是没法理解的。如果不是直观且深入地了解过,那么关于Docker的很多选项和相关的工具都会看起来很奇怪很吓人。

正在一统的世界

Docker出现在两个学科的结合点上——Web应用和分布式系统。对于过去的十年,我们在web社区很多时候都在假装只要知道如何编程就可以搭建web应用。我们写一些HTML、 JavaScript 、 Rails,然后我们就有了一个网页。我们加一些窗口、处理程序和一个API,然后我们就完成了它。之后发布产品,就能够吸引用户,获得收入,就改变这个世界了!

而同时,过去的二十年间,分布式系统的家伙一直在做一些相当无聊的东西。他们使用CORBA和SOAP这样复杂的协议进行试验,学会了如何处理像CAP定理这样的问题,了解了时钟同步是何等重要,认识到Two Generals Problem等主要理论。这些问题和解决方案对于只是想简单地编程和交付应用的人来说,相当的乏味无聊。

但是之后有趣的事情发生了。Web应用变得非常大,开始变得规模化。很多人进入互联网,web应用不能只在单一VPS上,或者只是垂直方向扩展。我们开始扩大它的规模,然后我们看到了应用中的各种bug,它们的名字很有趣:像“raceconditions”,“networkpartitions”,“ deadlock”和“Byzantine failures”等。这些问题是分布式系统的那些家伙搞了很久的问题,很多问题的解决方案不只是困难,理论上甚至是不可解的。

在扩展危机的早期,Heroku出来了。Heroku可以使我们很容易地在基础设施水平层面上进行扩展,让我们再一次假装只做简单web应用。于是那五年,我们花钱买的是自欺欺人的假装。

我们现在走到了自欺欺人的边界上,轻轻一脚迈了出来,我们在试图建立早期的扩展性,重构破碎的事物,了解了单体应用架构的缺点以及为什么单一数据库不能持续为我们工作。我们提出了一些概念,像不可变架构,“宠物还是放养”,微服务,以及一整套最佳和最差实践来尝试让问题简单化。

在这个转变中,Docker入局,尝试解决很多问题。但是与Heroku那样告诉我们可以假装扩展问题不存在、可以继续按照过去的方式来行事不同,Docker告诉我们分布式系统是我们一直在做的基础,我们需要接受它并在这个模型下工作。不再像过去的web框架、数据库和操作系统那样只处理简单问题,我们现在使用Swarm、Weave、Kubernetes和etcd等工具,不再假装一切都很简单。实际上,我们不再是单纯解决问题,而是深入了解我们正在解决的问题。

我们终于有能力构建可伸缩的架构而不是假装它只是抽象事物了。现在我们需要了解什么是网络分区并且如何处理它,如何在AP和CP系统中做出选择,如何构建在现有网络和机器的约束下仍然可以扩展的架构——有时在弗吉尼亚州发生一场风暴,有时会发生火灾,有时鲨鱼会咬断海底电缆,有时会是一个延迟、一个交付失败、机器死机或者抽象层有了裂缝,意外总是不时发生,不是吗?

一切都渴望更有弹性、更可靠,作为开发应用的一部分这些都是需要考虑的。并不是因为它是闪亮的新事物、或者它是一些虚构的最佳实践,而是因为像亚马逊、Netflix或者Google已经在这上面投入了15年的心血,他们告诉了我们如何构建真正有规模的系统。

真正的问题解决者

所以,Docker到底为我们解决了什么问题?我们为搭建web应用而做的每件事都是脆弱而混乱的,Docker正在让它变得清晰而条理:

截止目前,我们已经部署机器(DevOps中的运维部分)和应用(开发部分)分离,甚至我们有两个不同的团队来管理这部分应用的堆栈。然而这很可笑,因为应用像依赖代码一样依赖着机器和OS,考虑把它们分开没有意义。容器在开发者工具的帮助下可以统一管理OS和应用。

截止目前,我们一直在AWS上运行我们的面向服务的体系架构、Heroku、其他PaaS和IaaS,缺乏真正的工具来管理面向服务的架构,而Kubernetes和Swarm管理和编排了这些服务。

截止目前,我们已经使用整个操作系统来部署我们的应用。容器允许我们公开一个非常小的应用程序,只需要一些端口——小到一个静态二进制。

截止目前,机器上线后我们一直通过使用“配置管理”工具或者在同一台机器上重新部署应用来摆弄它们。由于容器是通过编排框架来实现规模扩缩,只需不变的镜像来启动,跑的机器不会被重复使用,消除了潜在的故障点。

截止目前,很大程度上我们一直在使用单个机器为单体应用设计的语言和框架。在这之前,Rail为面向服务架构设计的路线没有真正存在过。现在Kubernetes和Compose允许我们在服务之上指定拓扑结构。

截止目前,我们已经部署了由亚马逊等提供的重量级虚拟化服务器。然而我们不能说“我想要0.1个CPU,和200MB的内存”。我们已经浪费了很多虚拟化的开销和超出应用所需的资源。而容器可以更少需求地进行部署,并且更好地进行共享。

截止目前,我们已经在多用户操作系统上部署了应用和服务。多个用户可以同时跑在Unix上,共享文件、数据库、文件系统和服务。当我们搭建web服务时,它会与我们的工作完全不匹配。而容器可以保存简单文件而不是整个操作系统,让我们减少对于应用和服务的考虑。

要做的事情唯有改变

我们的行业发展如此迅速,对于新技术狂热崇拜并且不会等技术真正落地成熟。Docker正在以不可思议的速度发展着,这也意味着它还没有接近稳定和成熟。对于容器运行时、镜像格式、编排工具和主机OS,我们有很多选择,每一个都有不同的使用水准、范围、吸引力和社区的支持。

环顾我们的行业,在事物变得又老又无聊之前,它是不会稳定。举个例子,在我们有REST之前,有多少协议不得不消亡。我们踩在SOAP和CORBA的尸体之上通过经验和教训建立了REST 、AJAX和JSON。这是过去十年最主要的两个技术转折点。然而我们基于API的REST工具还没有达到十年前我们为SOAP所做的水平,特别是SOAP尚未完全死亡。

我们都知道Docker还没有成熟,在尝试它的时候仍有许多边界情况和缺陷。问题的浮沉之间,我们一次又一次思考解决的办法,不断尝试不断失败,直到探索出最佳实践的方法。可能几年以后我们再回顾这段经历,会发现很多决策上的错误或者失败,但是这就是探索的意义,进步的代价。

或许会花费很多年的时间,了解了它全部的特性,Docker才会真正稳定下来。但是这并不意味着容器是无稽之谈。我们总是面对着选择,是选择我们已经深刻了解的技术还是尝试一些新的事物?答案很清楚,只有不断地学习和适应技术的迭代,才能带来我们行业的进步和提升。

如果你在寻找我,那么向前看,我就在未来。

(文章转自:CircleCI blog)

Mesosphere协同其数据合作伙伴在容器2.0时代和DC/OS上的赌注

刀客info阅读(1239)评论(0)

【编者的话】本文为Mesosphere在其官方博客中发布的关于容器2.0时代中其数据合作伙伴及DC/OS的介绍。

今天我们宣布,我们已经和产业领导者Confluent以及DataStax公司联合,把他们的产品与商业支持一并整合进DC/OS中。这个重要的里程碑已经进一步说明现在是Container 2.0的时代了。

简而言之,Container 2.0是关于数据库容器,消息系统和其他应用服务-(状态服务)的优势的进一步扩展。我们许多客户信任他们在Confluent和DataStax的关键业务数据。这些共同的客户要求我们携手努力去加速他们在Container2.0上使用DC/OS的步伐。

Apache Kafka,一个高吞吐量的分布式消息系统,在广泛的行业和其垂直领域中正被更多的采纳。Confulent是由Apache Kafka公司的创始人成立的并和Confluent Platform的厂商们用于处理流数据。它专为大规模和可靠性设计,并且非常实际的解决了运行实时数据应用和实时代码构建的问题。

我们从客户那里听到了他们与Confluent团队合作的价值,并且知道了有关于Confluent Platform如何帮助他们实现了10倍于Apache Kafka的业务价值提升。我们期待着与整个团队在Confluent的合作从而可以逐步增加我们基础客户的成功案例。

Apache Cassandra,一个大型的分布式数据库,随着连接的设备与传感器的激增而在突飞猛进地增长着。DataStax是其公认的商业领导者。DataStax Enterprise(DSE)建立于Apache Cassandra之上,从而使得开发者可以用前所未有的性能,可扩展性和可用性去建立创新的实时网页,移动和物联网应用。

我们从客户那里听到并得知,DataStax是他们最值得信赖的合作伙伴,并且DSE使得他们可以以前所未有的速度进行创新。我们很高兴能有一个这样的强有力的,在企业数据领域内最可信的名字之一的DataStax公司作为我们的合作伙伴,可以使客户们能够更紧密。

datastax-confluent-400x204@2x.jpg

DC/OS可以方便地配置,部署,扩展和监控Confluent平台和DataStax企业版,这都可以通过DC/OS全局配置上的单一的点击来进行安装。DC/OS使你能够同时运行微服务与数据摄入,数据库和实时分析,毫不费力地提升物联网的能力,用灵活地,弹性地数据基础设施来预测分析和个性化应用程序。

现在,围绕着Reactive Platform和Apache Spark,我们也一起扩大对Lightbend支持与合作,合作范围涉及Reactive Platform和Apache Spark,该平台的数据处理和分析能力是现代基于数据驱动型企业应用程序的重要组成部分。事实上,Spark、Cassandra和Kafka在实时数据管道方面拥有共同和强大的组成部分。商业订阅的Confluent Platform,DataStax企业版和Lightbend Reactive Platform,以及企业版的DC/OS,都可以从各自的公司得到合宜的使用。

此外,我们还持续地看到客户来自于商业支持的容器状态服务这方面不断增长的需求。我们期待着与Confluent、DataStax、Lightbend和其他数据敏捷型领域的领导者合作去用DC/OS交付产品。

CentOS系统故障 | 一桩”血案”引发的容器存储驱动比较

liu, yu阅读(2203)评论(0)

写在前面:

由于红帽在Linux界的影响力,相信很多朋友在测试和生产系统用的是RedHat或者CentOS系统,这次我在CentOS系统上遇到了一个很有意思的故障,通过这次故障的原因分析及解决,特意写了这篇文章分享给大家。

我们在CentOS上部署了一套Docker系统,运行了一段时间后,突然发现所有容器运行异常,同时宿主机内核报磁盘I/O错误:

1

看到问题的第一反映是查看磁盘状态和空间使用情况,发现系统的根目录已经用完:

2

我们知道,Docker默认的存储目录是在/var/lib/docker/下,同时我们也知道,可以通过使用-g, –graph=”/var/lib/docker” 参数修改Docker 默认存放路径。知道了问题后,我们可以通过挂载一个大硬盘到系统,并将Docker的目录更改为新挂载到硬盘上:

3

我将Docker的存储目录设置到刚才新增加的/data目录下,但是原来的镜像和容器都找不到了,因为路径改了。原来的镜像是在/var/lib/docker/devicemapper/devicemapper/{data,metadata},转移文件后继续运行Docker服务,这样我们就有了一个300G的大房子给Docker们用了。

大家以为事情到了这里就完结了么?其实我也想,但是我顺便折腾了一下,于是又发生了接下来的事情。说我手贱也好,瞎折腾也罢,导入一堆容器镜像和运行一堆容器后,系统又光荣告诉我所有的容器根目录全部变成了只读,宿主机内核同样报磁盘I/O错误,一开始我以为data目录又被写满了,但是用df –Th命令查看后,发现目录还有很多空间:

4

但是残酷的现实是,只用了不到一半的空间后,所有的容器就全部出现异常了,这是我祭出了经典三板斧:重启容器,重启Docker服务,重启服务器。然并卵,容器还是运行异常。通过在网上爬了一堆资料,在http://jpetazzo.github.io/2014/01/29/docker-device-mapper-resize/上查到,CentOS默认用的是Device Mapper作为容器的存储驱动的,大家可以用dockers info命令查看,Docker服务启动时默认会在/var/lib/docker/devicemapper/devicemapper/目录创建一个100G(由于1000和1024换算的关系,系统实际显示的是107.4G,其他数字亦同)的data文件,然后启动的容器的所有变更的数据全部保存到这个data文件中;也就是说当容器内产生的相关data数据超过100G后容器就再也没有多余的空间可用,从而导致所有容器的根目录变为只读!同时它会限制每个容器最大为 10GB。太坑爹了有木有,给了大房子只能用100G!

5

 

为了找到根本原因,我们需要了解Device Mapper存储驱动的原理: Device Mapper存储驱动是以精简配置的方式运行的,它实际上是目标块设备的快照。

Docker启动时会设置一个100G的sparse文件( /var/lib/docker/devicemapper/devicemapper/data,元数据为/var/lib/docker/devicemapper/devicemapper/metadata ),并将其作为Device Mapper的存储池,而所有容器都从该存储池中分配默认10G的存储空间使用,如下图所示:

6

当有实际读写后,这些存储块将在存储池中被标记为已使用(或者从池中拿走)。当实际读写的块容量大于池的容量时,容器的运行空间不足,所以报I/O错误。

Device Mapper存储驱动非常方便,你不需要做任何安装部署便可以使用:如创建额外的分区来存储 Docker 容器,或者建立LVM。然而它也有两个缺点:

• 存储池会有一个默认 100GB 的容量,满足不了大存储的需求。

• 它将会被稀疏文件所支持(精简配置,一开始基本不占用空间,只有当实际需要写的时候才会使用磁盘的存储块)但性能较差。

针对这些问题,有两个解决方案:

1. 使用更大的文件/磁盘/逻辑卷创建data文件:

7

2. 通过Docker启动参数的–storage-opt选项来限制每个容器初始化的磁盘大小,如-storage-opt dm.basesize=80G 这样每个容器启动后,根目录的总空间就是80G。

但是我总觉得这样的解决方式不够优雅,需要多步操作才能满足需求,同时,容器的空间还是被限制的,只是限制的大小变化而已。那有没有更好的办法呢? 让我们继续来爬资料,在Docker的官方网站上:

(https://docs.docker.com/engine/reference/commandline/dockerd/)

8

Docker在存储驱动方面支持 AUFS、Device Mapper、Btrfs、ZFS、 Overlay 、Overlay2等多址方式,现由于AUFS并未并入内核,目前只有Ubuntu系统上能够使用aufs作为docker的存储引擎,而在CentOS系统上默认使用Device Mapper,但是幸运的是,在Linux内核3.18.0以上的版本,是可以原生支持Overlay驱动方式的,Overlayfs跟AUFS很像,但是性能比AUFS好,有更好的内存利用。

Docker通过-s参数选择存储驱动, 通过-s=overlay,我们将存储驱动器设置为Overlay方式,再重启Docker应用。

9

大家可以看到,现在Docker已经是使用了OverlayFS(这里大家要注意,如果系统有存储的镜像和运行的容器,更改存储驱动后将都不可用,请先行备份)。

通过修改为OverlayFS,Device Mapper的存储池容量限制及单个容器运行最大空间限制统统没有了,同时Overlay的读写性能也好于Device Mapper,只需通过-s=overlay一个参数即可优雅的使用更好的文件系统来运行容器。

至此,容器运行时I/O错误的原因已经完美解决,希望这篇文章能帮到在使用过程中遇到相同问题的朋友。

高质量Node.js微服务的编写和部署

刀客info阅读(2066)评论(0)

为促进DockerKubernetes等技术的交流传播,同时帮助用户更全面地了解时速云产品及其应用,时速云每两周会进行一次技术分享,分享时间为周四晚8:30-9:30在用户微信群、时速云技术分享群等进行产品、容器技术相关的技术直播分享和现场答疑。以下整理自7月28日第十三期技术分享内容,由 时速云工程师 张鹏程 分享。

微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件,这使得它们拥有更高的敏捷性、可伸缩性和可用性。

一个复杂的应用被拆分为若干微服务,微服务更需要一种成熟的交付能力。持续集成、部署和全自动测试都必不可少。编写代码的开发人员必须负责代码的生产部署。构建和部署链需要重大更改,以便为微服务环境提供正确的关注点分离。

后续我们会聊一下如何在时速云平台上集成 DevOps

20160803172049

Node.js 是构建微服务的利器,为什么这么说呢,我们先看下 Node.js 有哪些优势:

  1. Node.js 采用事件驱动、异步编程,为网络服务而设计
  2. Node.js 非阻塞模式的IO处理给 Node.js 带来在相对低系统资源耗用下的高性能与出众的负载能力,非常适合用作依赖其它IO资源的中间层服务
  3. Node.js轻量高效,可以认为是数据密集型分布式部署环境下的实时应用系统的完美解决方案。

这些优势正好与微服务的优势:敏捷性、可伸缩性和可用性相契合(捂脸笑),再看下Node.js 的缺点:

  1. 单进程,单线程,只支持单核CPU,不能充分的利用多核CPU服务器。一旦这个进程 down 了,那么整个 web 服务就 down 了
  2. 异步编程,callback 回调地狱

第一个缺点可以通过启动多个实例来实现CPU充分利用以及负载均衡,话说这不是 K8s 的原生功能吗。

第二个缺点更不是事儿,现在可以通过generatorpromise等来写同步代码,爽的不要不要的。

下面我们主要从 Docker 和 Node.js 出发聊一下高质量Node.js微服务的编写和部署:

  1. Node.js 异步流程控制:generator 与 promise
  2. Express、Koa 的异常处理
  3. 如何编写 Dockerfile
  4. 微服务部署及 DevOps 集成

1. Node.js 异步流程控制:Generator 与 Promise

Node.js 的设计初衷为了性能而异步,现在已经可以写同步的代码了,你造吗?

目前 Node.js 的LTS版本早就支持了Generator, Promise这两个特性,也有许多优秀的第三方库bluebird、q 这样的模块支持的也非常好,性能甚至比原生的还好,可以用 bluebird 替换Node.js 原生的 Promise:

global.Promise = require('bluebird')

blurbird 的性能是 V8 里内置的 Promise 3 倍左右(bluebird 的优化方式见https://github.com/petkaantonov/bluebird/wiki/Optimization-killers )。

1.1 ES2015 Generator

generator 就像一个取号机,你可以通过取一张票来向机器请求一

个号码。你接收了你的号码,但是机器不会自动为你提供下一个。

换句话说,取票机“暂停”直到有人请求另一个号码(next()),此时它才会向后运行。下面我们看一个简单的示例:

20160803172103

从上面的代码的输出可以看出:

  1. generator 函数的定义,是通过 function *(){} 实现的
  2. 对 generator 函数的调用返回的实际是一个遍历器,随后代码通过使用遍历器的 next() 方法来获得函数的输出
  3. 通过使用yield语句来中断 generator 函数的运行,并且可以返回一个中间结果
  4. 每次调用next()方法,generator 函数将执行到下一个yield语句或者是return语句。

下面我们就对上面代码的每次next调用进行一个详细的解释:

  1. 第1次调用next()方法的时候,函数执行到第一次循环的yield index++语句停了下来,并且返回了0这个value,随同value返回的done属性表明 generator 函数的运行还没有结束
  2. 第2次调用next()方法的时候,函数执行到第二循环的yield index++语句停了下来,并且返回了1这个value,随同value返回的done属性表明 generator 函数的运行还没有结束
  3. … …
  4. 第4次调用next()方法的时候,由于循环已经结束了,所以函数调用立即返回,done属性表明 generator 函数已经结束运行,valueundefined的,因为这次调用并没有执行任何语句

PS: 如果在 generator 函数内部需要调用另外一个 generator 函数,那么对目标函数的调用就需要使用yield*

1.2 ES2015 Promise

所谓 Promise,就是一个对象,用来传递异步操作的消息。它代表了某个未来才会知道结果的事件(通常是一个异步操作),并且这个事件提供统一的 API,可供进一步处理。

20160803172126

一个 Promise 一般有3种状态:

1.pending: 初始状态, 不是fulfilled,也不是rejected.

2.fulfilled: 操作成功完成.

3.rejected: 操作失败.

一个 Promise 的生命周期如下图:

20160803172137

下面我们看一段具体代码:

20160803172143

asyncFunction 这个函数会返回 Promise 对象, 对于这个 Promise 对象,我们调用它的then 方法来设置resolve后的回调函数,catch方法来设置发生错误时的回调函数。

该 Promise 对象会在setTimeout之后的16ms时被resolve, 这时then的回调函数会被调用,并输出’Async Hello world’ 。

在这种情况下catch的回调函数并不会被执行(因为 Promise 返回了resolve), 不过如果运行环境没有提供 setTimeout 函数的话,那么上面代码在执行中就会产生异常,在 catch 中设置的回调函数就会被执行。

20160803172151

小结

如果是编写一个 SDK 或 API,推荐使用传统的 callback 或者 Promise,不使用 generator 的原因是:

  • generator 的出现不是为了解决异步问题
  • 使用 generator 是会传染的,当你尝试yield一下的时候,它要求你也必须在一个 generator function 内

看来学习 Promise 是水到渠成的事情。

2. Express、Koa 的异常处理

20160803172201

一个友好的错误处理机制应该满足三个条件:

  1. 对于引发异常的用户,返回 500 页面
  2. 其他用户不受影响,可以正常访问
  3. 不影响整个进程的正常运行

下面我们就以这三个条件为原则,具体介绍下 Express、Koa 中的异常处理。

2.1 Express 异常处理

在 Express 中有一个内置的错误处理中间件,这个中间件会处理任何遇到的错误。

如果你在 Express 中传递了一个错误给next(),而没有自己定义的错误处理函数处理这个错误,这个错误就会被 Express 默认的错误处理函数捕获并处理,而且会把错误的堆栈信息返回到客户端,这样的错误处理是非常不友好的。

还好我没可以通过设置NODE_ENV环境变量为production,这样 Express 就会在生产环境模式下运行应用,生产环境模式下 Express 不会把错误的堆栈信息返回到客户端。

在 Express 项目中可以定义一个错误处理的中间件用来替换 Express 默认的错误处理函数:

20160803172209

在所有其他app.use()以及路由之后引入以上代码,可以满足以上三个友好错误处理条件,是一种非常友好的错误处理机制。

2.2 Koa 异常处理

我们以Koa 1.x为例,看代码:

20160803172217

把上面的代码放在所有app.use()函数前面,这样基本上所有的同步错误均会被try{} catch(err){} 捕获到了,具体原理大家可以了解下 Koa 中间件的机制。

2.3 未捕获的异常 uncaughtException

上面的两种异常处理方法,只能捕获同步错误,而异步代码产生的错误才是致命的,uncaughtException错误会导致当前的所有用户连接都被中断,甚至不能返回一个正常的HTTP 错误码,用户只能等到浏览器超时才能看到一个no data received错误。

这是一种非常野蛮粗暴的异常处理机制,任何线上服务都不应该因为uncaughtException 导致服务器崩溃。

在Node.js 我们可以通过以下代码捕获uncaughtException错误:

20160803172225

捕获uncaughtException后,Node.js 的进程就不会退出,但是当 Node.js 抛出uncaughtException 异常时就会丢失当前环境的堆栈,导致 Node.js 不能正常进行内存回收。

也就是说,每一次、uncaughtException 都有可能导致内存泄露。既然如此,退而求其次,我们可以在满足前两个条件的情况下退出进程以便重启服务。

当然还可以利用domain模块做更细致的异常处理,这里就不做介绍了。

3. 如何编写 Dockerfile

3.1 基础镜像选择

我们先选用 Node.js 官方推荐的node:argon官方LTS版本最新镜像,镜像大小为656.9 MB(解压后大小,下文提到的镜像大小没有特殊说明的均指解压后的大小)

我们事先写好了两个文件package.json, app.js:

20160803172238

下面开始编写 Dockerfile,由于直接从 Dockerhub 拉取镜像速度较慢,我们选用时速云的docker官方镜像 docker_library/node(https://hub.tenxcloud.com/repos/docker_library/node),这些官方镜像都是与 Dockerhub实时同步的:

20160803172247

执行以下命令进行构建:

docker build -t zhangpc/docker_web_app:argon .

最终得到的镜像大小是660.3 MB,体积略大,Docker 容器的优势是轻量和可移植,所以承载它的操作系统即基础镜像也应该迎合这个特性,于是我想到了Alpine Linux,一个面向安全的,轻量的 Linux 发行版,基于 musllibcbusybox

下面我们使用alpine:edge作为基础镜像,镜像大小为4.799 MB

20160803172304

执行以下命令进行构建:

docker build -t zhangpc/docker_web_app:alpine .

最终得到的镜像大小是31.51 MB,足足缩小了20倍,运行两个镜像均测试通过。

3.2 还有优化的空间吗?

首先,大小上还是可以优化的,我们知道 Dockerfile 的每条指令都会将结果提交为新的镜像,下一条指令将会基于上一步指令的镜像的基础上构建。

所以如果我们要想清除构建过程中产生的缓存,就得保证产生缓存的命令和清除缓存的命令在同一条 Dockerfile 指令中,因此修改 Dockerfile 如下:

20160803172314

执行以下命令进行构建:

docker build -t zhangpc/docker_web_app:alpine .

最终得到的镜像大小是21.47 MB,缩小了10M。

其次,我们发现在构建过程中有一些依赖是基本不变的,例如安装 Node.js 以及项目依赖,我们可以把这些不变的依赖集成在基础镜像中,这样可以大幅提升构建速度,基本上是秒级构建。

当然也可以把这些基本不变的指令集中在 Dockerfile 的前面部分,并保持前面部分不变,这样就可以利用缓存提升构建速度。

最后,如果使用了 Express 框架,在构建生产环境镜像时可以设置NODE_ENV环境变量为production,可以大幅提升应用的性能。

Q&A:

1. 自动构建对程序的要求是什么?有dockerfile就可以了吗?

答:自动构建对程序没有要求,只要有Dockerfile就行。

2. 一个容器只放一个服务,这个成本有点高吧?

答:结合 stack 编排,成本还是可控的,一个容器对应一个服务比较符合微服务的理念

3. node是单进程的 容器中的node也是单进程部署的吗?或者说容器的cpu需不需要配置多核?

答:容器的CPU一般是按时间片划分的,容器中的 node 一般都是单进程部署,结合 k8s 可以建立多个实例,实现负载均衡。

4.以前没有容器 node进程挂了 操作系统关心的是进程 现在容器中跑node k8s去关心容器挂不挂 容器中的node如果挂了 就是容器去把node再重启吗?

答:如果是单机部署的话 可以用 –restart=always 命令实现容器自动重启; k8s可以支持对容器内服务定义探针,根据规则可以对服务进行重启或者从前端路由摘除

5.docker daemon挂了的话那也没办法了?

答:docker daemon挂了的话,可以通过节点agent自动恢复docker daemon,或者自动把服务迁移到其他正常服务节点。

OpenStack与Rancher融合的新玩法

刀客info阅读(2202)评论(0)

前段时间的OpenStack China Days大会上, Rancher CEO 梁胜博士特意分享一个关于 OpenStack与Rancher结合的议题,今天我就对此话题稍微展开讲一下「玩转Rancher与OpenStack」。

OpenStack是开源Iaas云的事实标准,功能大而全,除了能管理虚机同时也能管理容器,OpenStack项目中的Magnum、Kuryr、Kolla、Murano、Nova-docker等都是与容器场景很不错的结合点;而Rancher不同,Rancher是为容器而生,只是顺道做了一些VM的管理工作,与OpenStack不同的是针对VM的管理,Rancher并不是对标AWS,Rancher相对来说要精简很多,当然Rancher对容器的掌控要远强于OpenStack。本次分享给大家带来Rancher与OpenStack能够融合使用的一些玩法。
 
我会分为几个场景来讲解一下,这样对OpenStack不是太了解的朋友而言可以更直观一些。
场景一
使用OpenStack的VM来提供Rancher Host
这种结合是最先能想到的,可以说是顺理成章的需求。Rancher添加以OpenStack的VM为Host资源,我觉得主要有两种方式:custom host方式和docker-machine driver方式。
 
第一种方式,我们都知道Rancher在Add Host时可以用在目标主机执行一条shell的方式来添加host,而OpenStack在创建VM的时候可以在注入一个执行脚本,这个脚本会在VM创建完毕后在VM的OS内部执行,所以我们就可以利用这些特性:
20160801184648
这样VM在创建完毕后会自动成为Rancher的一个Host资源,这里一点小建议就是VM的镜像最好是自带Docker,这样可以注入的脚本中省去安装Docker Engine的过程,可以大幅提升速度。
 
第二种方式就是利用docker-machine driver,而且openstack driver也是docker-machine的官方驱动之一,不过这个driver的参数确实太多,易用性上差很多。除了使用openstack driver,其实我们完全可以使用generic driver,openstack对主机秘钥有很好的管理,所以我们完全可以使用openstack和Rancher的api,利用generic driver来简化openstack driver的复杂性,当然前提是VM的镜像最好还是自带Docker Engine:
20160801184702
说完Host资源,我们看看存储方面。OpenStack对存储的支持区分的比较细,对象存储、块存储、文件系统都有各自的项目来支持,如swift、cinder、manila等,存储系统对接的不仅仅是Rancher,Docker Engine本身也要处理好一些优化细节。
 
对于对象存储Swift,可以作为Docker registry的backend存储,我们可以registry服务部署到VM上,然后镜像的存储放在swift上。另外,目前convoy backup可以备份到AWS S3上,对于国内用户来说比较麻烦,实际上完全可以备份到swift上,当然需要在convoy上添加这个驱动的支持,或者可以把swift配置成S3的接口,这样也可以和convoy结合起来使用。
 
对于块存储Cinder,更多的结合场景在Docker Engine上,Docker有很多种storage driver,也就是我们熟知的rootfs可以有多种形式,常用的有aufs、devicemapper、overlayfs等,通常VM的flavor根磁盘都比较小,所以我们需要用cinder创建一块盘来挂载到/var/lib/docker上或者直接指定这块盘为devicemapper对应的设备。
 
对于文件系统manila,manila本身能够创建一个对外的NFS服务,也可以创建一个glusterfs集群服务,这样也可以和convoy能够有很好的集成。目前相对对象存储和块存储 ,Manila的成熟度还不是太高。
 
计算存储之后便是网络,我们都知道Rancher中Cattle的网络使用ipsec,ipsec本身就是一种overlay技术,而OpenStack的Neutron很多也会使用GRE/VXLAN之类的overlay网络,这样容器之间的网络通信就变成overlay嵌套overlay,性能上必然打打折扣,所以OpenStack与Rancher结合使用时,强烈建议Neutron使用vlan网络。
 
当然可能由于各种环境因素必须在neutron中使用overlay,此时VM的网卡的mtu需要设置成1400或者1450,那么同样需要对Docker容器的mtu做设置,否则容器内一些应用层的协议(HTTP)将会无法正常使用。DOCKER_OPTS=”$DOCKER_OPTS –mtu=1400″
20160801184710
场景二
构建容器与虚机的混合网络
上一场景所提到的嵌套overlay的问题,是在OpenStack中使用Docker集群的普遍问题,如下图所描述:
20160801184718
这种性能的损耗是巨大的,繁荣的OpenStack社区孵化的一个子项目Kuryr就是解决这个需求场景的。Kuryr本质上就是把容器内namespace的port与neutron port绑定,这个neutron port根据不同neutron-plugin-agent略有不同:
20160801184724
最终可以实现容器和容器之间组网,容器和虚机之间组网等模式,Neutron会作为IPAM存在,我们可以随意地定义网络:
20160801184731
这样我们可以把很多Neutron的特性带入到容器网络中,诸如安全组、浮动ip、Qos、Lbaas、Fwaas等等。
 
目前Kuryr只支持CNM(libnetwork),在OpenStack N版的release周期中会放出对CNI(主要是Kubernetes)的支持,届时Rancher 1.2也将会支持CNI,这样两者可以有一个很好的结合,后期可长期关注这个方向。
场景三
使用Murano来快速部署Rancher
Murano是OpenStack的应用市场,将应用基于Murano约定的打包标准打包后放入应用市场,用户就可以在OpenStack中快速部署该应用,这个理念非常类似Rancher的Catalog,只不过它是基于VM的。如果需要在OpenStack中快速部署一套简单的Rancher环境,那么使用Murano是个不错的选择。
20160801184742
我们可以在OpenStack Horizon上用拖拖拽拽的方式创建Rancher环境:
20160801184749
最终通过Murano的编排,创建了Rancher服务环境 ,并自动生成部署图:
20160801184755
这种主要是方便、快速创建一套Rancher环境,我目前只是做了个demo,如果更完善还需要把Rancher的HA模式放进来。
场景四
利用Rancher Catalog快速部署OpenStack
玩过OpenStack的朋友都深知其复杂性,对于一个新手来说,刚上来部署OpenStack来个三天三夜不是什么新鲜事。OpenStack的快速部署需求引出了一些开源项目和商用产品,诸如openstack-ansible、kolla、fuel、magicstack等等。
在这其中kolla的理念比较特殊,它立志于以容器方式部署openstack服务,从而能够实现快速部署甚至滚动升级降级等特性。
 
Rancher本身就是管理容器的利器,完全可以把openstack当做Catalog中的一个应用来部署,这个服务Rancher也已经开始支持https://github.com/rancher/openstack-catalog,目前实现也比较初级不支持controller的HA,可以将其加到Catalog里面体验一下。
 
有几点注意事项:
1. Host必须开启KVM,可以使用这个命令查看一下 egrep -c ‘(vmx|svm)’ /proc/cpuinfo,返回是0说明没开启,各种OS开启KVM可Google之。
2. 计算节点的libvirtd进程不能在运行在base OS中。
3. 各个节点需要两块网卡,一块用于API通信,一块用于Neutron网络,网络需要提前配置好。
4. 部署的过程需要拉取很多镜像,需要耐心的等待。
Q & A
Q
Rancher现在只有IPSec 这种网络方案吗?性能会有问题吗?
A
Rancher-net组件目前只支持ipsec。ipsec网络本身是overlay网络,同时还有密钥加密,所以性能上会差一点。不过在Rancher 1.2的发布计划中,会支持CNI,这样我们可以把calico weave等网络组件集成进来,用户可以根据自己的实际业务场景 选择不同的网络组件,Rancher对CNI的支持已经开始开发了。
Q
Kuryr现在可以对接Rancher吗?
A
Kuryr 现在暂时不可以,Kuryr目前也是在支持CNI的迭代中,需要等Rancher和Kuryr都完毕后,两面就可以打通了。Kuryr之前的计划应该是在OpenStack N版会添加CNI的支持,差不多就是今年10月份左右。
Q
【当然可能由于各种环境因素必须在Neutron中使用overlay,此时VM的网卡的mtu需要设置成1400或者1450,那么同样需要对docker容器的mtu做设置,否则容器内一些应用层的协议(HTTP)将会无法正常使用。】关于这一点,是明确要求1400或1450还是说可以小于1400即可?因为强制只能是这两个值应该有点特别原因吧?
A
特别的原因就是GRE/VXLAN的包头太大了,设置mtu拆包的时候不能用默认的1500 否则数据包就是无法识别了。1400/1450 是可以计算出来的,有一个公式可以计算,小于这个值也可以 但是这样传输效率就太低。

数人云总架构师解读Mesos1.0.0

刀客info阅读(1212)评论(0)

2016年7月27号 Apache 社区发布了 Apache Mesos 1.0.0, 这是 Apache Mesos 的一个里程碑事件。相较于前面的版本, 1.0.0首先是改进了与 docker 的集成方式,弃用了 docker daemon;其次,新版本大力推进解决了接口规范化问题,新的 HTTP API 使得开发者能够更容易的开发 Mesos 框架;最后, 为了更好的满足企业用户的多租户,安全,审计等需求,新版本提供了更细粒度的授权验证机制。下面我就详细谈一下自己对新版本重要功能的理解。

HTTP API

1.0.0 通过统一的基于 RPC 的 HTTP API 对以前的两种不同用途的接口--Framework SDK 和 REST API,进行了整合, 这个是最近几个月 Mesos 社区在大力推进了的一个事情。

借助这次重构,社区首先是规范了 Mesos 的接口,为 API 标注了版本信息并且规范了发布流程,从而避免了以前的版本黑盒导致的不兼容问题,减少 breaking news 和客户生产环境的 surprise。

其次,以前的局限于开发语言的 Framework SDK ,功能有限的 REST API 都极大限制了第三方开发者的手脚,为开发基于 Mesos 的框架带了额外的困难,另外客户端和服务器的双向通信也增加了程序的维护成本和局限了程序的部署方式,新版本从软件工程的角度,解耦了上述双向通信问题。

最后,Mesos 也开始支持时间流。上述种种,我们可以看出 Mesos 社区正在以更开放的态度来便利社区开发者,为各种框架提供更好的对接。

一致的容器化技术

Mesos 1.0.0 的 agent 无需安装 docker 程序也可以运行 docker 容器了,或者说,Mesos 可以自己解析 docker 镜像来启动容器了。 腹黑的说,继 RKT 之后,Mesos 也抛弃了 docker daemon。我们知道,虽然在 docker 1.11 之后,containerd 的引入已经解决了 docker daemon 重启带来的容器重启问题,但是宿主机的 init 系统仍然无法直接跟踪进程的生命周期。同时,这也可以看出 Mesos 社区对 docker 技术的把控能力。

网络

对容器网络标准 CNI 的支持,CNI 标准是多家网络厂商参与制定的容器网络标准,Mesos 兼容了 CNI 标准,相当于间接的支持了 VxLAN, DC/OS overlay, Calico, Weave, Flannel 等多种网络技术。这是继一容器一 IP 功能后,Mesos 的又一重要的网络功能。

安全

多租户,安全,审计等一直是企业用户对平台软件的基本诉求,Mesos 在 1.0.0 中通过提供更细粒度的授权验证机制对此作出了响应。首先,在 1.0.0 中,Mesos 的所有敏感数据入口都是经过 SSL/TLS 加密的;其次,Mesos 管理员现在可以通过配置 ACLs 来限制用户只能在 WebUI/API 看到自己的任务了,而这就是企业用户的 must-have 要求;最后,Mesos 也提供了完善的 authorizer 接口,企业用户可以通过该接口添加自己特有的安全策略。

GPU 支持

现在你可以通过 Mesos 来跑 TensorFlow 的任务[https://www.youtube.com/watch?v=giJ4GXFoeuA&list=PL903xBaKIoaWc0hnSVyAAGAJUPxq2MCd0]了, 与管理 cpu、内存资源类似, Mesos 现在也将 GPU 资源纳入帐下。参照 nvidia-docker 的实现, Mesos 现在可以无缝的运行 GPU docker 容器了。同时, Spark, Marathon 和 Aurora 社区也加入了在 Mesos 上调度GPU的行列。

社区合作

最后,朋友多了路好走。 Mesos 社区也在加大与 IBM , Microsoft 和 Nvidia 等厂商的技术合作。其中, IBM 已经成为紧随 Mesosphere 之后的第二大 Mesos 代码贡献厂商,未来,IBM 会在 Mesos 的 optimistic offers,  资源分配优化和兼容 POWER 平台方面投入力量。 同时, Mesos 也推出了 Mesos 运行在 Microsoft 上的试验功能。

Docker 的步伐:DevOps 与 OS 化

刀客info阅读(1555)评论(0)

过去十年云计算的发展,在 IT 领域为共享经济提供了新的机遇;而过去五年移动互联网的兴起,更是在诸多方面给 IT 架构提出了新的挑战。新的挑战,新的机遇,同时也意味着新的活力。一时间,Docker微服务DevOps 以及精益研发等新词汇,在较短的时间内,即充斥着整个 IT 行业。基础设施领域,巨头的垄断,以及技术壁垒的存在,往往会限制入局者,也让后来者望而却步。面对业务需求的不断演进,软件提供商的应对能力如何,在机遇面前同样接受考验。

往往是时代的领航者,首先嗅探到历史变革前的酝酿。我们大致看到:对的时机,新的思想总显得有些俏皮,同时还不失冒进思想背后,我们也总能发现:有些公司进行着那些惊为天人的尝试,他们激进,他们开拓,他们从 0 到 1 。Docker 这家公司在这其中不可谓是浓墨重彩的一笔。

目前为止,历史给了 Docker 三年多的时间。这三年中,Docker 自始至终将 Build ,  Ship ,  Run 当作公司的宗旨,也就是帮助用户完成任意应用的构建、发布与运行。

20160727111849

通过总结 Docker 的三年,我们不难发现 Docker 的步伐:

  • 第一年,专注软件构建,对接构建下游,营造镜像生态
  • 第二年,服务容器管理,发布调度平台,打造交付流程
  • 第三年,整合企业资源,完善平台功能,着手应用编排

如今,在这第四年过半之际,再去解读 Docker,我们会发现,Docker 的发展似乎除了重视应用的 ” Build ,  Ship ,  Run ” 之外,另外还在两个领域的努力有点“欲盖弥彰”:

  • 推进 DevOps 进程
  • 管理能力迈向 OS 化
Docker 推进 DevOps
DevOps 在 IT 领域是一种强调开发团队、运维团队以及其他团队之间增强协作与沟通,以达到软件产品快速成熟以及安全可控的文化。从 Docker 的宗旨来看,DevOps 的理念似乎非常匹配,Docker 完全有能力来加速、保障软件的生命周期。而从这几年的行业发展来看,Docker 作为一款工具,的确在帮助企业践行 DevOps 理念,同时也借助这款工具的打磨,通过可视价值在更大的群体中推广 DevOps 。

20160727111907

如果说依旧以软件构建、CI / CD 等来介绍 Docker 带来的 DevOps 价值,那未免有些老生常谈。如果关注 Docker 最新动态,你不会错过 Docker 原生集成编排的爆炸性新闻。当时 DockerCon 2016 发布此消息之后,坊间关于编排之争、容器生态分裂等传言与猜测甚嚣尘上。而在我看来,编排只是一种形式, Docker 所期望的 DevOps 程度远不止如此,目前的动作实际上也不止于此。

原生集成编排

Docker 推出 Swarmkit,原生集成编排能力的新闻,我相信对其他以容器编排为目标的分布式平台(比如 Kubernetes,Mesos+Marathon 等)而言,是一个不太友好的消息。一个工具,一个厂商,凭借在容器生态中拥有大量的用户群体,釜底抽薪,拦截了北向生态。乍一看,的确如此,但如果从 DevOps 的角度重新看待这个问题,也许大家会有不一样的收获。

DevOps 是一种新的文化理念,在其驱使之下,践行 DevOps 带来价值的大与小,世人一般很难衡量,往往只是与现有固化流程作简单对比。PaaS 领域,人们习惯于将 DevOps 联系进来,而且从效果来看,PaaS 的存在的确大大简化了传统运维人员对于应用发布后的管理,因此类似于 Kubernetes 等平台也确确实实受到传统运维人员的追捧,释放运维似乎看到曙光。

然而,回到 DevOps,这一词的存在,受益者可绝不止是 “ 运维人员 ” 。对于开发人员而言,同样存在价值。或许有人言:那岂不是意味着开发人员会承担更多的活,去涉及运维的脏活、苦活、累活呢?如果是传统的 IT 架构,缺乏足够的工具辅佐,恐怕是如此,或者 DevOps 寸步难行。

而如今,在 Docker 的世界中,很多事情似乎变的足够简单。在解决了网络、存储、安全等问题之后,Docker 的 Swarmkit 帮助 Docker 大大降低了用户使用容器,践行 DevOps 的门槛。至今为止,大部分企业内部的软件交付,往往会涉及三个部门:开发、测试、运维,三者缺一不可。Docker 的思路比想象中的要简单很多,力求在工具层面做到最简约,仅仅通过 Docker 一款工具就可以完成开发、测试、运维等绝大部分工作。如果仅仅在开发者占用的仅有资源中,Docker 即可以提供完备的 “ End-to-End ” 的工具链,那工程师完全可以轻松胜任 DevOps 角色。开发工程师,在开发过程中融入运维的理念,借助 Docker 工具的威力,走通软件生命周期的全流程。Docker 带来的开发部署等环节的环境一致性、编排功能的完备性,势必大大降低团队内部的沟通成本和资源开销。我想企业内部在做IT决策时,如此明显的价值导向不可能视而不见。

DevOps 自始至终都没有局限在 PaaS 的运行时,相比运维庞大的 PaaS 平台来解放应用运维的能力,是否会存在本末倒置,一切都还在未可知,至少 Docker 这种轻量级,最便利的一体化方式给 DevOps 提供了一种新的思路。

开发驱动监控

Docker 以轻巧的方式,实现了用户对于编排的需求。表象似乎很光鲜,但是我们不妨对目前普遍的编排进一步的思考。是否会发现,类似于 Kubernetes 与 Swarmkit 的编排着重于应用的运行时管理,如果仅限于运行时,仅限于应用运维,缺乏开发端源头的输入,开发与运维的鸿沟依然赫然在目,一分不少,丝毫无改观。

传统的 PaaS 平台,比如 Cloud Foundry,OpenShift,可以基本做到管理应用的运行。然而,应用的生命周期往往比这更复杂,随后的监控、协调、调度、故障恢复等都是需要克服的难题。而这些在传统企业内部,毫无疑问都是运维的差事,出了问题还毫无避免的追溯开发人员。如果此时,在拥有传统 PaaS 的背景下,一款软件的生命周期中,可以更多的受 DevOps 文化影响,那可以大大减少很多成本。举一个简单的例子,在传统 PaaS 以及容器编排平台中,对于应用的监控往往很难做到放之四海皆准。对于一些应用而言,平台通用的监控不是粒度太大,犹如隔靴搔痒,就是提供的细粒度监控并不针对用户的痛点,显得南辕北辙。运维人员在设计监控的时候,根本无法通过通用的方式完成应用的 “ 个性化 ” 需求,因此,权衡诞生,取舍难免。

如果关注最新的 Docker 1.12,细心的人可能会发现:

Dockerfile 开始支持新命令 HEALTHCHECK,完成用户指定的应用健康检查

Docker 的此举,看似不经意,实则平地见惊雷,一举弥合了开发与运维的鸿沟,至少在应用监控领域。Docker 大大释放了运维人员的压力,但是企业切入 Docker 的第一步还是 Docker 化,也就是 Dockerfile,这一环节自然是开发者的范畴。另外,对于应用的个性化监控,我想没人比应用的开发者更清楚,如果由应用开发者来承担,来完成这部分的定义,完全是件皆大欢喜的事。从此,开发环节即完成应用自定义监控的定义, 通过 Docker 提供的统一的架构完成监控,运维环节的监控将不再那么捉襟见肘。

可以说,Docker 1.12 开始,它为应用监控提供了新的契机,弥合开发与运维的鸿沟,打通了两者的任督二脉,这往往是传统的 PaaS 平台,容器编排平台无法企及的。

Docker 迈向 OS 化

Kubernetes 、Mesos 等平台诞生之后,回顾过去的一到两年,仿佛整个生态的潜意识都有着一个潜意识:容器生态分为两层,容器引擎的 Docker 作为管理工具,作为底层,单纯服务于容器;编排平台的 Kubernetes 或者 Mesos,作为上层,满足应用编排的各种需求。笔者也一度认为 Docker 势必将往上层走,卧榻之侧,岂容他人鼾睡。然而,Docker 的举动却令人大吃一惊,采取的策略则是:Docker 迈向 OS 化。

自从 libnetwork 诞生,Docker 似乎就传递着一种信息:无心借力第三方工具,借助内核借力打力。

Docker 风靡至今,面对传统的资源管理方式,至今仍有未解之谜。如果说,Docker 暂且借助内核的 VxLan 能力,缓解或解决了 Docker 容器世界的网络难题,那么企业内部架构中仍有问题存在,比如存储,比如负载均衡等。问题固然要解决,不过反观近年来企业应用的发展史,在选择底层软硬基础设施时,往往较信任更为基础的操作系统(Operating System,OS),在与上层云平台的磨合过程中,多多少少存在水土不服。因此,Docker 管理能力迈向 OS 化,也不难理解。容器未来的方向很有可能打破传统 IaaS 与 PaaS 的界限,回到广义云 OS 层面的变革中。

全局存储

对于应用而言,数据的重要性不言而喻。计算与存储分离,一直是 Docker 最希望的数据管理方式,而对于存储的统一化管理,Docker 一直没有给出令人信服的解决方案,反而是生态中类似于 ClusterHQ,HedVig 等公司一致在该领域深耕。不过,这也不能苛责 Docker,这毕竟不是 Docker 的强项与主营业务。

Docker 不可能封闭容器生态的存储市场,这方面的努力,我们从 Docker 抽象存储概念即可看出( Docker 诞生,只存在容器和镜像这两个一级概念,而随着时间的发展,Docker 另外抽象出存储卷( Volume )以及网络,作为一级概念,并行管理 )。

经历了过去 3 年多单机化的存储卷,如今 Docker 1.12 推出全局的存储卷,原生支持集群环境中的数据卷共享。在加上 DockerCon 2016 上,Docker 官方演示借助 NFS,集群环境中管理分布式数据。容器生态有理由推测,Docker 在存储领域并非视而不见,而是非常有可能借助操作系统 OS 的能力,切入存储生态。

IPVS 负载均衡

如今,大多数企业级的应用,不再是仅拥有单个实例。多实例的现状常常可以避免很多问题,比如单点问题,负载的均衡问题等。而 Docker 的世界中,容器的扩展一直以来不是一个新话题。对于扩展出来的应用容器,服务的注册以及发现由谁来完成,一直没有一个定论。而 Kubernetes 等平台则是为此专门引入一个平台路由组件完成这部分工作。由于 Docker 的网络模式与平台路由组件在协作时,或多或少会存在水土不服,性能等方面的损耗,因此很难达到 ” 1+1>2 ” 的效果。

新版本的 Docker 1.12,编排应用时,可以直接使用 Linux IPVS 完成服务的注册以及负载均衡。或许,这一举措直接带来的好处将是:

  • 借助内核能力,无需额外配置、部署及管理
  • 大幅提高负载均衡的性能
  • 原生支持多种传输协议的负载均衡能力( TCP,SCTP, UDP 等 )

大道至简,如果诸如 Linux 内核等底层技术栈,本身可以提供负载均衡的管理能力,运维人员没有理由再去额外安装一个负载均衡模块,昂贵的配置、管理、运营成本是团队决策者不得不考虑的点。另外,比起 Nginx / HAProxy , IPVS 还在多个层面存在优势:比如 UDP 的支持,多样的负载均衡策略,以及健康检查等。

总结

全新的领域,用“探索”来形容现在的 Docker,我认为最合适不过。着眼全球的软件交付,Docker 对于 DevOps 理念的贡献,可谓不可小觑。而面对云计算领域的基础设施以及平台架构,Docker 的思路也许会更倾向于 OS 化,逐渐走向 Cloud OS 。然而,Docker 作为目前全球最炙手可热的创业公司,百般眼光以及多样的揣测,都会聚集于这条不乏趣味的鲸鱼身上。未来如何,我们拭目以待。