Murano/ApplicationCatalog

应用目录项目旨在使外部开发者更容易为 OpenStack 终端用户创建应用程序和服务。通过这种方式，这些第三方开发者可以丰富 OpenStack 生态系统，使其对用户更具吸引力，并且用户可以更轻松地从他们的 OpenStack 集群中获得更多价值，从而促进 OpenStack 本身的采用。

在任何环境中安装第三方服务和应用程序都可能很困难，但 OpenStack 环境的动态特性可能会使这个问题更糟。该项目旨在通过在第三方组件和 OpenStack 基础设施之间提供额外的集成层来解决这个问题。这个集成层使得能够从单个控制平面提供基础设施即服务和平台即服务。对于用户来说，这个控制平面就成为一个单一的界面，他们可以从中配置整个功能齐全的基于云的应用程序环境。

通过自助服务门户访问，应用目录包含一个应用程序和服务的列表，云用户从中选择进行自助配置。由于每个应用程序和服务定义都包含系统部署所需的所有信息，用户无需与各个 IT 部门合作即可配置云服务，也不需要提供详细的 IT 规范。他们只需要提供业务和组织需求。

在本提案中，我们将研究应用目录设计，定义各种组件，并研究涉及的各种用例。

应用目录设计

如图所示，应用目录利用现有的 OpenStack 项目和服务

应用目录项目通过 Heat 直接和间接地集成所有 OpenStack 组件。Ceilometer 服务将收集使用信息，Murano-API 将在计费规则处理期间使用这些信息来计算计费信息。

Murano API 将暴露 API 调用来管理（CRUD）可用于部署的服务。该 API 将由服务管理员用户界面用于简化服务管理。

应用目录组件和定义

应用目录的关键组件是

元数据服务 - 存储应用程序描述和服务元数据，包括与应用程序相关的 Heat 模板、软件配置和配置脚本，以及 UI 表单定义
API 服务 - 用于 UI，API 使管理员能够操作应用程序元数据，开发者能够发布和管理应用程序，以及终端用户能够执行应用程序配置和自助配置。API 提供 RBAC 功能来控制对各种组件和应用程序的访问。
环境控制 - 与 OpenStack 部署引擎（如 Heat、Trove 和 Savanna）集成，以执行应用程序的实际部署。
计费 - 与 Ceilometer 使用数据合作，为部署的应用程序准备计费信息。每个应用程序可以有自己的计费规则，由创建它的开发者设置。

在评估此提案时，请考虑这些定义

环境 - 将应用程序分组到单个部署中的逻辑实体。
应用程序 - 具有自己的配置和部署脚本的软件组件。应用程序可以使用多个虚拟机进行部署，例如 Galera 集群或 SQL 集群。
应用程序定义 - 应用程序的描述，包括描述如何部署应用程序的元数据、应用程序要求、应用程序 UI 等。
RBAC - 基于角色的访问控制
Murano - 一组组件，提供对应用程序管理和部署的控制。它可以通过定义的端点访问，并且可以引用一个或多个应用目录实例。例如，它可以引用单个本地实例、部门树的实例、远程实例或这些实例的任何组合。
应用目录实例 - 托管服务目录组件并管理一个或多个应用程序定义的 Murano 服务的实例。应用目录实例可以是本地的，与单个云关联，也可以是远程的，为多个 OpenStack 环境提供服务。
应用发布者 - 将应用程序发布到应用目录的个人或公司
终端用户 - 尝试从应用目录自助配置应用程序的个人或公司
目录管理员 - 维护应用目录并确定与其使用相关的任何相关策略的个人或公司。

应用目录用例

应用发布者

该过程始于应用发布者创建一个新的应用程序描述并将其发布到 Murano 端点。然后，它将在该 Murano 端点定义的任何应用目录实例中可用，具体取决于该实例的策略。

应用发布者应该能够通过定义服务元数据、描述属性和指定部署服务及其依赖关系所需的所有步骤来创建新的应用程序。开发者可以从头开始创建此定义，也可以通过扩展现有定义来创建，类似于面向对象范式中的继承。应用发布者可以定义服务的外部依赖项。此依赖项列表定义了在部署给定服务时环境中必须存在的其他服务（按其类型指定）。

考虑这个例子。应用发布者创建了一个提供 Web 应用程序的服务。开发者提供了名称和其他服务属性，并指定外部依赖项是 Web 服务器和数据库。当用户想要在环境中部署此服务时，他们需要拥有 Web 服务器服务和数据库服务在该环境中，并且必须能够指定他们希望如何满足这些要求。（有关更多信息，请参阅终端用户用例。）

应用发布者可以定义其服务的其他使用条款。例如，开发者可以限制其使用和可扩展性（通过继承或从另一个服务引用），或指定计费规则。

应用发布者可能指定的另一个重要参数集是使用指标。这些使用指标定义了 Murano 支持的 Ceilometer 或其他监控工具在运行其实例时应监控服务的哪些方面。应用发布者然后可以指定与这些指标一起使用的计费规则，从而定义使用服务的成本。

[请注意，此提案旨在定义一个提供计费信息的项目，但由于不同组织有不同的需求，因此它没有定义实际的支付方式；支付可以通过外部组件处理，或者可以在 Murano 的未来版本中解决。]

服务定义不绑定到任何特定的 OpenStack 部署或 Murano 实例。开发者可以创建一个服务定义，然后将该定义发布到多个服务目录实例（只要该目录的管理员允许发布即可（如下所示））。

目录管理员

目录管理员管理已发布的的服务定义。

目录管理员是应用程序服务目录的维护者。他们能够手动添加或删除目录中的服务定义，或者充当审核员，允许或不允许其他应用发布者发布他们的服务定义。这种控制可以是粒度的，也可以不是，由管理员选择。例如，管理员可以指定所有新提交必须在提供给任何终端用户之前获得批准，或者管理员可以选择在提交后将服务仅提供给与应用程序发布者关联的 OpenStack 租户，直到服务获得批准。管理员还可以决定在提交后将所有服务提供给所有人，例如在测试云或小型云中，所有开发者都是“可信的”。

管理员还可以定义自己的计费规则，这些规则将添加到应用发布者指定的计费规则（如果已定义）。这使得目录管理员能够覆盖运行和维护云的成本。例如，需要 Microsoft Windows 的服务可能会产生操作系统许可费用；这种机制使目录管理员能够收回该成本。

目录管理员还配置基于角色的访问控制规则 (RBAC)，这些规则定义了云的哪些终端用户（与租户关联）可以访问目录中的哪些服务，以及它们是否可以直接部署或必须在部署前获得批准（请参阅终端用户用例）。特定服务的计费规则也可以专门为给定的租户或给定的用户定义。

最终用户

最后，服务已准备好供终端用户使用。

用户应该能够创建由一个或多个可用服务组成的环境。过程如下

用户浏览可用服务的列表并选择一个或多个进行部署。如果选定的服务具有需要其他服务在同一环境中部署的依赖项，用户可以选择已经存在于环境中的该类型实例，或者添加该类型的新实例。依赖项可能包括其他服务，或者它们可能包括诸如浮动 IP 地址或许可证密钥之类的资源。添加到环境中的每个服务都必须正确配置；系统会提示用户提供所有必需的属性，并且输入将根据每个服务定义中定义的规则进行验证。当用户完成环境配置后，如果他们具有适当的权限，他们可以部署该环境。（请参阅下文。）部署环境意味着创建实例、部署服务并执行所有必需的配置操作。

在某些环境中，终端用户将部署提交给 IT 作为工单会更合适。IT 部门然后可以对定义进行健全性检查，确定它们是否合适，并批准、修改或拒绝部署。如果请求获得批准或修改，IT 部门可以启动部署，而不是用户。

用户可以浏览他们具有权限的任何已部署环境，并检查其状态。检查包括确定哪些服务在哪些节点上运行、服务如何配置等。用户可以修改服务设置、添加新服务或删除现有服务、验证更改（即检查所有必需的属性都设置为有效值，所有服务依赖项都存在等），并通过将这些更改传播到云来重新部署环境。用户还可以检查其环境中运行的服务的用法指标，并查看可计费活动和特定服务的总支出。

应用示例

由 Trove 提供或由自定义部署脚本部署的 RDS 和 NoSQL 数据库。
由 Sahara 提供的 Hadoop 集群。
通过 Heat 配置的 OpenShift PaaS 集群
由 Murano 工作流部署的 MS SQL 集群
由 Murano 工作流部署的 IIS 服务器场
由 Murano 部署的文件共享 (SMB 或 NFS)
由 Murano 工作流安装的 Chef 服务器或 Puppet Master 节点
由 Murano 工作流管理的 Nagios 或 Zabbix 监控

示例

1. 企业 IT 部门创建了私有 OpenStack 云。Cinder 服务使用的硬件存储。默认情况下，此硬件存储会公开简单的卷，而未启用其他功能和选项。同时，此硬件存储具有可以为每个卷启用的功能，例如在线加密和防病毒扫描程序。IT 部门决定在 OpenStack 中公开这些功能，并在应用目录中创建了一个名为 ISCSI 磁盘，具有加密和防病毒扫描程序的新服务。现在，最终用户可以通过将相应的应用程序（NFS 或 CIFS 服务器）和具有加密和防病毒扫描程序的 ISCSI 磁盘添加到环境来创建安全的 FileStorage 解决方案。在环境部署期间，Murano 应用目录会生成 Heat 模板以在 OpenStack 中配置所需的资源，并生成 Mistral 服务中的所有必要的流程，以在存储设备上配置新卷并将其附加到 VM。

2. IT 部门希望向 OpenStack 云用户提供一组具有有限支持配置的应用程序。IT 部门在应用目录中发布这些服务，并为特定用户配置对已发布应用程序的访问权限。现在，最终用户可以使用 Horizon 仪表板使用已发布的应用作为构建块来配置自己的环境。由于最终用户无法修改底层应用程序定义，因此 IT 服务可以为已发布的服务提供支持，因为它完全控制已发布应用程序的工作流程和 Heat 模板。