翻译Murano—OpenStack，来自wiki.openstack.org/wiki/Murano（2015.7.3Update）

Murano英文资料地址：wiki.openstack.org/wiki/Murano

翻译水平有限，仅限自己学习记录所用。

一、Murano

    Murano项目给OpenStack项目引进了一个应用程序目录，使得应用的开发人员和云管理人员可以在可浏览的分类目录里发布各种云就绪的（cloud-ready）应用。云的使用者，即使是毫无经验的人，也能够通过按下按钮就可以用这个目录来编写可靠的应用环境。

    主要的目标就是提供UI和API，使其允许在应用抽象层级（Application abstraction level）构建和部署复合环境。服务应该做到能够协调复杂的循环依赖的情况，以便于用许多相关联的应用和服务建立完整的环境。然而，实际部署其本身的工作是由现有的软件业务流程工具（software orchestration tools），例如Heat来完成的，因此，Murano项目将会成为各种应用和服务的整合点。

    Murano目前的稳定版本是2014.2，代号为“Juno”。

二、主要信息（Main Info）

1.Murano/ApplicationCatalog（应用目录）

1.1 项目任务（Project Mission）

该项目的任务是提供一个方法让第三方应用程序和服务可以运行在虚拟机上，甚至是使外部的应用可以作为OpenStack的自己的服务。这些应用程序可能是一个简单的、单一的虚拟机，也可能是复杂的、多层的、可以自动缩放（autoscaling）和自我治疗的（self healing）的应用程序。

        从第三方工具开发者的视角来看，应用程序目录将提供一种发布应用程序和服务的方式，包括部署的规则和要求，建议的配置，输出参数和计费规则，它还提供了一种跟踪计费和使用信息的方法。

从使用者的视角来看，应用程序目录是一个发现和自部署（self-provision）第三方应用和服务，并且将它们集成到用户自己的环境中同时可以跟踪使用信息和成本的地方。

1.2原理（Rational）

应用程序目录是为了让创建应用的外部开发人员和使用服务的OpenStack用户用起来更容易。使用这种方法，第三方开发人员可以使OpenStack得生态系统更加丰富，从而吸引更多的用户，用户可以更容易的获得更多的OpenStack集群。

在任何环境中安装第三方的服务和应用程序都是很艰难的，但是一个动态的OpenStack环境可以使这个问题更加严重。这个项目旨在通过为第三方组件和OpenStack基础设施之间提供一个额外的集成层（integration layer）来解决这个问题。这个集成层可以从一个单一的控制平面（single control plane）提供Iaas和Paas。对于用户来说，这个控制计划就编程了一个独立的接口，通过这个接口他们可以部署一个完整的基于云的功能齐全的应用环境。

通过自服务门户（self-service portals），应用程序目录就是一个包括应用程序和服务的列表，在这里，云的消费者（cloud consumers）可以自主选择配置。因为每个应用和服务的定义都包含了部署所需要的系统的全部信息，用户将不必通过各种IT部门来提供云服务，用户也不需要知道详细的规格参数，他们只需要提供商业和组织上的需求。

在这篇proposal中，我们将着眼于应用程序目录的设计，各种组件的定义，并且再看一些使用案例。

1.3应用程序目录设计（Application Catalog Design）

这些应用程序目录利用了现有的OpenStack项目和服务，正如你在下图中看到的：

应用程序目录通过Heat直接或间接地集成了全部OpenStack的组件。Ceilometer这个服务收集使用信息，这个服务在计费规则处理过程中被Murano-API调用来计算计费信息。

The Murano API will expose API calls to manage (CRUD) services available for deployment，这个API将由用户界面来简化服务的管理。

1.4 应用程序目录组件和定义（Application Catalog components and definitions）

应用程序目录关键的组件包括：

• 元数据服务(Metadata service)：对应用的描述信息和服务的元数据，包括应用相关的Heat模板，软件配置和部署脚本，还有UI形式定义的存储。
• API服务：可以在UI中使用，API能够让管理员管理应用程序元数据，让开发者发布和管理应用，让最终的用户可以执行应用程序的配置和自配置。
• 环境控制：整合了OpenStack的部署引擎，例如Heat，Trove，Savanna，来执行实际应用程序的部署。
• 计费(Billing)：与Ceilometer一起为已部署的应用程序提供计费信息，每一个应用程序都有自己的计费规则，这个计费规则是由开发者创建的。

为了评价这篇Proposal，考虑以下这些定义：

• 环境：一个用来将部署应用程序的逻辑实体。
• 应用程序：一种有自己的配置和部署脚本的软件组件。一个应用程序可以使用多个虚拟机来部署，例如一个Galera集群和SQL集群。
• 应用程序定义：一个对应用程序的描述，其中包括如何描述如何部署应用程序、应用程序需求和应用UI的元数据。
• RBAC：Role Based Access Control，基于角色的访问控制。
• Murano：一组用来控制应用程序的管理和部署的组件。它可以通过定义的端点（endpoint）访问，并且可以引用一个或多个应用程序目录实例。举例来说，它可以指向一个单一的本地实例，一个department tree实例，一个远程实例，或者上述任何实例的组合。
• 应用程序目录实例：一个Murano服务的实例，包括了主机目录服务组件和管理一个或多个应用程序定义。
• 应用程序发行商：向应用程序目录发布应用的个人或公司。
• 终端用户：从应用程序目录中自主获得应用的个人或公司。
• 目录管理员：维护应用程序目录并且确定其使用的所有相关政策的个人或公司。

1.5 应用目录用户用例（Application Catalog Use Cases）

应用发行商

这个过程开始于一个应用程序发行商创建一个新的应用程序描述并且将其发布到Murano端点（endpoint）上。然后在任何符合实例政策的Murano端点定义定义和应用程序目录上都是可用的。