It’s great to see Murano is gaining popularity and usage since its release, along with additional projects added in the last OpenStack releases - from Sahara to Marconi, I find the addition and the diversity of projects now available in this growing ecosystem extremely impressive.
Authors of this article: Uri Cohen and Luther Trammell
So for those who are unfamiliar, OpenStack Murano introduced an application catalog to OpenStack, which allows application developers and cloud administrators to publish their cloud-ready applications in a browsable, easily navigable and categorized catalog.
What this essentially means for OpenStack users is that they can now submit and upload application packages to Murano in various formats, from Heat orchestration templates, to MuranoPL packages (the Murano language), and even Glance images, and deploy these uploaded applications to OpenStack at the click of a button. So formerly if you wanted to set up a Hadoop cluster, or a Kubernetes cluster, this required manual configuration and setup to tie it all together. The big news was that suddenly cloud users, experience and inexperienced ones alike can leverage this catalog to compose reliable application environments at the push of a button.
Orchestrate your app deployments on OpenStack, VMware, AWS, and more. Get Cloudify. GO
With Murano, the new backend provides roles and permissions to enable the administration of the applications - so you can have an application developer role (who develops an application and uploads it to Murano) a cloud user role (who uses the uploaded applications) and an administrator role who manages the Murano service itself. This simplifies the management of apps on OpenStack significantly.
Murano makes all of this possible on OpenStack. However, when applications are deployed or shared between multiple clouds or not deployed on OpenStack at all, Murano cannot do much for you.
Murano, like Cloudify, is pluggable with a built-in plugin system - so it was only natural for the Cloudify team to partner with the engineering team behind Murano to create a Cloudify plugin for Murano. This plugin allows Murano to manage TOSCA templates directly, and deploy them to OpenStack and other clouds directly, using Cloudify. This comes in addition to, not in place of, the already existing integrations with Heat, Glance, and the MuranoPL itself. By using this plugin, users can essentially extend Murano to any infrastructure, and even deploy and model applications on mixed infrastructures.
On top of this, Cloudify adds the ability to plugin to additional technologies not available through Murano alone, for example SDN controllers outside of OpenStack (for NFV oriented applications, AKA VNFs). It also enables you to easily model complex application topologies in a standard format (e.g. mixed workloads of containerized non-containerized components, like deploying your web application as part of the Docker container and your mongo database directly on an OpenStack VM). You also automatically receive all of the post-deployment functionality available with Cloudify, application management and monitoring, healing and scaling, along with application portability across clouds.
On a personal note, it’s been an excellent experience working with the stellar engineering team at Mirantis to extend Murano to additional clouds and use cases. We expect this integration to simplify deployment on hybrid environments, as well as other popular clouds, including VMware, GCP, and more.
Now Let's See How it Works Under the Hood
The plugin has two essential python files: cloudify_tosca_package.py, which specifies the way Cloudify TOSCAblueprints will be packaged, and cloudify_client.py, which interacts with the Cloudify Manager's Rest API via HTTP.
When you package a blueprint archive for upload to Murano, it should have something like the following structure:
./ | LICENSE | logo.png | manifest.yaml | README.rst | Resources | | some-blueprint.yaml | | types/ | | scripts/
The Resources directory contains the Cloudify Blueprint and required files, while the the Manifest.yaml tells Murano what’s going on:
The EntryPoint in the Manifest.yaml specifies the name of the Cloudify blueprint file to be uploaded to the Cloudify Manager. For example in our example folder structure above, you that would be “some-blueprint.yaml”.
Format: Cloudify.TOSCA/1.0 Type: Application FullName: org.getcloudify.muranoapps.examples.MyApp EntryPoint: some-blueprint.yaml Name: My App Description: > This is my application Author: Me Tags: - TOSCA - Cloudify
This is called by the Cloudify Murano Plugin Code(cloudify_tosca_package.py):
class CloudifyToscaPackage(package_base.PackageBase): def __init__(self, format_name, runtime_version, source_directory, manifest): super(CloudifyToscaPackage, self).__init__( format_name, runtime_version, source_directory, manifest) self._entry_point = manifest.get('EntryPoint', 'main.yaml')
When the application is executed in a later stage the entire Resources directory will be compressed by Cloudify, when Murano makes the rest API call:
@specs.parameter('entry_point', yaqltypes.String()) def publish_blueprint(self, entry_point): global archive_upload_lock if self._check_blueprint_exists(): return path = self._application_package.get_resource(entry_point) with archive_upload_lock: try: self._client.blueprints.upload( path, self._blueprint_id) except cloudify_exceptions.CloudifyClientError as e: if e.status_code != 409: raise
You can fork the code and definitely be sure to provide us with feedback.
Watch the video below for a deeper walk-through.