Deployment Automation on OpenStack with TOSCA and Cloudify
•Download as PPTX, PDF•
18 likes•17,144 views
TOSCA (Topology and Orchestration Specification for Cloud Applications) is an emerging standard for modeling complete application stacks and automating their deployment and management. It’s been discussed in the context of OpenStack for quite some time, mostly around Heat. In this session we’ll discuss what TOSCA is all about, why it makes sense in the context of OpenStack, and how we can take it farther up the stack to handle complete applications, both during and after deployment, on top of OpenStack.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Deployment Automation on OpenStack with TOSCA and Cloudify
Similar to Deployment Automation on OpenStack with TOSCA and Cloudify (20)
More from Cloudify Community
More from Cloudify Community (20)
Recently uploaded
Recently uploaded (20)
Deployment Automation on OpenStack with TOSCA and Cloudify
- 1. Deployment Automation on OpenStack with TOSCA and Cloudify Nati Shalom @natishalom Uri Cohen @uri1803
- 2. Provision What It Really Takes to Deploy and Manage Apps Scale Install Monitor Configure Deploy
- 3. Large Parts Are Mostly Manual Measure performance against expected SLA’s Set and tune Alerts thresholds Match Policy to Incident Real Time Analytics Send Metrics Correlate with Historical Events Collect and Analyze Logs Troubleshoot Execute Policy Feedback Setup Monitoring and Alerts Deploy and Configure Applications Setup Machine, Network, Sto rage Push updates
- 4. The Impact of Human Errors 80% of outages impacting mission-critical services will be caused by people and process issues 50% of those outages will be caused by change/configuration/release integration and hand-off issues
- 5. The Cost of Downtime Up by 60%
- 6. EFFECTIVENESS The Current Reality.. 83%BE HERE WANT TO 61% ARE HERE TIME
- 7. The Solution Challenges Solution: Automation & Orchestration • 80% • Remove Manual Intervention out of of outages impacting mission-critical services will be caused by people and process •83% are facing significant roadblock keeping them from moving to the next phase (Politics, Budget, Time, Stuff) the application deployment process • Reduce Complexity and Dynamically align to the business needs
- 8. Automating The Application Deployment Real Time Analytics Real Time Analytics Cloud Infrastructure Send Metrics Correlate with Historical Events Execute Policy Scale Feedback Failover Deploy Historical data Intelligent Orchestration
- 9. TOSCA – The Glue for Putting all This Together TOSCA
- 10. What is TOSCA? • Topology & Orchestration Specification of Cloud Application • By OASIS – Sponsored by IBM, CA, Rackspace, RedHat, Huawei and others
- 11. What is TOSCA? • Goal: cross cloud, cross tools orchestration of applications on the Cloud • Status: – Version 1 approved (XML ) – Version 2 (YAML!) in design
- 12. • Standard • Can Describe Why TOSCA? – Any Topology – Any Automation Process • Portable between Clouds and Tools
- 13. The TOSCA Building Blocks Application Topologies Workflows Policies
- 14. What do we see here?
- 15. Host App module What do we see here? Middleware connection
- 16. • An application topology • 3 layers What We’ve Seen – Infrastructure (Cloud or DC objects) – Platform or Middleware (App containers) – Application modules, schemas and configurations • Relationships between components: – What’s hosted on what or installed on what – What’s connected to what
- 17. What’s in a TOSCA Topology? • component in the topology are called Nodes • Each Node has a Type (e.g. Host, BD, Web server). – The Type is abstract and hence portable – The Type defines Properties and Interfaces • An Interface is a set of hooks (named Operations) • Nodes are connected to one another using Relationships
- 19. Types and Nodes Portable Blueprint Concrete Types Node in Topology Node Implementation Instance of Instance of Implements Abstract Type Concrete Type Uses defines Lifecycle Interface Lifecycle: create: start: stop: delete: Implements Concrete Plugin
- 20. Types and Nodes Portable Blueprint Concrete Types Frontend_host My_OpenStack_Host Instance of Instance of Implementing OpenStack Host Host Uses defines Lifecycle Interface Lifecycle: create: start: stop: delete: Implementing Nova Plugin Lifecycle: create: nova_provisioner.create start: nova_provisioner.start stop: nova_provisioner.stop delete: nova_provisioner.delete
- 21. Relationships Node in Topology Connnected_to Node in Topology defines Hosted_on Relationship Interface Node in Topology source_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink
- 22. Relationships Host Connnected_to Network defines Hosted_on Relationship Interface Tomcat source_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink target_interfaces: cloudify.interfaces.relationship_lifecycle: - preconfigure - postconfigure - establish - unlink
- 24. Properties Portable Blueprint Concrete Types Frontend_host My_OpenStack_Host Instance of Instance of Implementing OpenStack Host Host Memory size = 2GB Image_Id=1235 Memory Size Properties schema Property values Image Id Generic Properties Schema
- 25. Policies • TOSCA 1.0 didn’t elaborate much on policies • TOSCA 2.0 (draft) discusses specific DSL for specific policies such as SLA of a Node • Out take: – Policies are imperative – Policies are NOT in YAML and are tool dependent (we’re using Riemann.io)
- 26. • TOSCA 1.0 – Workflows (Plans) are in any WF language. – Strong preference for BPMN 2.0 Workflows • TOSCA 2.0 – No change • Cloudify 3.0 take – Workflows are also tool specific, currently we use Radial (Ruby based DSL) but seeking an alternative for future versions
- 27. • TOSCA Template (Blueprint in Cloudify) contains: Putting It All Together – Application Topology • Nodes – Interfaces – Properties – Artifacts (Plugins in Cloudify) • Relationships – Interfaces – Workflows – Policies
- 31. Invokes Reports Creates Architecture Cloudify Manager REST + File Server Proxy GUI Metrics VM Blueprint + Runtime Data Workflow Engine Policy Engine Task Manager Monitoring Data Agent Logs + Events App VM Remote Agents Application Stack Agent Agent Agent Agent Monitoring Agent
- 32. HOW IT FITS INTO THE OPENSTACK UNIVERSE
- 33. The AWS Stack
- 34. The OpenStack Equivalents OpenShift/ CloudFoundry **Solum** ? Heat Nova, Cinder, Neutron etc..
- 35. References • OASIS TOSCA https://www.oasis-open.org/committees/tosca/ • TOSCA Session from the HK Summit https://wiki.openstack.org/w/images/a/a1/TOSCA_in_Heat_-_20130415.pdf • Cloudify 3.0 (AKA Cosmo) on github https://github.com/cloudifysource/cosmo-manager https://github.com/cloudifysource/cosmo-cli
Editor's Notes
- Goals:Why Workflows are critical part of automation of applications on the cloudClarify the need for something like OpsWorksWhy do we think this OpsWorks is needed in addition to other projects
- A recent Gartner study projected that through 2015, “80 percent of outages impacting mission-critical services will be caused by people and process issues, and more than 50 percent of those outages will be caused by change, configuration, release integration, and handoff issues.[2].”(Ronni J. Colville and George Spafford, “Configuration Management for Virtual and Cloud Infrastructures”)
- According to the AppsDynamics blog “How much does downtime cost,” the downtime expenses increased by an average of 65 percent from 2010-2012, even though the number of downtime hours per organization decreased (Figure 1) [1]. One possible explanation for this trend is that larger portions of business are being done online, making the overall impact of downtime bigger on an organization’s bottom line. With the move to cloud and Software-as-a-Servcice-based (SaaS-based) delivery models where not only customer-facing applications are exposed to online service but entire IT infrastructures, the impact of downtime could easily shut down an entire organization.
- http://www.cloudcomputing-news.net/blog-hub/2013/sep/10/the-challenge-of-predicting-enterprise-cloud-computing-growth/83% of enterprises face significant roadblocks that hold them back from moving beyond cost reduction to faster time-to-market and better orchestration of their businesses. Respondents mentioned that politics, budget, time and staff are the main sources of roadblocks to getting more value out of their cloud computing investments. The majority of these roadblocks are not related to IT. They include lack of clarity regarding organization and budget (37%), resistance to change (16%) and lack of trust (visibility and reliability) (15%). The following graphic illustrates the enterprise cloud journey as defined in TheInfoPro Wave 5 Cloud Computing Study.