回顾一下第1章描述的云计算平台层次结构,IaaS平台接管了所有的资源虚拟化工作,通过软件定义的方式来为云租户提供虚拟的计算、网络和存储资源。PaaS平台接管了所有的运行时环境和应用支撑工作,云平台的租户因此可以申请配额内的计算单元而不是虚拟机资源来运行自己的服务。当前不少经典PaaS平台已经采用容器作为计算单元,那些仍然依靠虚拟机提供应用运行时支持的PaaS平台在本书中将被称为IaaS+平台。云平台调度这些计算单元用以部署和运行租户的代码制品。在这两层的基础上,用户部署的应用和服务通过API响应的方式组成一系列集合服务于最终用户,这就是所谓SaaS 。上述过程其实描述了一个清晰可见的层次结构,如图5-1所示。

① 描述见http://www.programmableweb.com/news/new-enterprise-big-data-mobile-and-saas-api-economy/analysis/2013/09/25。

在经典云平台层次体系里,应用实例运行在PaaS平台所提供的容器环境中,容器在虚拟机基础上完成了第二层次基础设施资源的划分;容器封装了应用正常运行所需的运行时环境和系统依赖;同时,容器也成为了租户调度应用、构建应用多实例集群的最直接手段。与IaaS层不同,通常在PaaS层可以采用更贴近应用的资源调度策略。可是,目前遵循这个体系结构构建的经典PaaS平台中存在一个有趣的现象:租户从始至终都无法感受到容器的存在!

相比于基于虚拟机提供运行时支持的IaaS+平台(比如AWS),经典PaaS平台的租户甚至都不能进入自己的计算单元(容器)中,这类PaaS平台就如同一个黑盒,所有“扔”进去的应用就完全脱离了租户的控制,进入了完全被托管的状态。诚然,如果一切都有条不紊地运作,该模式可谓完美,因为“所有用户都是最懒的”这个假设总是成立,而残酷的现实却是:“错误总是会发生在任何意想不到角落里。”

enter image description here

举个简单的例子,一旦应用运行过程中有错误发生,一些经典PaaS平台首先会删除故障实例,然后立即在其他位置恢复这个实例和容器。这个过程中,甚至平台默认没有保存现场的过程。浙江大学SEL实验室云计算团队曾在Cloud Foundry中增加了从websocket日志组件收集容器中的应用日志到ElasticSearch的机制,通过该机制在一定程度上能给用户提供方便的日志信息诊断处理,但对于日志中无法体现的异常还是无能为力,更谈不上调试代码和保存环境上下文了。这样的先天缺陷,也是后来云计算领域会出现大量“云DevOps工具”,提供一个类似“白盒PaaS”解决方案的重要原因之一。

在一些经典PaaS平台中,出于安全、封装等各个方面的考虑,容器总是被故意隐藏在整个云平台的运行过程当中(如图5-1所示),因此开发和运维人员失去了往日对应用及其运行时环境的完全掌控能力,试图重新获得控制权所做的努力往往要求助于过分晦涩的交互方式和hack般的自定义过程。再加上经典PaaS平台通常在应用架构选择、支持的软件环境服务等方面有较强限制。因此在生产环境下,部分企业和个人开发者会倾向于放弃PaaS层,直接依靠运维力量来分配和调度虚拟机,靠大量自动化工具来维护和支撑所有运行时、应用环境配置、服务依赖、操作系统管理等。这时,传统云平台分层结构就会进化成如图5-2所示的状态,即IaaS+云平台。

本书认为,这种“返璞归真”的做法是一种值得一试的云计算运维方法,尤其是在大部分IaaS都能够提供标准而丰富的API的今天。高效便捷的虚拟机DevOps工具在很大程度上弥补了IaaS平台脱离应用的缺陷;以虚拟机镜像为基础可以保证生产环境、测试环境、开发环境上的严格一致;IaaS提供商还在不断推出关系型数据库、NoSQL、日志、搜索、对象存储等构建在虚拟机上的可对外提供服务的镜像。事实上,基于IaaS的云生态环境已经具有相当高的成熟度。

当然,如果没有Docker的话。

enter image description here

当前,经典PaaS平台和IaaS加DevOps工具组成的IaaS+平台还在分庭抗礼,但随着容器技术逐渐步入视野,云平台建设已经有了新的思路。

相比IaaS+平台,Docker容器启停速度比虚拟机提高了一个量级,而在资源利用率上容器独有的高密度部署能力也非普通IaaS提供商所能提供的。更有吸引力的是,大小仅几十到几百MB的Docker镜像就完整封装了Web容器、运行配置、启动命令、服务hook和所需环境变量,提供了一种全新的应用分发方式,给应用开发者带来了弥足珍贵的“全环境一致性”保证。相比之下,动辄GB级的虚拟机镜像在应用部署和分发上就很难再有竞争力了。

相比经典PaaS平台,Docker的出现使得构造一个对开发和运维人员更加开放的容器PaaS云成为可能,基于容器镜像的应用发布流程不仅能覆盖整个应用生命周期,还减少了经典PaaS平台对应用架构、支持的软件环境服务等方面的诸多限制,将更多控制力交还给开发和运维人员。这种“降维攻击”把曾经引起不少争论的话题再次摆在了开发者面前:PaaS应该以何种形态存在?

本书无意给上述问题寻找一个完美答案,更希望能与读者一起研究和探索基于容器的云平台究竟以什么形态出现才更合理。因此,本书为读者介绍多种类型的容器云平台。它们中一类更偏向经典PaaS平台,提供各类“一键xx”服务,它们给予用户最大的方便和更高度的自动化,也因此附加了对应用架构和开发运维自由度限制;另一类则给用户最大的开发运维自由度,但自动化程度较低,使用相对复杂。也许到阅读完第二部分内容后,读者就能找到怎样的容器云平台才是最适合自己的。在本书中将不会再过分强调所谓IaaS、PaaS、SaaS三层云计算划分方式,更多的是将这些概念视为经典技术作为容器云的对照。

值得一提的是,不论是采用哪种形态的云平台,随着Docker等面向开发者的容器大行其道,本书下面将要着重讨论的云平台都已经变成了图5-3所示的结构。

在Docker等容器技术很有成为未来应用发布事实标准的当下,必须指出本书进行讨论的一个基本立足点:由于当前容器在内核完整性、安全性和隔离性上的固有缺陷,目前在大部分场景下我们必然需要虚拟机、虚拟网络、虚拟存储的支持。

enter image description here

本书接下来讨论的所有以容器为核心的云平台都不会锁定在某种具体IaaS或者PaaS上面,将始终坚持容器云平台应无差别地工作在物理机上或者虚拟机上这样朴素的思想,并以此为基础剖析各类容器云的原理与本质。这或许不太容易,比如Kubernetes天生就是为GCE定制的,而其他大部分容器管理平台也都以AWS和DigitalOcean作为默认的下层资源依赖。本书在后续的论述中将尽可能屏蔽掉这类外部因素,以中立的技术态度贯穿本书的始终。

评论

本文目前还没有评论……

我要评论

需要登录后才能发言
登录未成功,请修改提交。