提请留意一些新增的云控制器功能

    精彩文章,何不与朋友分享

[译注]本文翻译自Cloud Foundry英文博客站点,原文题为“Heads Up on Some New Cloud Controller Features”,文章发表时间是 2012 年 6 月 20 日。

正如我于 4 月底在我的博文中所讨论的那样,云控制器正在经历大换血,这项工作正在 cloud_controller_ng repo 中进行。如果您正关注 cloud_controller_ng 项目的评审进展,那么现在是时候留意一些新增的 Organization 和 AppSpace 对象了。这些对象是我们今年将要推出的一些新增功能的基础:

  • 操作协同
  • 高级配额管理和控制
  • 定制域及各种各样的应用程序功能

本篇博文将着重介绍这些对象本身,并通过讨论操作协同来说明这些对象的重要性。其他功能将在后续的博文中予以讨论。

为了解这些新增对象,最好简要回顾一下当前模型并了解这种架构存在的部分限制。下图简要显示了当前的云控制器模型。

在此架构中,每个用户帐户直接包含指定了名称的应用程序和指定了名称的服务实例。这些名称的作用域为该用户帐户对象,并且只有该帐户才能操作这些应用程序和服务。这种模型的简易性暴露了一个操作方面的问题,当有多名人员负责一个应用程序的日常维护时,这个问题便可能会出现。

这个问题是:当在给定的帐户下创建您的生产应用程序时,只有该帐户可以操作此应用程序(更新代码、对其进行横向扩展、增加其内存大小,等等)。对于只有一名开发人员操作的情况,这种模型没有问题。不过,一旦有多名人员负责一款应用程序(例如您初创的只有 3 个人的小公司),这种方法就会出问题。为了弥补这一缺陷,人们采用共用的帐户,共用密码,或者不得不调用管理员权限,凭借这些权限,管理员可以操作其他用户的帐户中的对象。这些解决方案全都奏效,不过都是欠佳的解决方案,也会暴露出自己的一些问题(无法生成说明谁执行了何种操作的精准审核日志、拥有管理员权限的人员过多,等等)。

新模型旨在以可扩展且可持续的方式解决上述不足,同时还会为实现其他高级功能奠定所需的基础。

下图简要显示了新的云控制器模型。

采用这种新模型时,应用程序和服务现在的作用域是一个称作 AppSpace 的新对象。多位用户可以访问同一 AppSpace,每位用户各有一组权限决定着其可以对该空间内的应用程序和服务执行哪些操作。不用再采用共用的帐户、共用密码或调用管理员权限,您只需为面向生产的应用程序创建一个 AppSpace,再允许一组遴选出来的开发人员操作该空间内的应用程序和服务即可。

通过引用 Organization 对象,我们在此基础上更进了一步。此对象可以包含多个 AppSpaces 以及一个成员用户名单。如果您确实难以理解这个对象但熟悉 GitHub 帐户模型,您可以从作用域界定和权限的角度来审视它,GitHub Organization 与 Cloud Foundry Organization 十分相像,GitHub repo 则与 Cloud Foundry AppSpace 是相似的。

关于高级配额管理及其他功能,我将留到另一篇博文中详细阐述;不过,如果您阅读代码和评审进展,您便可以了解到我们是如何使用这些新增对象作为配额管理、定制域及众多其他高级功能的基础的。

-markl

Cloud Foundry 工程设计部副总裁 Mark Lucovsky

    精彩文章,何不与朋友分享

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" cssfile="">