如何使用 cloud foundry 建立 appfog

[译注]本文翻译自cloud foundry英文博客站点，原文题为“how we built appfog using cloud foundry”，文章发表时间是 2012 年 09 月 13 日。　　使用云的价值主张是“一切因此而简单”。但构建和操作大规模的云却绝非易事。as正如 mark lucovsky 在他的最新访谈中所言：“谁说大规模分布式系统简单？”尽管像 cloud foundry 这样的解决方案使构建核心云技术不再那么令人生畏，但仍然不是件容易的事。　　在这篇嘉宾博文中，appfog 的创始人和 ceo lucas carlson讲述了如何使用 cloud foundry 开源 paas 技术建立 appfog 的历程以及在这一过程中的收获　　核心云技术高深莫测　　运行基于 cloud foundry 的简单服务并不是难事。查看 micro cloud foundrytm。　　构建一个适合生产和企业工作负荷的服务相当困难。　　要构建含有一个 api 端点的基于 cloud foundry 的服务，该服务在 4 个以上的独立基础结构供应商的 6 个以上不同可用性区域中运行，适合于生产和企业工作负荷，具有一定规模和一般可用性？目前这真的很难。　　快马加鞭推行 cloud foundry　　正如您可以设想到的那样，自从 appfog 宣布 ga 以来，人们一直在问我们怎样去做。我们是如何解决怎样将针对 cloud foundry 提供、为跨多个云、多个可用区域以及多个供应商提供一个可共用界面的公共云扩大规模的？　　首先：cloud foundry 代码库确实很不错。由于选择使用 cloud foundry 进行构建，我们不必面对此类项目可能出现的很多潜在严峻挑战和消耗大量时间的问题。　　其次：我们能够从 cloud foundry 生态系统内的更多工具、代码和服务所获得的益处显著加快了我们的开发速度。　　第三：拥有 ga 中已经存在并具有一定规模而且并非基于 cloud foundry 的公共 paas 是我们的一个重要促进因素。我们具有实现强大的 paas 所需要的内部操作经验。　　appfog 的操作经验对我们来说非常宝贵。尽管 paas 与 noops 趋势紧密结合，但 noops 并不意味着无操作，而只是对开发人员而言无操作。正如每一个曾运行过 cloud foundry 的人员所知，很多操作对于运行 paas 都必不可少而且很重要。　　最为重要的是，我们拥有一个有成千上万的开发人员（php fog 的用户）参与的充满活力的社区供我们咨询，在从内部测试版到公共测试版直至 ga 的过程中帮助我们定义、测试及改进 appfog。　　悉心倾听，交付所成　　正是这个社区帮助我们了解了 appfog 的 ga 的发展目标、需要的工作方式以及我们的目标定价。开发人员对我们的要求如下：　　能够跨数十个或数百个负载平衡的实例上轻松扩展应用程序，甚至免费版也是如此　　必须在基础结构中最快的服务器上运行应用程序（例如 m2.4xl）　　必须能够跨多个基础结构（rackspace、hp、aws、azure，并且无价格差异）运行应用程序　　必须简化定价。没有稀奇古怪的打包和组合以及名称。简单而且价格合理，最重要的是公正。　　在云中实现真正的互操作性，包括运供应商之间的一键式零代码迁移，从而消除了所有供应商锁定痕迹　　目标是 30 秒部署到 aws、rackspace、hp、azure 等等。　　支持 cloud foundry 代码库中的任意及所有语言　　支持任意及所有关系数据存储和 nosql 数据存储　　这是一个令人生畏的列表。但这正是开发人员所需要的。　　因此让我们面对现实… 我们事实上是如何做到的呢？　　如何围绕 cloud foundry 构建 paas　　这是个复杂的过程。幸运的是，几个月前，jeremy voorh** 在伦敦 qcon 做了一个报告，叙述了 appfog 如何将 cloud foundry oss 位与我们自有的自定义扩展和增强功能集并用，来构建商用系统。这无疑是了解从 cloud foundry 到 appfog 的发展历程的最好开端。此报告的幻灯片位于此处，视频位于此处。　　在此，我们不逐一回顾 jeremy 历时近一小时的讲话，但我们要讨论一些要点。　　首先，jeremy 澄清了一些关于“cloud foundry”这一标志的混淆之处。一方面，cloudfoundry.com 是 vmware 提供的托管 paas，运行在 vsphere 虚拟**上，该**基于 cloudfoundry.org 中的开源项目。 vmware 还公开了其用来管理 cloudfoundry.com-cloud foundry bosh-的工具的源代码，并公开了其托管服务生产环境中的 bosh 版本。　　我们不在托管 vmware 服务上进行，而是从同一个开源 cloud foundry 项目构建。这种分布式开源系统使团队能够在其生命周期内在云中管理及部署应用程序和服务，这是 appfog 服务的核心。　　由于我们构建了一个基础结构不可知的 cloud foundry 服务，因此 appfog 在当前的 cloud foundry 生态系统中是独一无二的。　　cloud foundry 的好处在于，基本上它可以与从基于 openstack 的 iaas（如 rackspace 或 hp）到 aws、joyent、citrix 等等所提供的基础结构相结合来实现。这种固有的多云可移植性就是 cloud foundry 项目如此鼓舞人心的原因所在。　　对于我们而言，在应用程序的生命周期内和多个基础结构间部署和重新部署的能力是构建下一代 paas 的关键。我们认为，它还可以实现 paas 的以下基本使命： (a) 促进产品团队对开发的关注；(b) 在应用程序生命周期内形成更短的反馈周期；(c) 提供接近即时水平扩展性的可能性。　　cloud foundry 在云计算革新中的作用　　即使是对于通常而言精通云计算领域的人，回顾历史发展环境也非常重要。对我们 appfog 人而言，cloud foundry 已提供了一些重要的构建基础来构成首个下一代 paas。但是，这对我们有何意义？　　首先，了解一些背景信息很重要。paas 最初是在一些历史性突破的基础上应运而生的，例如：　　20 世纪 90 年代在 rackspace 等公司出现数据中心。　　21 世纪前十年的早期在 vmware 出现服务器虚拟化　　21 世纪前十年的中期 aws 在虚拟化资源中引入 api　　最近出现的 devops 范例及其关联和派生的工具，例如 puppet 和 chef。　　但只是在过去两年，这条发展路线才开始真正走向成熟。像 cloud foundry 和 openstack 这样的工具已产生，并能够对整个应用程序生命周期进行管理。这意味着“**即服务”中的“**”现在可以包含开发之外的应用程序生命周期的所有方面。jeremy 在报告中将此称为“noops”。其含义绝非是再也无人去执行操作，而是操作工作的职责已传递到**层，并且在应用程序生命周期的大部分时间（如果不是全部生命周期）会保留在该层。　　如果没有像 cloud foundry 这样包罗万象的工具，我们永远也不能逾越第一代 paas **与下一代 paas（如 appfog）之间的鸿沟，前者对于基础结构管理而言实质上与用于（难以控制的）基础结构管理的**相比只是略有改进，而后者为用户带来的好处则要全面得多。　　appfog 对 cloud foundry 的修正　　appfog 从为托管 cloud foundry 生态系统提供强大的用户界面和多云体验入手开始工作。我们在 cloud foundry 代码库和成型的 paas 产品之间遇到了许多障碍。尽管当前的 cloudfoundry.org 项目集成了 cli 和各种 ide，但我们还着眼于全面的用户体验，包括快速注册、web 控制台以及我们称为 jumpstart、附加组件等等的构建前示例应用程序。　　尽管一些 cloud foundry 用户确实觉得从命令行、eclipse 或 spring tool suite 来操作系统（就像很多 appfog 用户的做法一样）非常习惯，但我们还是希望为用户提供直观而又别具一格的控制台，用来管理他们的所有应用程序。下面是 appfog 控制台的一个示例：　　系统创建者希望 cloud foundry 对于事物的 ux 端处于一种不可知的状态，而且不希望使其 ux 实现过于武断。　　我们知道，简单和直观并不是最终目的，而在基于低于标准的基础系统生成简洁的 ux 是很容易的事情。但还有很多方面需要进行探寻，以满足尽可能多用户的需求，我们相信我们已经做到了这一点。　　以下是我们在 cloud foundry 的顶层和下层所引入的一些创新举措：　　基于 varn**h 的缓存层，用于显著提高速度　　从一个基于 cf 的基础结构一键**到另一个基础结构，实现真正的工作负载可移植性　　cloud foundry api 兼容层，自动将请求路由到在空间的完全不同部分中运行的完全自治的 cf 实例　　跨数据中心的深度 nagios 集成，使我们在问题产生影响前就发现问题的存在　　此外，cloud foundry 使 appfog 能够创建非常完整的自通信体系结构。无论是在基础结构级别还是其他级别，它还使我们能够将 appfog 设计为一个假定故障发生的系统，并提供一组处理故障的规程。　　翻开 cloud foundry 新的一页　　构建能够跨多个云的完全成熟的商用级别 paas，并使其全部具有最高水准的最终用户体验，即使是从基本的 cloudfoundry.org 系统开始，也是一项宏大的事业。它需要一个极富开发人员敬业精神并全心投入的团队，一个愿意设身处地为客户着想的团队。　　但我们认为值得为这样的成果付出。我们非常幸运能够拥有像 cloud foundry 这样的核心系统。我们以多种方式进行回报，包括为项目添加初始 php 运行时支持，并在优化 cloud foundry 使其能够在公共云中良好运行的过程中不断进行回馈。　　对于 appfog 转向 ga，我们的激动之情难以言表。对于已经注册并开发了千千万万个应用程序的千千万万个开发人员，我们更是无比兴奋。　　我们认为，appfog 的成功不仅仅证明了 paas 的强大，还证明了 cloud foundry 代码库的力度及其开源生态系统和社区的强大。这不仅仅是 appfog 的胜利，更是为 cloud foundry 的成功做出贡献的每一个人的胜利。　　关于作者：lucas carlson 是一位创业家和专业程序员，擅长开发具备一定规模的 web 应用程序。lucas 是主要跨云 paas 公司 appfog 的创始人和 ceo。他撰写了十多个 ruby 库，并为包括 rails 和 redcloth 在内的多个重要 rails 产品做出了贡献。lucas 创立、主办了广受欢迎的 ruby on rails 竞赛 rails day 并担任评委，一直是很多重要编程会议中广受欢迎的发言人。lucas 是 mog 的第一位工程师，负责这一开创性音乐流服务的开发和技术指导。lucas 居住在俄勒冈州波特兰，喜爱统计学和 go。 20210311