华为向 Mesos 社区贡献 Cloud Foundry-Mesos 框架
华为向 Mesos 社区贡献 Cloud Foundry-Mesos 框架：可将开源CloudFoundry运行在Mesosphere DCOS上近日华为宣布将其开发的Cloud Foundry-Mesos框架贡献给Mesos社区，能够实现在Mesosphere
DCOS上部署与运行云原生应用。这个新框架能够将流行的PaaS框架Cloud
Foundry集成到Mesos之上，使得用户可以直接在Mesos上通过Cloud Foundry部署云应用，成为除了Mesos自带应用框架Marathon之外的另一选择。此开源项目目前托管在Github上，地址为：。Cloud
Foundry-Mesos框架由华为与Mesosphere的工程师合作完成，能够为应用提供安全可靠的、可伸缩、可扩展的云端运行环境，并且应用能够享用Cloud Foundry生态圈内各类丰富的服务资源。企业能够通过Cloud Foundry开发云应用，并通过Cloud Foundry-Mesos将应用部署到DCOS上，使应用能够与DCOS上安装的其他服务及应用框架共享资源，实现资源利用率最大化，能够大幅降低企业数据中心运营成本。DCOS能够运行在虚拟和物理环境上，能够支持Linux（以及很快支持Windows），并可适用于私有云、公有云及混合云环境。华为PaaS平台首席架构师熊英博士解释说，CloudFoundry-Mesos框架属于华为正在持续研发中的PaaS平台产品。华为PaaS解决方案使用了大量先进的开源及自研技术，支持多种业界流行的应用编排与调度框架，包括CloudFoundry、Kubernetes等，旨在帮助客户能够在复杂的、大规模的云环境下快速、自动化地部署及管理企业应用。Mesos作为统一的资源管理平台，提供了多种灵活的应用部署和管理方式，具备良好的平台扩展性，能够显著提升资源利用率，因此在华为PaaS产品的战略目标中具有重要意义。此次与Mesosphere DCOS的合作，能够帮助企业客户快速开发、部署云应用到DCOS上，并与其他企业已有数据中心服务如Hadoop、Spark等共享数据中心资源，能够较好的优化运营成本。Mesosphere联合创始人及CEO-Florian Leibert解释说，Mesosphere很高兴能与华为合作完成这一重要工作，将Cloud Foundry这一主流的PaaS框架纳入到DCOS及Mesos生态中，能够帮助客户优化IT系统，加速企业应用及产品的研发流程，提升运维效率，以应对21世纪软件为中心的业务模式所带来的挑战。
CloudFoundry-Mesos 的详细介绍：
CloudFoundry-Mesos 的下载地址：
转载请注明：文章转载自 开源中国社区
本文标题：华为向 Mesos 社区贡献 Cloud Foundry-Mesos 框架
本文地址：
引用来自“我?包子”的评论啦啦噜 引用来自“雨翔河”的评论什么情况品牌
引用来自“我?包子”的评论啦啦噜 什么情况当前【全部】
全部安卓手机安卓平板安卓电视iPhoneiPad其他
当前位置：>>>Cloud Foundry v2
热门排行榜
1000万+人在玩9000万+人在玩1000万+人在玩100万+人在玩9000万+人在玩5000万+人在玩
Cloud Foundry v2 app相关推荐
发现该应用有下载安装使用错误或恶意扣费携带病毒，请
版权所有 京ICP备号-5
京公网安备 50 备Cloudfoundry | Software Engineering Lab | Zhejiang University
浙江大学 | SEL实验室
| VLIS研究中心
全球企业Kubernetes开源社区代码贡献排名：浙江大学SEL实验室排名第六。请看来自Stackalytics|Kubernetes community contribution官方网站截图。
从全球企业的贡献排名来看，排名状况基本变化不大，仍然是Google独占鳌头。令人欣喜的是，浙江大学SEL实验室排名又上升了一位，代码贡献量近24万行，总排名超越CoreOS达到世界第六位。这无疑是振奋人心的事情，这意味着越来越多的年轻学术人员投入Kubernetes开源社区建设，这将近一步提高中国在容器云社区的地位。
Kubernetes是当前容器集群编排3大开源方案中社区活跃度最高的。虽然现在正值入冬，但仍然挡不住 Kubernetes掀起全球关注的热潮。Kubernetes体现了Google对海量容器集群管理的经验和精华，这让Kubernetes在容器云计算框架横行天下的年代游刃有余，已经逐步成为了容器云框架中的佼佼者。从Kubernetes开放、自由、持续发展生态圈兼容的态度能看出，Kubernetes正变得越来越自信。
下图为Kubernetes模块代码贡献分析图：
从图中可知：Kubernetes运维和生态圈组件模块代码贡献直追核心模块kubernetes，排名2-4位的模块分别是Kubernetes生态圈、操作和界面。Kubernetes使用者越来越关心容器云框架落地而非仅仅将其作为空中楼阁远观而止。
Kubernetes在国内发展已经超过了3年的时间，但是遗憾的一点，尽管我们拥有世界上最多的开发人员，但是我们常常对社区没有话语权，国内的用户的需求无法对社区上游形 成影响，导致很多本地化定制的需求无法真正的在社区版本代码得到体现。所以如何让中国的声音出现在社区，是我们所有容器云计算人需要思考的问题。更希望越来越多的国内传统IT巨头能够意识到这个问题，投身于开源的事业中。
自Docker容器与容器云第1版出版以来，销量达到10000多本，得到了广大技术人员的认可，并且翻译成繁体，进入台湾市场。本书对Docker和Kubernetes的源码解析深入细致，是国内Docker界的良心之作。
经过作者们多年的实践经验积累及近一年的精心准备，浙江大学SEL实验室出版的《Docker容器与容器云》第2版，终于与我们见面了。
本书根据Docker 1.10版和Kubernetes 1.2版对第1版进行了全面更新，从实践者的角度出发，以Docker和Kubernetes为重点，沿着“基本用法介绍”到“核心原理解读”到“高级实践技巧”的思路，一本书讲透当前主流的容器和容器云技术，有助于读者在实际场景中利用Docker容器和容器云解决问题并启发新的思考。全书包括两部分，第一部分深入解读Docker容器技术，包括Docker架构与设计、核心源码解读和高级实践技巧；第二部分归纳和比较了三类基于Docker的主流容器云项目，包括专注Docker容器编排与部署的容器云、专注应用支撑的容器云以及一切皆容器的Kubernetes，进而详细解读了Kubernetes核心源码的设计与实现，最后介绍了几种典型场景下的Kubernetes最佳实践。
自本书第1版出版以来，容器生态圈已经发生了翻天覆地的变化。新的开源项目层出不穷，各个开源项目都在快速迭代演进。Docker已经从本书第1版里的1.6.2发展为当前的1.10。Kubernetes也从本书第1版里的0.16发展到了现在的1.2，并且在1.0.1版本时宣布其已经正式进入可投入生产环境（production ready）的状态。
第3章是本书第一部分的重点。Docker 1.10版相对于本书第1版中的1.6.2版，主要的更新包括如下几个方面：
1、Docker在架构方面不断将自身解耦，逐步发展成容器运行时（runtime）、镜像构建（builder）、镜像分发（distribution）、网络（networking）、数据卷（volume）等独立的功能组件，提供daemon来管理，并通过Engine暴露一组标准的API来操作这些组件（详见本书3.2节）；
2、将网络和数据卷提升为“一等公民”，提供了独立子命令进行操作，网络和数据卷具备独立的生命周期，不再依赖容器的生命周期（详见本书3.7节、3.8节）；
3、网络实现方面，Docker将网络相关的实现解耦为独立的组件libnetwork，抽象出一个通用的容器网络模型（CNM），功能上也终于原生支持了跨主机通信（详见本书3.8节）；
4、在扩展性方面，在1.7.0版本后就开始支持网络、volume和存储驱动（仍处于实验阶段）的插件化，开发者可以通过实现Docker提供的插件标准来定制自己的插件（详见本书3.6节、3.7节、3.8节）；
5、在Docker安全方面，Docker支持了user namespace和seccomp来提高容器运行时的安全，在全新的镜像分发组件中引入可信赖的分发和基于内容存储的机制，从而提高镜像的安全性（详见本书3.5节、3.6节、3.9节）。
需要特别指出的一点是，随着容器如火如荼的发展，为了推动容器生态的健康发展，促进生态系统内各组织间的协同合作，容器的标准化也显得越来越重要。Linux基金会于2015年6月成立OCI（Open Container Initiative）组织，并针对容器格式和运行时制定了一个开放的工业化标准，即OCI标准。Docker公司率先贡献出满足OCI标准的容器运行时runC，HyperHQ公司也开源了自己的OCI容器运行时runV，相信业界会有越来越多的公司加入这个标准化浪潮中。Docker公司虽然没有在Docker 1.10版本中直接使用runC作为容器的运行时，但是已经将“修改Docker engine来直接调用runC的二进制文件为Docker提供容器引擎”写入到了1.10版本的roadmap中。本书在3.4.3节中对runC的构建和使用进行了介绍。
第8章是本书第二部分的重点。由于Kubernetes的代码始终处于积极更新之中，自本书第1版截稿以来，Kubernetes又相继发布了0.17、0.18、0.19、0.20、0.21、1.0、1.1与1.2等几个版本。主要的更新包括如下几个方面：
1、大大丰富了支撑的应用运行场景。从全面重构的long-running service的replicaSet，到呼声渐高的支持batch job的Job、可类比为守护进程的DaemonSet、负责进行应用更新的Deployment、具备自动扩展能力的HPA（Horizontal Pod Autoscaler），乃至于有状态服务的petSet，都已经或者即将涵盖在Kubernetes的支撑场景中（详见本书8.2节）。
2、加强各个组件的功能扩展或者性能调优。apiserver和controller manager为应对全新的resource和API有显著的扩展；scheduler也在丰富调度策略和多调度器协同调度上有积极的动作；kubelet在性能上也有长足的进步，使得目前单个节点上支持的pod从原来的30个增长到了110个，集群工作节点的规模也从100个跃升为1000个；多为人诟病的kube-proxy如今也鸟枪换炮，默认升级为iptables模式，在吞吐量上也更为乐观；在可以预期的未来，rescheduler将成为Kubernetes家庭中的新成员，使得重调度成为可能（详见本书8.3节）；
3、兼容更多的容器后端模型、网络及存储方案。从Docker到rkt，Kubernetes展示了对容器后端开放姿态，同时它还准备以C/S模式实现对其他容器的支撑。在网络方面，Kubernetes引入了网络插件，其中最为瞩目的当属CNI；存储上的解决方案更是层出不穷，flocker、Cinder、CephFS不一而足，还增加了许多特殊用途的volume，如secret、configmap等（详见本书8.4节、8.5节）；
4、增加了OpenID、Keystone等认证机制、Webhook等授权机制，以及更为丰富的多维资源管理机制admissioncontroller（详见本书8.6节）；
5、另外，作为Kubernetes社区的积极参与者，我们还专门增加了8.8节，讨论当前社区正在酝酿中的一些新特性，如Ubernetes、petSet、rescheduler。我们还讨论了Kubernetes性能优化，以及Kubernetes与OCI的关系等话题。
除了全面更新这两个重点章节之外，我们还在第1章中更新了Docker近期的“大事记”并重新整理了容器生态圈，加入了许多重要的容器云技术开源项目，以及OCI、CNCF等国际标准化组织；在第2章中，我们将Docker命令行工具的基础用法更新到了Docker 1.10版；在第4章中完善了对时下火热的“容器化思维”和“微服务”的讨论；在第6章中更新了对Docker“三剑客”——Compose、Swarm和Machine的讨论；在附录中以Docker 1.10版为标准更新了附录A的Docker安装指南，以Kubernetes 1.2为标准，更新了附录F中Kubernetes的安装指南。
如果你是初级程序员，本书可以帮助你熟悉Docker与kubernetes的基本使用；如果你正在IT领域进行高级进阶修炼，那本书也可以与你一起探索Docker与kubernetes的工作原理。无论是架构师、开发者、运维人员，还是对Docker比较好奇的读者，本书都是一本不可多得的带你从入门向高级进阶的精品书，值得大家选择！
最后，摘录一些读者的推荐如下——
—— 许式伟，七牛云存储CEO ： “虽然在此之前已经有了由Docker团队出的第一本Docker书，但是这是国内第一本深入解读Docker与Kubernetes原理的原创图书，这一点意义重大。本书比较完整地介绍了Docker与Kubernetes的工作原理和生态，非常有借鉴意义。”
——肖德时，数人科技CTO： “Docker容器技术已经在国内如火如荼地流行起来，浙江大学SEL实验室目前是国内掌握Docker技术最熟练的技术团队之一，他们在国内Docker技术界一直产生着重要影响。这次他们把Docker的实战经验汇编成书，可以帮助更多的Docker爱好者学习到一手的实战经验。”
——程显峰，火币网CTO ： “本书非常细致地讲解了Docker技术的来龙去脉和技术细节，更为难得是还加入了Docker生态当中的其他技术。Docker这项技术本身就是将多种思想和技术融合的产物，从生态的视角去解读技术的来龙去脉将极大地促进读者对云计算和容器技术的重新思考。”
—— 刘俊，百度运维部高级架构师，两次百度最高奖获得者 ： “本书宏观上描绘了容器和容器云技术发展的浪潮和生态系统，微观上以Docker和Kubernetes为典型进行了深度分析。无论是Docker技术爱好者，还是系统架构师、云端开发者、系统管理和运维人员，都能在本书中找到适合自己阅读的要点。浙江大学SEL实验室云计算团队是一支非常优秀的云计算研究团队，很多85后、90后人才活跃在顶级社区前沿，感谢他们能将多年的知识和智慧积累分享出来！”
——郝林，微影时代架构师，《Go并发编程实战》作者 ： “本书是浙江大学SEL实验室云计算团队多年深耕Docker及背后的容器技术的结晶。最大的特点就是深入，并且有各种实用案例和细致讲解。另外，这本书在怎样真正地把Docker及周边产品落地以构建灵活多变的云平台方面也进行了生动的阐释。”
——网友 Monster-Z： “自本书第一版出版以来，Docker社区又经过了如火如荼的发展，特别是网络部分的实现已经发生了翻天覆地的变化，而本书在第一版的基础之上及时地对网络部分的内容进行了更新。本书对于docker网络最新内容深入透彻的分析，让我们这些急于想要对Docker网络部分实现原理有所了解的开发人员如醍醐灌顶。相信对Docker技术感兴趣的读者在读完本书之后会与我有相同的感受。”
——网友 XiaoYu： “之前对于浙江大学的SEL实验室早有耳闻，也深知他们在云计算领域有着深厚的积淀。这次对他们著作的第二版进行了深入的研读，可以看得出，在保持了第一版架构的同时，对各个章节的内容又进行了大量的扩充，紧紧跟随着Docker以及k8s社区的发展步伐。相信不论是对于初涉容器领域的新人，还是希望深入理解Docker容器实现原理的开发人员，这都是一本不可多得的好书。”
——网友 Mongo： “在学习了本书的第一版之后，就一直期待着本书第二版的出版。于是当得到第二版出版的消息之后，就迫不及待入手了一本。捧读之后，发现在内容上与第一版有了较大的变化，这应该与Docker本身快速的发展有关，当然也从侧面反应了容器技术在时下的热度。相信对于像我这样Docker技术的一线使用者来说，本书固有的深度以及第二版的时效性都将让我们对Docker的使用和理解都更上一层楼。”
——网友 YaoDD： “之前在学习k8s的过程中，一直苦于没有深入到代码层面的书籍可供参考。国内出版的大多数图书更多的是对官方文档的”翻译”，而并没有进一步深入的解读。直到发现了浙江大学SEL实验室出版的《Docker容器与容器云》一书，其中对k8s的各个组件做到了深入源码级的原理分析，让人直呼过瘾。所以在该书第二版出版的第一时间就购买并阅读了，发现在保持第一版分析深度的同时，又加入了许多社区最新的研发成果。如果你想对k8s有着更加深入的理解，那么本书将是你的不二选择。”
——网友 DockerLover： “作为一名Kubernetes企业级应用的一线实践者，早就对浙大的SEL实验室慕名已久。该实验室的研究人员为Kubernetes社区共享了大量的代码，数量上堪比华为等巨头企业，尤其是其中的张磊博士，更是Kubernetes的member，技术实力可见一斑。因此本书不论是深度广度，还是对于学习容器技术的指导意义都是毋庸置疑的。”
——网友 GaryRong： “自Docker出现以来，一股容器热潮已经席卷了整个互联网，如火如荼，方兴未艾。而浙大SEL实验室在云计算和PaaS领域深耕多年，作为docker技术在国内第一批的学习者和实践者，积累了丰富的经验。而出版的《Docker 容器与容器云》从第一版到第二版，对低到底层容器技术的实现，高到整个容器生态圈的发展都有着独到而深刻的理解。相信本书一定不会让你失望。 ”
《Docker容器与容器云》是Kubernetes社区核心开发者张磊博士及其技术团队近年来PaaS方面积累，全书不仅描述了容器与容器云技术，还融入了实验室四年来对云计算各个层面的理解。该书是国内第一本对Docker原理进行深度解析的书籍，也是第一本结合PaaS对各类容器云进行深度剖析，并着重深入分析Kubernetes原理的书籍。
该书从2014年12月开始写作到2015年9月正式出版发行，期间数易其稿，从最初的对源码进行逐字逐句的分析，转变为带着问题去思考，最后再回到源码去理解问题背后的本质，书的每一章每一节都是实验室智慧与汗水的结晶。
出版发行以来，我们几乎没有对本书进行特别的宣传，凭着少数几次活动以及朋友圈里朋友们的口口相传，逐渐被广大云计算爱好者们发现，并受到了业内外读者的一致好评。从九月初至今，不到两个月的时间，第一次印刷的三千五百册就已接近全部售罄，准备进行第二次印刷。我们也会尽可能多的根据读者的反馈，对第一次印刷中存在的问题进行勘误。
我们自己没有太多权利评判书本本身的好坏，但是我们看到了业内外读者的评价，让我们感受到了深深的肯定，非常感谢大家的支持！同时也向更多朋友推荐我们这本《Docker容器与容器云》，这绝对是您在容器技术方面最值得一读的书！
最后，摘录一些读者的推荐如下：
“虽然在此之前已经有了由Docker团队出的第一本Docker书，但是这是国内第一本深入解读Docker与Kubernetes原理的原创图书，这一点意义重大。本书比较完整地介绍了Docker与Kubernetes的工作原理和生态，非常有借鉴意义。” ——许式伟，七牛云存储CEO
“Docker容器技术已经在国内如火如荼地流行起来，浙江大学SEL实验室目前是国内掌握Docker技术最熟练的技术团队之一，他们在国内Docker技术界一直产生着重要影响。这次他们把Docker的实战经验汇编成书，可以帮助更多的Docker爱好者学习到一手的实战经验。”——肖德时，数人科技CTO
“本书非常细致地讲解了Docker技术的来龙去脉和技术细节，更为难得是还加入了Docker生态当中的其他技术。Docker这项技术本身就是将多种思想和技术融合的产物，从生态的视角去解读技术的来龙去脉将极大地促进读者对云计算和容器技术的重新思考。”——程显峰，OneAPM首席运营官
“本书宏观上描绘了容器和容器云技术发展的浪潮和生态系统，微观上以Docker和Kubernetes为典型进行了深度分析。无论是Docker技术爱好者，还是系统架构师、云端开发者、系统管理和运维人员，都能在本书中找到适合自己阅读的要点。浙江大学SEL实验室云计算团队是一支非常优秀的云计算研究团队，很多85后、90后人才活跃在顶级社区前沿，感谢他们能将多年的知识和智慧积累分享出来！”——刘俊，百度运维部高级架构师，百度最高奖获得者
“本书是浙江大学SEL实验室云计算团队多年深耕Docker及背后的容器技术的结晶。最大的特点就是深入，并且有各种实用案例和细致讲解。另外，这本书在怎样真正地把Docker及周边产品落地以构建灵活多变的云平台方面也进行了生动的阐释。”——郝林，微影时代架构师，《Go并发编程实战》作者
“Docker颠覆了容器技术，也将容器技术带到了新的高度。InfoQ从2014年初就开始密切关注容器技术，见证并切身参与了容器技术的发展。作为我们的优秀作者，浙江大学SEL实验室在InfoQ撰写了很多与Docker、Kubernetes相关的技术文章，得到了广大读者的肯定。希望这本书能推动容器技术在中国的落地。”——郭蕾，InfoQ主编
“浙江大学SEL实验室属于国内较早接触并研究开源PaaS技术的团队之一，从传统PaaS的开源代表CloudFoundry、OpenShift，到新一代基于Docker的PaaS平台如DEIS、Flynn等，他们均有深入的研究和实践经验。更为难得的是，他们不仅参与开源贡献，而且笔耕不辍，通过博客、论坛等方式积极分享有深度、有内涵的技术文章，并广泛参与国内PaaS届各种技术交流会议。华为PaaS团队也在与之交流中汲取了不少营养。此次，他们将近年来对Docker容器和Kubernetes、DEIS、Flynn等PaaS开源平台的研究成果结集成册，内容详尽且深入浅出。我相信，无论是入门者还是老手，都能够从中获益。”——刘赫伟，华为中央软件院
“容器技术在大型互联网企业中已广泛应用，而Docker是容器技术中的杰出代表。本书不仅介绍了Docker基础知识，而且进行了代码级的深入分析，并通过对Kubernetes等技术的讲解延伸至集群操作系统以及对Docker生态领域的思考，同时结合了大量实践，内容丰富，值得拥有。”——王炜煜，百度运维部高级架构师，JPaaS项目负责人
“Docker作为操作系统层面轻量级的虚拟化技术，凭借简易的使用、快速的部署以及灵活敏捷的集成支持等优势，奠定了Docker如今在PaaS领域的江湖地位。 浙江大学SEL实验室在云计算和 PaaS领域耕耘多年， 积累了丰富的经验。本书既有对Docker源代码层面的深度解读，也有实战经验的分享，希望这本书能够帮助Docker开发者在技术上更上一层楼。”——李三红，蚂蚁金服基础技术部JVM Architect
本书覆盖面非常广，从docker的使用、核心原理、高级实践再到编排工具以及著名的集群调度工具kubernetes均有涉及，很好的把握了技术人员的痛点。而且架构原理方面均是用docker1.7和部分1.6作为依据，非常有时效性。《Docker源码分析》的作者也是出于该团队，容器云方面功底很深厚啊。 ——网友Crazykev
比较专业的书，书中的内容远远高于这本书的物理容量，希望好好研究Docker和Linux某些虚拟化机制的同学，可以以这本书入门去不断扩充自己的知识。不过这边毕竟是一Docker为主线的书，主要还是为了深入帮助大家理解Docker，以及Docker生态圈内的应用和服务。一句话：国内不可多得的一本Docker相关知识的书，此书讲解深入，排版合理，内容紧凑，值得好好看。 ——网友RHMAN
其实之前不太了解SEL实验室的背景是什么，不过从此书的内容来看，团队的研究能力和文字能力都相当不错。好久没有读过让人“爽快”的技术书籍了。在Docker应用中各领域的知识要点都能提纲挈领的进行讲解，而且对于生产环境的挑战也有深刻的理解，算得上是既有广度又有深度的佳作。 ——网友jerryshang
原文地址：
We’ll begin with a basic Spring application named ms-spr-demo. This app takes users to a simple web page announcing the ubiquitous “Hello World!” message. We’ll utilize the cf command-line interface to push the application:
这里先向CF PUSH一个很简单的打印“Hello World”的应用：
$ cf push --path build/libs/cf-demo.war
Name& ms-spr-demo
Instances& 1
Memory Limit& 512M
Creating ms-spr-demo... OK
1: ms-spr-demo
Subdomain& ms-spr-demo
1: cfapps.io
Creating route ms-spr-demo.cfapps.io... OK
Binding ms-spr-demo.cfapps.io to ms-spr-demo... OK
Create services for application?& n
Save configuration?& y
Saving to manifest.yml... OK
Uploading ms-spr-demo... OK
Starting ms-spr-demo... OK
-----& Downloaded app package (9.5M)
Installing java.
Downloading JDK...
Copying openjdk-1.7.0_25.tar.gz from the buildpack cache ...
Unpacking JDK to .jdk
Downloading Tomcat: apache-tomcat-7.0.41.tar.gz
Copying apache-tomcat-7.0.41.tar.gz from the buildpack cache ...
Unpacking Tomcat to .tomcat
Copying mysql-connector-java-5.1.12.jar from the buildpack cache ...
Copying postgresql-9.0-801.jdbc4.jar from the buildpack cache ...
Copying auto-reconfiguration-0.6.8.jar from the buildpack cache ...
-----& Uploading droplet (48M)
-----& Uploaded droplet
Checking ms-spr-demo...
Staging in progress...
Staging in progress...
Staging in progress...
Staging in progress...
Staging in progress...
Staging in progress...
Staging in progress...
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
0/1 instances: 1 starting
1/1 instances: 1 running
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960
&&&&$ cf push --path build/libs/cf-demo.war&&&&&&Name& ms-spr-demo&&&&&&&&&&Instances& 1&&&&&&&&&&Memory Limit& 512M&&&&&&&&&&Creating ms-spr-demo... OK&&&&&&&&&&1: ms-spr-demo&&&&&&2: none&&&&&&Subdomain& ms-spr-demo&&&&&&&&&&1: cfapps.io&&&&&&2: mattstine.com&&&&&&3: none&&&&&&Domain& 1&&&&&&&&&&Creating route ms-spr-demo.cfapps.io... OK&&&&&&Binding ms-spr-demo.cfapps.io to ms-spr-demo... OK&&&&&&&&&&Create services for application?& n&&&&&&&&&&Save configuration?& y&&&&&&&&&&Saving to manifest.yml... OK&&&&&&Uploading ms-spr-demo... OK&&&&&&Starting ms-spr-demo... OK&&&&&&-----& Downloaded app package (9.5M)&&&&&&Installing java.&&&&&&Downloading JDK...&&&&&&Copying openjdk-1.7.0_25.tar.gz from the buildpack cache ...&&&&&&Unpacking JDK to .jdk&&&&&&Downloading Tomcat: apache-tomcat-7.0.41.tar.gz&&&&&&Copying apache-tomcat-7.0.41.tar.gz from the buildpack cache ...&&&&&&Unpacking Tomcat to .tomcat&&&&&&Copying mysql-connector-java-5.1.12.jar from the buildpack cache ...&&&&&&Copying postgresql-9.0-801.jdbc4.jar from the buildpack cache ...&&&&&&Copying auto-reconfiguration-0.6.8.jar from the buildpack cache ...&&&&&&-----& Uploading droplet (48M)&&&&&&-----& Uploaded droplet&&&&&&Checking ms-spr-demo...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&Staging in progress...&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&0/1 instances: 1 starting&&&&&&&&1/1 instances: 1 running&&&&&&OK&&
根据Nolio发布的，很多公司通过路由策略选择性地对部分用户发布新功能从而使用 “金丝雀部署（Canary Deployments）”来测试生产中的软件，并将这一方式作为其可持续交付的一部分。“金丝雀部署”是增量发布的一种类型，它的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。
考虑到和预防性（pre-emptive），一旦克服了“金丝雀部署”所涉及的技术挑战将可以减少部署流程中的风险。A/B 测试允许在不改变大多数用户的用户体验的情况下进行对新功能的测试。而性能测试对于整个用户群体来说同样只会产生微不足道的影响。
根据Nolio的“金丝雀部署”，该方式由以下几个步骤组成：
准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
从负载均衡列表中移除掉“金丝雀”服务器。
升级“金丝雀”应用（排掉原有流量并进行部署）。
对应用进行自动化测试。
将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
在Cloud Foundry中，当应用开发者的应用由Cloud Foundry的组件DEA来运行时，应用的资源隔离与控制显得尤为重要，而warden的存在很好得解决了这个问题。
Cloud Foundry中warden项目的首要目的是提供一套简易的接口来管理隔离的环境，这些隔离的环境可以被称为“容器”，他们可以在CPU使用，内存使用，磁盘使用以及设备访问权限方面做相应的限制。
本文将从四个方面进行探讨分析warden的实现：
warden的功能介绍及框架实现
warden框架的对外接口及实现
warden框架的内部模块及实现
warden的运行示例
warden的功能介绍及框架实现
warden功能介绍
由于Cloud Foundry v1中DEA组件运行应用程序时，自身设计存在一定的缺陷，即同一个DEA上运行的应用不能很好的实现运行过程中资源的隔离与限制，故在Cloud Foundry v2中引入了warden这一模块。
warden专门接收DEA组件发送的关于应用的管理请求，在处理这部分管理请求时，借助轻量级虚拟化技术，将宿主机操作系统进行虚拟化，在容器内部执行请求的具体内容。warden的具体使用效果为应用程序之间互不感知，资源间完成隔离，各自的资源使用存在上限。假设Cloud Foundry不存在应用程序资源的隔离与限制机制，则在同一个DEA上运行的多个应用程序，在负载增加的时候，会出现竭力竞争资源的情况，当资源消耗殆尽时，大大降低应用程序的可用性与安全性。
在资源隔离与限制方面，warden主要提供3个维度的用户自定义隔离与限制：内存、磁盘、网络带宽；另外warden还提供以下维度的资源隔离与限制，但仅提供默认值，不提供用户自定义设置：CPU、CPUACCT、Devices。
Posted in ,
在Cloud Foundry v2版本中，DEA为一个用户应用运行的控制模块，而应用的真正运行都是依附于warden。更具体的来说，是DEA接收到Cloud Controller的请求；DEA发送请求给warden server；warden server创建warden container并将用户应用droplet等环境配置好；DEA发送应用启动请求至warden serve；最后warden container执行启动脚本启动应用。
本文主要具体描述，DEA如何与warden交互，以保证最终用户的应用可以成功绑定某一个端口，实现用户应用对外提供服务。
DEA在执行启动一个应用的时候，主要做到以下这些部分：promise_droplet, promise_container, 其中这两个部分并发完成；promise_extract_droplet, promise_exec_hook_script(“before_start”), promise_start等。代码如下：
promise_droplet,
promise_container
].each(&:run).each(&:resolve)
promise_extract_droplet,
promise_exec_hook_script('before_start'),
promise_start
].each(&:resolve)
12345678910
&&&&[&&&&&&&&promise_droplet,&&&&&&&&promise_container&&&&&&].each(&:run).each(&:resolve)&&&&&&&&&&[&&&&&&&&promise_extract_droplet,&&&&&&&&promise_exec_hook_script('before_start'),&&&&&&&&promise_start&&&&&&].each(&:resolve)&&
Posted in ,
Cloud Foundry作为业界出众的PaaS平台，在应用的可扩展性方面做得非常优秀。
具体来讲，在一个应用需要横向伸展的时候，Cloud Foundry可以轻松地帮助用户做好伸展工作，也就是创建出一个应用的多个实例，多个实例地位相等，多个实例共同为用户服务，多个实例共同分担访问压力。
大致来说，可以认为是共同分担访问压力，但是也不是针对所有该应用的访问，都进行均衡，分发到不同的应用实例处。譬如：当Cloud Foundry的访问用户访问应用时，第一次的访问，gorouter会将请求分发到应用的某个实例处，但是如果该用户之后的访问都是有状态的，不希望之后的访问会被分发到该应用的其他实例处。针对以上这种情况，Cloud Foundry提供了自己的解决方案，使用StickySession的方式，保证请求依旧分发给指定的应用实例。
本文即分析Cloud Foundry中gorouter关于StickySession的实现方式。
该部分内容需要对gorouter有一定的了解，可以参见笔者之前的博文：Cloud Foundry中gorouter源码分析
关于StickySession的信息，gorouter所做的工作，主要分为两个部分：如何给HTTP请求添加StickySession、如何通过StickySession辨别应用的具体实例。
Posted in ,