Going Native with OpenStack Centric Applications: Murano

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 including 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

• 

  Murano Application Catalog UI

  Supports Windows and Linux applications

• 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

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

Murano Application Packaging Process

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.

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:

Murano Architectural Overview

Murano Actions – application-specific scaling

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, Murano may be integrated as a southbound application catalog to expose OpenStack-native applications as SaaS application profiles available for users of a northbound catalog. 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.

—
*Future capability
**To be released in November 2014 on Mirantis OpenStack Express
Murano logo and screenshots reprinted with permission from Mirantis Inc.