Murano: Application Catalog for Openstack
•Descargar como PPT, PDF•
12 recomendaciones•6,107 vistas
A talk given on a SFBay Openstack meetup http://www.meetup.com/openstack/events/163020092/
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Murano: Application Catalog for Openstack
Similar a Murano: Application Catalog for Openstack (20)
Último
Último (20)
Murano: Application Catalog for Openstack
- 1. Murano — Application catalog for OpenStack Alexander Tivelkov Mirantis, Inc. © MIRANTIS 2014 1
- 2. Agenda • Why do we need an application catalog? • Use cases • Murano project overview • Application packages and their structure • Murano Architecture • Demo • Q&A © MIRANTIS 2014  2
- 3. What’s going on with OpenStack? • 8 major releases delivered • Core components quite stable and solid • Customer adoption increases • A number of free and commercial distributions • Commercial downstream projects emerge • 3rd party PaaS solutions integrated with OpenStack IaaS © MIRANTIS 2014 3
- 4. What is next? Applications! • Cloud-ready • Scalable • High-available • Ready to integrate with each other • Deployable on OpenStack • Think of SaaS on top of OpenStack © MIRANTIS 2014 4
- 5. Who is next? Developers! © MIRANTIS 2014 5
- 6. Distributing Cloud-Ready Applications • Hundreds and thousand of applications need to find their users • Different languages, frameworks and runtimes • Different prerequisites and environment requirements • Different licensing requirements • Both private and public clouds © MIRANTIS 2014 6
- 7. Application Catalog • A single point to publish all the different apps • Language, OS and platform agnostic • Browsable and categorised • Built-in deployment engine • Maintenance and management tools • Detailed statistical reports • Access control • Billing rules © MIRANTIS 2014 7
- 8. As an application developer, I… • Describe App’s properties and dependencies • Build the deployment workflow • Specify the external events and the workflows to handle them • Define the billing metrics and rules • Build and sign the application package • Submit the application package to catalog © MIRANTIS 2014 8
- 9. As a cloud user, I… • Browse the catalog for needed application • Compose an environment out of the picked Apps • Deploy the environment in my cloud infrastructure • Maintain the application while it runs • Pay for applications only when I use them © MIRANTIS 2014 9
- 10. As a cloud administrator, I… • Review the app packages submitted by developers • Import app packages from external repositories • Specify the access restrictions for packages • Specify the deployment policies for cloud users • Review the deployment requests from cloud users • Monitor the app usage statistics and billing reports © MIRANTIS 2014 10
- 11. Murano • Historically evolved from an all-purpose deployment tool to an Application Catalog • Is built on top of sophisticated workflow-based deployment engine • Catalogs “Application packages” which may be used to compose complex software environments and manage their lifecycle • Allows to define powerful yet easy-to-use wizard-like UI • Uses core OpenStack services under the hood © MIRANTIS 2014 11
- 12. Murano Application Package • Catalog headers • Application properties and dependencies • Workflow definitions • Other required resources: • Heat templates • Deployment and configuration scripts • Binaries … © MIRANTIS 2014 12
- 13. Murano environments • Composed of Applications and their Dependencies • Detect the types of dependencies automatically Network Network Linux node Linux node • Can be modified in runtime Linux node Linux node Linux node Linux node Tomcat Tomcat Server Server • Environment templates may be saved and reused © MIRANTIS 2014 My Java My Java application application MySQL MySQL 13
- 14. Architecture overview Package Package Repository Repository OpenStack Dashboard OpenStack Dashboard Standalone UI Standalone UI REST API REST API CLI CLI Environment Environment Storage Storage Murano Murano Engine Engine VM-side VM-side guest guest agent agent Core openstack Core openstack services services © MIRANTIS 2014 14
- 15. Demo • Uploading MS SQL Server application package • Deploying a windows-based environment consisting of Active Directory and clustered MS SQL Server © MIRANTIS 2014 15
- 16. Current project status • One year of active development • Generic deployment and workflow engine ready • Application Catalog features under development • Fully supports OpenStack Havana release • Supports both Linux and Windows • Bundles a handful of pre-built application packages • StackForge community project © MIRANTIS 2014 16
- 17. Roadmap • New easier-to-use Domain Specific Language • Storing Application Packages in Glance • Integration with Mistral Workflow Engine • Role-based access control • Advanced Usage statistics and billing • Murano-driven autoscaling events • Workflow development tools • Everything you invent and contribute! © MIRANTIS 2014 17
- 18. Questions? • Project homepage: launchpad.net/murano wiki.openstack.org/wiki/Murano • IRC: #murano at freenode • Mailing list: openstack-dev@lists.openstack.org, add [Murano] in the subject field © MIRANTIS 2014 18
- 19. A common question: why not Puppet? Murano Puppet • User-oriented • DevOps-oriented • Higher-level • Lower-level • Dynamically builds and modifies environments for any user-defined configuration • Manifests are fixed for particular cloud configuration • Maximum flexibility • Customisable flexibility But Murano can run Puppet underneath! © MIRANTIS 2014 19
Notas del editor
- 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?
- Thanks for your attention!