Following on our previous discussion surveying the projects supporting applications within OpenStack, let’s continue our review with an in-depth look at the OpenStack-native Application Catalog: Murano, currently an incubation status project, having seen its functionality and core services integration advanced over the past few OpenStack releases.
What is it?
An application catalog developed by Mirantis, HP and others (now Cisco), that allows application developers and cloud administrators to publish applications in a categorized catalog to be perused and deployed by application consumers. The selection of applications available within the catalog is intended to be that of released versions (ready-state) of applications (cloud-native or enterprise-architected), not application versions that are mid-development. Ideally, these are applications ready to be consumed and run by application users.
Functionality Highlights
- Supports Windows and Linux
- Leverages HOT templates for application definition
- Controls Heat stack creation and updates processes
- Track application properties and dependencies
- Defines provisioning workflow definitions and executes them
- Introduces “Application” and “Environment” constructs
- Provides UI for application topology visualization
- Control lifecycle of a deployed application
- Allows simple management of access to an application
- Compose an environment from multiple application components
- Out of the Box Cataloged Applications
- 16 sample applications available now
- 6 production-grade applications on Mirantis OpenStack Express**
- Multiple application formats supported:
- HOT Templates
- MuranoPL
- Vision to support
- Other application model formats:
- Parallels APS format
- TOSCA format
- Pricing; billing system integration
- Other application model formats:
User Personas & Capabilities
As an application catalog, Murano, primarily focuses on three user personas, the Cloud Administrator, Application Consumer and Application Publisher receiving the most emphasis upfront in the development of this project.
Application Consumer
The Application Consumer selects and deploys instances of applications into environments they define. The Application Consumer also…
- …browses catalog (search, category, tags, etc)
- …creates new environments
- …deploys applications in environments
- …monitors application statistics
Application Publisher
The Application Publisher creates application definitions (packages) that are imported as entries into the application catalog for perusal by Application Consumers. The Application Publisher also…
- …defines application metadata (author, help message, version, etc)
- …identifies cloud resource allocation (HOT templates)
- …creates application deployment specifications (HOT templates)
- …defines a template for dynamic visualization of application topology (Horizon)
- …identifies metrics collection (Ceilometer)
- …establishes actions & events (Murano & Mistral)
- …imports and publishes application definition to catalog
Cloud Administrator
The Cloud Administrator is responsible for running the application catalog and providing stable infrastructure upon which to deploy and run applications. The Cloud Administrator also…
- …curates application catalog (certification and signing of packages)
- …configures access to applications
- …defines billing rules*
Application Packaging Process
Currently, Murano applications may be packaged using two different formats to describe the application – the MuranoPL or a HOT template. There’s roadmap to support addition application description formats. While these two methodologies vary in terms of how the orchestration is performed during provisioning of an instance of the app, their are common attributes (catalog metadata) like an application display name, logo, description, author, tags. For those familiar with other domain-specific languages of other popular configuration management frameworks, the MuranoPL is of little challenge to pick up (you may lean into use Bash or Powershell if more comfortable) or you may opt to use SoftwareConfig and SoftwareDeploy of HOT. One Cisco product team has already taken the time to go through the process Murano-fying their applications with the intent to use Murano as an internal catalog to facilitate service activation.
Architectural Overview & Core Services Integration
See the “Murano Architectural Overview” diagram for a visual representation of how Murano is tightly integrated with core OpenStack services. It’s relationship to existing core services breaks down as follows:
Glance
Originally designed as an image repository, Murano will use Glance to store & query application definitions. Glance is used as an artifact repository to store application definitions, query & search them and store images required by applications. Images used by Murano are marked with specific metadata, which is used by Murano to derive appropriate selections within the UI during application deployment time.
Heat
- Cloud resource allocation specific to the application
- Resources required by application is allocated using Heat
- Application provisioning / deployment via Heat Software Configuration
- Life-cycle callbacks*
Horizon
Horizon is used to provide the Application Catalog user interface wherein Application Publishers may browse and deploy applications. Horizon is also used to both build applications and visualize the topology provisioned applications. The need for this type of dynamic user interface (application topology canvas) has been proposed as separate project to provide common support to other Application-oriented projects – Heat, Solum, Mistral and Murano. This application blueprint designer project is codename – Merlin.
Docker
Murano supports existing Nova and Heat plugins. See the “Murano and Containers” section below.
Ceilometer
Murano uses Ceilometer for application metric collection & processing. Additionally, Ceilometer events may be subscribed to and trigger specific actions (see below) for autoscaling, HA, DR and other.
Mistral
- Workflows are used when complex workflow outside of Heat is needed.
- Actions (also available w/o Mistral)
- Application level ad-hoc actions (e.g. create backup, enable/disable some feature, or create user for an application) will also be defined in Mistral.
- Events (e.g. when X occurs then do Y)
- Events mapping to actions
Actions & Events
Murano and Containers
Murano inherently supports Docker containers by relying upon existing OpenStack components for container integration and orchestration. This means that there are no considerations to be accounted for within the MuranoPL to describe the application package to support containers. Similarly, when using Heat templates at the core of the application package, only reference to Docker resources and images is needed to support container orchestration by Heat. There are different ways of using Docker in OpenStack via Murano:
1) Heat template can use Heat::Docker
- Heat::Docker driver leverages Heat engine directly to instantiate containers
- Use Heat when Nova does not support Docker
2) Heat template can use Nova::Docker
- Use when you have a bare metal Docker installation
- Through Nova API, create a container without a VM being created to host
- Nova can go to bare metale to create Docker container
- User provides Heat template, workflow (Murano DSL) and image
3) Not recommended – Use Heat resource to create a VM with Docker inside and boot an image file to the VM with docker run.
The Murano team is looking to add autoscaling for Docker services, facilitate Docker application placement and integration with monitoring and network services.
Murano as a Southbound Catalog
Murano has two different northbound APIs to expose access to applications in the catalog – REST and AMQP (Services Broker). Within the Juno release, the Services Broker has only been prototyped. It’s scheduled to be fully-implemented in Kilo. While other use cases may exist, the primary use case for these northbound API revolves around allowing northbound catalogs to access and expose OpenStack-native applications.
The Services Broker supports CRUD and binds service with your application. A proof of concept has been completed to integrate Cloud Foundry with Murano via the Service Broker. When CloudFoundry is integrated to Murano, CloudFoundry users see and order Murano applications in CloudFoundry.
Using the REST API, look for the Cisco Intercloud Marketplace to have integrated Murano as a southbound application catalog to expose OpenStack-native applications as SaaS application profiles available for users of the Marketplace. Users benefit from existing services offered on top of OpenStack. This enables application components to be split across infrastructure (having application components deployed into different infrastructures).
Kilo Roadmap
While subject to change, based on Kilo design summit discussions this week, the project team aims to bite off the following capabilities before the next release in May.
- Implementing CloudFoundry ServiceBroker API
- Use of Glance as an artifact repository
- Support pluggable package definitions formats:
- TOSCA (Topology and Orchestration Specification for Cloud Applications)
- APS (Parallels Application Standard)
- Multiple Heat Stacks and OpenStack Cloud support
- Availability Zones (for DR)
- Multiple OpenStack clouds
- Pluggable Architecture
- Integration with 3rd party API (F5, Brocade etc.)
- Package format plugins
We’ll continue our review of support for applications within OpenStack in the next post of this series by diving into application lifecycle management with Solum.
This article originally appeared on Lee Calcote’s blog.
—
*Future capability
**To be released in November 2014 on Mirantis OpenStack Express
Murano logo and screenshots reprinted with permission from Mirantis Inc.
Great post, very interesting read. Thanks
Thanks for the feedback, Albert. It’ll be a while yet, but keep a lookout for a book on the topic.