转自：https://iaaslee.blogspot.com/2015/10/openstack-application-catalog-murano.html?view=snapshot
如题，本文的着重点在于讨论Murano的工作原理和设计。所以内容较为晦涩和枯燥。根据前面的内容，我们很容易得出Murano在OpenStack环境中的数据流，在整个创建、构建、直到虚拟机／集群开始运行的整个过程，可以由下面两张图来清晰的表达：
0、OpenStack UI 中Murano的操作：
正如我们所讲的，murano是Heat的更加接近人类的理解的产物，所以所有的提交、定制最后都会汇集为Heat的模版，尤其是需要其它OpenStack服务做配合的时候。
1、deploy键按下之后，其它OpenStack服务的数据流向和处理：
- 用户通过Murano图形界面发送请求给Murano python客户端。
- Murano python客户端再发送请求给Murano API服务。
- Murano API 服务再发送请求到RabbitMQ。
- Murano Conductor从队列里挑选出请求信息。
- Murano conductor解析信息，重组为Heat模版，并交给Heat引擎。
- Murano conductor会将真正的执行计划发送给rabbitmq，这将是交给Murano代理执行的任务。
- Heat通过各个OpenStack的服务部署整个的IaaS级别的基础设施。
- OpenStack服务部署虚拟机实例，此实例会激活murano代理。
- 在虚拟机内部，Murano代理从rabblitmq中挑出原先murano conductor所分配的执行计划，然后通过各种脚本或程序引擎来执行它们。
2、看完运行时的数据流图后，我们再看下其设计时的组件架构考量：
Murano主要是利用现有的项目和服务。Murano通过Heat直接或间接的整合了其它的OpenStack服务。Celimeter服务所收集到用户信息，Murano－API会用此信息到计费规则处理中，从而计算出计费信息。
先来解释下这些主要组件的功能或定义：
- 元数据服务：存储应用描述和服务的元数据。包括有应用相关的Heat模版、软件配置、部署脚本以及UI的元素定义。
- API服务：UI所使用。此API可让管理员来操纵应用的元数据、可让开发者发布和管理应用，还可让最终用户执行应用配置和自我部署。API提供了RBAC的能力，来对各个组件和应用做访问控制。
- 环境控制：集成OpenStack的部署引擎，如Heat，Trove，Savanna等，来执行实际的应用部署。
- 计费：为已经部署的应用，和Ceilmeter的使用数据一起合作来生成计费信息，每个应用都可拥有自身的计费规则。由创建它的开发者来设置。
再来看下Murano中需要解释的术语、角色或定义：
- 环境：用于组织应用到一个单一到部署的逻辑实体。
- 应用：一个拥有自身的配置和部署脚本的软件组件。一个应用或许会用到多个虚拟机来部署，举例来说，如一个Galera集群，或者是SQL集群，又或者是本系列所用到的Mesos集群。
- 应用定义：一个应用的描述，其包含了应用将如何部署的元数据描述，应用的前提条件，应用的UI元素等等。
- RBAC：基于角色的访问控制。
- Murano：一组提供了控制程序的管理和部署的组件。它通过所定义的端点来访问，可能指向一个或多个应用目录实例，例如，它可能是指向一个本地的实例、也可能是一系列的实例集合、也可能是远端的实例、也可能是上述三种情况的任意组合。
- 应用目录实例：Murano服务的实例，托管服务目录组件，管理一个或多个应用的定义。应用目录实例可以是本地的，也可以一个单一的云中相关联的，或者是远端的，为多个openStack环境提供服务。
- 应用发布者：一个独立的个体或者公司，发布应用到应用目录。
- 最终用户：一个独立到个体或公司，在应用目录中尝试自行部署一个应用。
- 目录管理者：一个独立的个体或公司，维护应用目录，并决定任何有关其用途的相关政策。
3、最后我们再来看下murano代理的数据流工作原理图：
- Heat从rabbitmq中拿到消息
- heat会使用cloudinit来生成murano-agent.conf
- murano代理，会使用此murano-agnet.conf来查找相应的rabbitmq服务以及输入队列。
- Murano代理会从rabbitmq挑选出正确的消息。
- murano代理会执行消息中的执行计划。
总结：
本文尝试解释murano的运行原理及其数据流向，采用的描述手法是尽量的用图来表示。至于顺序，就是从用户的角度出发，从最为直观的可见的、可操作的地方入手，然后谈到部署一个应用时的数据流向，然后诠释了murano的术语和概念，以及架构原理。最后补充了当OpenStack的服务完成了任务之后，虚拟机实例内部发生的事情及其与外部的交互。
时间仓促，错误和纰漏实在太多。还请看官谅解。请留言指出，不胜感激！
