My name is Alexander, I am a software engineer in Mirantis. Today we will talk about the Application Catalog which we have built and called the Murano project.
This is our agenda for today. We'll talk about the application catalogs, why are they needed and how can they be used, define the typical use-cases - and will take a look how this goals are achieved in Murano. I will make a little demonstration of how it works - and then will answer your questions.
But let's start from the very beginning: the openstack. Openstack is no longer a geek-driven homebrew project, like amazon with bells and whistles, which it used to be some time ago. Nowadays it is mature and solid Infrustructure as a service solution, with wide adoption across the market and well-established community of thousands devoted developers working over the world.
The core services of OpenStack are quite solid - and the progress is moving towards the platform solutions. There are a number of commercial products providing Platform-as-a-service solution which are integrated with of OpenStack - and this speeds up the progress even more.
What will be the next step in this climb?
Right. The applications: the cloud infrastructure is useless without the applications which run on top of it, solving real customers needs and taking the most from the Cloud underneath.
So, actually, the next step of the climb is up to developers. Up to you, folks.
Remember this guy and his "Four words"? Yeah, developers, developers, developers, developers - more and more of us are coming to the openstack community, more and more projects are announced every day.
Let's make a quick check: who of you have ever tried to develop something for openstack? Please, rise your hands…
So, there are quite a lot of developers, the number is increasing - and so we expect the tremendous amount of applications intended to run over the openstack to appear very soon.
Building a cloud-ready applications is a challenge of its own nature, but I am pretty sure that we’ll all make it: there is number of development-oriented tools, platforms and frameworks, specially intended to aid the developers in simplify their life.
But once the application is ready, another challenge appears: it has to find its user. There will be hundreds of apps, and thousands of users, and there is a hell of interconnected requirements: prerequisite components, operating systems, cloud resources, licenses, distribution policies..
That is why we need to have a single point where the application developers will meet cloud users, and where all their requirements will be satisfied. This will be a catalog, where all the different applications can be published in a unified manner - and then searched for by the end-user. Once found, the applications should have an easy way to be deployed in the cloud, and their maintenance should also remain centralised and easily accessible.
The usage statistics should be gathered all the time - and, of course, let’s not forget about the commercial benefits of application developers: the usage of their apps should be paid, and the catalog should be the centralised point of gathering this billing information.
That’s right, you’ve got the idea. Is is an AppStore. For OpenStack.
To publish the app in this catalog, the developer should describe it, define all its configuration parameters and dependencies - and set up the workflow which will not only deploy the application in the Cloud, but will also define different aspects of its in-cloud behaviour: scaling up and down, health monitoring, usage reporting etc. Then, this description - altogether with the application itself - is submitted into the catalog and is indexed there.
Then, the application becomes accessible for the end-users: they may locate it in the catalog, inspect its software and hardware requirements, check the prices and usage agreements - and so on. Then - as in any mobile AppStore - user should simply press a button - and get the app in his cloud environment.
Well, “simply pressing a button” belongs to a perfect world, in reality some properties and parameters will still have to be entered - but these should remain as easy and user friendly and possible.
And there is one more role: cloud administrator. This guy acts as a moderator between the developers and users: reviews and approves the published applications, manages access rights and deployment policies, approves the deployment requests from users, if required. There maybe plenty of various use-cases. Private Clouds may have their IT team here, with their specific use-cases, public cloud hosting providers have different stories and scenarios - so, it should be customisable and flexible enough.
So, that was an overall concept - and now, meet the Murano project: our implementation of this vision.
We started from a much simpler goal: we were building a tool which could catalog and deploy Services for building Windows Data Centers in the openstack clouds. The idea proved good, and now we are positioning Murano as a generic Application Catalog, which can host and deploy any applications, provide rich user experience for both cataloguing and operational goals.
Murano manipulates with so-called “Application packages” - a structured, annotated a signed archives, containing definitions of applications, their deployment and management workflows, all the resources needed to deploy them - and so on. The packages may - or may not - include the actual binary - depending on the way the actual deployment happens. The workflow - that’s what is mandatory there.
Murano users pick these packages from the catalog, and form environments out of them. Applications may depend on each other (like on the example diagram, where Java app, Tomcat Server and MySQL are considered to be Murano applications), and on some other software or hardware resources, which are not first-class applications on their own, but are nevertheless part of the environment. When the environment definition is ready, it may be deployed in the cluster - so all the applications and their dependencies are deployed.
This is an overview of Murano’s architecture: it communicates with the outer world via a stateless RESTfull API, which may be called by various client via python bindings. Murano comes with a horizon-based plugin for OpenStack dashboard, which provide a convenient openstack-looking wizard-like user interface - but it remains an optional component and may be substituted by different client tools, such as standalone UI and even command-line utility, depending on the needs.
The API interacts with two different storages: one stores the actual catalog - the Application Packages, and another one stores the environments, composes out of this packages by the actual user in the actual openstack clouds. Application definitions from the packages are used to assist to dynamically build the UI and validate the incoming input. Constructed environments are stored on a per-user basis and may be deployed independently from the construction.
The workflow engine is the core of Murano: it executes the workflows when the application has to be deployed in the cloud, its configuration has to be updated or some other actions have to be done with the applications. This actions include calling external OpenStack APIs, such as orchestrating resource allocation with Heat, networking configuration with Neutron or calls to specific platform-services such as Trove or Savanna. These actions cause a number of Virtual Machines to be allocated in the cloud - and then some other configuration actions may run on these machines. To do that, the Workflow Engine communicates with the guest agents, running on this virtual machines.
Now, let’s see this in a little action.
I will show how the murano application packages look like, upload one to the application catalog, and will use it to build a simple environment composed out of two applications. As Murano originated as Windows-deployment tool, this apps will be Windows Services. This is a good demo scenario, as windows deployments are usually quite complicated and uneasy to orchestrate.
So, here it is: the Murano project.
It’s been in the active development for about a year now. We’ve started from Windows-data-center-as-a-service, and evolved into a full-fledged OS-independent application catalog, with most of the needed features ready and integrated with the most recent official openstack release. We are hosted at stackforge and are community-driven openstack project, aiming to be officially incubated and eventually integrated into the main openstack trunk.
There are a lot of things to be done yet, and the development is in active progress. We are introducing new domain-specific language to define the applications and workflows: it is simple, but yet powerful enough, having the object-oriented capabilities to simplify the developer’s life. We are working on even more integration with Core openstack projects: we’ve started an initiative to turn Openstack Glance - which is currently an Image storage - into a generic artefact repository - and will use this repository to store murano application packages. We’ll improve statistics gathering to build the solid base for billing aggregation - and.. well.. we have lots of ideas.
What is much more important is the fact that you may have your ideas as well. You may have your use-case and scenario for the application catalog - or your customers may have one. And here you are: Murano is 100% opensource, which means we are open for any suggestions, ideas and proposals, we are waiting for potential contributors - so you are welcome to join. Developers, Developers, developers - remember that?