AWS Summit Stockholm 2014 – T5 – Deploy, manage and scale applications on AWS
•
1 gefällt mir•2,443 views
AWS offers a number of services that help you easily deploy and run applications in the cloud. Come to this session to learn how to choose among these options. Through interactive demonstrations, this session will show you how to get an application running using AWS OpsWorks and AWS Elastic Beanstalk application management services. You will also learn how to use AWS CloudFormation templates to document, version control, and share your application configuration. This session will cover topics like application updates, customization, and working with resources such as load balancers and databases. This session is recommended for people who understand AWS and want to know more about deployment options for their applications.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie AWS Summit Stockholm 2014 – T5 – Deploy, manage and scale applications on AWS
Ähnlich wie AWS Summit Stockholm 2014 – T5 – Deploy, manage and scale applications on AWS (20)
Mehr von Amazon Web Services
Mehr von Amazon Web Services (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
AWS Summit Stockholm 2014 – T5 – Deploy, manage and scale applications on AWS
- 1. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Deploy, Manage, and Scale Your Apps with OpsWorks and Elastic Beanstalk Guy Ernest, Solutions Architect
- 2. What you will learn in this session • How to choose among the AWS services that can help you run applications more easily • How to get an application running using AWS Elastic Beanstalk and AWS OpsWorks • How to use AWS CloudFormation templates to document, version control, and share your application configuration
- 3. 1. Make dough 2. Roll and cut the dough 3. Separate donuts from holes 4. Let the dough rise 5. Prepare the glaze 6. Frying time! 7. Let them dry 8. Apply glaze 9. Add sprinkles (optional)
- 4. It’s not just deployments… • How do I scale my environment? • What is i-dc4297f2 used for? • How do I know when my application is unhealthy? • Where do I get logs? • Who has SSH access?
- 5. You need to deliver resilient applications with less work Source: http://xkcd.com/844/
- 6. AWS Elastic Beanstalk AWS OpsWorks AWS CloudFormation Application Container Application Automation Templated Provisioning
- 7. Jane Doe, Elastic Beanstalk developer
- 8. Jane Doe, Elastic Beanstalk developer • Developer • Builds web apps, APIs, and handles some background processing workloads • Needs some flexibility to customize her app environments and get it fast to testing • Wants simple API to monitor, view logs, scale, and deploy her apps
- 9. The demonstration • A Massive Voting App using HTML, Java and Node.js • Uses Elastic Load Balancing and Amazon DynamoDB
- 27. Elastic Beanstalk Supports… Java PHP Python Ruby .NET Node.js
- 28. Deploy Your App for Test Alert Log Mon App AZ http://your-app.elasticbeanstalk.com
- 29. Deploy Your App for Scale Alert Log Mon App AZ ELB http://your-app.elasticbeanstalk.com
- 30. Deploy Your Background Processing App Alert Log Mon App AZ Amazon SQS queueProducers
- 31. Deploy With Tools You Know Alert Log Mon App AZ ELB http://your-app.elasticbeanstalk.com
- 32. John Doe, AWS OpsWorks Developer
- 33. John Doe, AWS OpsWorks Developer • Developer • Builds apps with broad architectural patterns and software; e.g., MongoDB and Solr • Needs a high degree of flexibility to customize app environments • Wants APIs to control all aspects of application operations including deployments and scaling
- 34. Benefits • Any architecture • Configuration as code • Automation to run at scale • Control any component
- 42. Recipes in action Recipe + Metadata = Command execute “mysql-connect” do command “/usr/bin/mysql -u#{node[:deploy][:myphpapp][:database][:username]} -p#{node[:deploy][:myphpapp][:database][:password]} #{node[:deploy][:myphpapp][:database][:database]} … “deploy”: { “myphpapp”: { “database”: { “username”: “root”, “password”: “abcxyz”, … “/usr/bin/mysql -uroot –pabcxyz myphpapp …
- 43. “White board you environment”
- 45. Deploy your Apps
- 47. AWS CloudFormation: Model Your App • Document, version control, and share your applications and infrastructure as a JSON document • Provision app and other AWS resources (Amazon VPC, DynamoDB, etc.) from a template • Repeatable, reliable deployments for test/dev/prod in any AWS region
- 48. Elastic Beanstalk or AWS OpsWorks Resource AppELB AZ your-app.elasticbeanstalk.com Alert Log Mon
- 49. Database Resources Users Table (DynamoDB) MySQL Primary (RDS) AppELB AZ your-app.elasticbeanstalk.com Alert Log Mon
- 50. Object Storage and Security Resources Users Table (DynamoDB) MySQL Primary (RDS) App Storage (S3) IAM Instance Profile AppELB AZ your-app.elasticbeanstalk.com Alert Log Mon
- 51. Deployed as an AWS CloudFormation Stack Users Table (Amazon DynamoDB) MySQL Primary (Amazon RDS) App Storage (Amazon S3) IAM Instance Profile AppELB AZ your-app.elasticbeanstalk.com Alert Log Mon
- 52. Modeled in a Template File Users Table (Amazon DynamoDB) MySQL Primary (Amazon RDS) App Storage (Amazon S3) IAM Instance Profile AppELB AZ your-app.elasticbeanstalk.com Alert Log Mon AWS CloudFormation Template
- 53. What we discussed • How to choose among the AWS services that can help you run applications more easily • How to get an application running using Elastic Beanstalk and AWS OpsWorks • How to use AWS CloudFormation templates to document, version control, and share your application configuration
- 54. Learn More Get started with Elastic Beanstalk http://amzn.to/1dh8QkU Follow us @aws_eb Get started with AWS OpsWorks http://amzn.to/1bSHOPN Follow us @AWSOpsWorks Get started with AWS CloudFormation http://amzn.to/1m11Z3K Follow us at @AWSCloudFormer
- 55. © 2014 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc. Deploy, Manage, and Scale Your Apps with OpsWorks and Elastic Beanstalk Guy Ernest, Solutions Architect Thanks!
Hinweis der Redaktion
- How many people hand craft your environments? everything from provisioning hardware to deploying code to servers. to creating database tables. Once upon a time this was the only way to get applications running, and it was actually fun, to SSH to the machine to YUM install packages, to scp my files. It is OK with one server or couple of servers. But even I needed to go back and check my notes or history log to remember what I need to do to make it right. But we need to make it more repeatable and reliable, namely to automate it.
- And it’s not just getting the application installed and deployed to your servers… How to I configure alarms for problems in my app. How not to leave your servers open for everybody to SSH into them, just because you need your developers to check the logs of the application.
- It’s nice when you have the time, but it’s hard to ensure repeatability, especially at scale. We want documented and tested workflows… the cloud lets you document everything … not just your code but your infrastructure & software config How do we get it?
- During this session we will discuss the following services: AWS Elastic Beanstalk is an easy-to-use service for deploying, managing and scaling web applications and web services developed with popular programming languages such as Java, .NET, PHP, Node.js, Python and Ruby. AWS OpsWorks is an integrated application management service that helps automate and operate any app architecture. You can start from templates for common technologies or build your own to perform any task that you can script. AWS CloudFormation simplifies provisioning and management for the full breadth of AWS resources. It integrates with OpsWorks and Elastic Beanstalk to simplify the provisioning of all the resources in your application – Amazon VPC, Amazon RDS, etc.
- The 3 types of applications are web facing, API and back ground processes Everybody heard or said in the past: “But it was working on my machine…”
- This is role to use instead of putting your access key and secret key in a source control. You can also use the interface to define parameters like API key or other secrets that you what beanstalk to push to all your servers
- And we also have the older versions and we can roll back to each one of them, We can also see the logs, get the monitoring
- Opsworks supports any architecture, from simple web apps to complex apps with multiple components and services. Joe needs flexibility to run a variety of software: load balancers and databases, and also caching servers, cron jobs, and workers. All configuration can be represented as CFN templates and Chef recipes/Bash scripts making instance configuration repeatable and reliable. Joe wants control over his application’s configuration to match his needs, processes, and tools. He uses different EC2 instance sizes to better align capacity with demand, configures RAID arrays, installs software packages... Automation – deployments, scaling, log management, customization in your configuration scripts make it easy to predictably run your application. Joe lives by automation. He couldn’t run at scale using manual steps so he scripts configuration, provisioning, monitoring, and deployments. For example, he auto scales his application using time and load to match his demand. Each new instance that comes online is built to spec automatically. Control anything – instance sizes, scaling thresholds, how you deploy. He wants to deploy in his own way, too; his CI process includes a 1-box deploy before expanding to his production fleet. Built-in solutions like EBS RAID, SSH. Joe likes a simple solution that handles common operational tasks so that he can avoid pitfalls and reduce the effort to operate applications in a reliable, secure, and scalable manner.
- You can also customize OpsWorks deployments. OpsWorks supports repositories such as git, subversion, and bundles on http servers and S3. You can deploy to one or more instances to support patterns such as “1 box” deployments. You can also run recipes on demand, for example a CloudWatch alarm could automatically upload logs to S3. You can assign only specific users to perform deployments.
- AWS OpsWorks enables you to automate management actions so that they are performed automatically and reliably. You can benefit from automatic failover, package management, Amazon EBS volume RAID setup, and automatic rule-based or time-based instance scaling. Common tasks automatically handled for you, and you can also extend and customize that automation. AWS OpsWorks supports continuous configuration through lifecycle events that automatically update your instances’ configuration to adapt to environment changes, such as auto scaling events. With AWS OpsWorks there is no need to log in to several machines and manually update your configuration. Whenever your environment changes, AWS OpsWorks updates your configuration. AWS OpsWorks creates events that correspond to lifecycle stages. These events can be used to trigger Chef recipes on each instance to perform specific configuration tasks. OpsWorks has built-in recipes to perform basic management for each event based on the type of layer. You can also create custom recipes to script any configuration change that your application needs for a specific lifecycle event. The following lifecycle events are supported: Setup is sent to the instance when it is instantiated or successfully booted. For example, the OpsWorks Rails application server layer uses the setup event to trigger a Chef recipe that installs dependencies like Apache, Ruby, Passenger, and Ruby on Rails. Configure notifies all instances whenever the state of the stack changes. For example, when a new instance is successfully added to an application server layer, the configure event triggers a Chef recipe that updates the OpsWorks Load Balancer layer configuration to reflect the added application server instance. Deploy is triggered whenever an application is deployed. For example, the OpsWorks Rails application server layer uses the deploy event to trigger a Chef recipe that executes the tasks needed to check out and download your application and tells Passenger to reload it. Undeploy is sent when you delete an application. For example, the undeploy event can trigger a custom Chef recipe that specifies any cleanup steps that need to be run, such as deleting database tables. Shutdown is sent to an instance 45 seconds before actually stopping the instance. For example, the shutdown event can trigger a custom Chef recipe that shuts down services.
- When you deploy your application, a deploy event is sent to the instances and all built-in and custom recipes are run.
- When you add another EC2 instance, in this case the DB server, that instance runs setup recipes and then all instances run configure recipes. This lets you automate tasks where all instance need to know, such as letting the database server know about the app servers that will connect with it.
- When you deploy your application, the event is sent by default to all instances. In the case of the database, you might want to create a new table per application.
- Following the pattern, new instances get the setup event and all instances get the configure event.
- You can also run specific recipes at any time. When we change user permissions, such as adding an SSH key, OpsWorks executes the built-in recipes on all instances in the stack.
- You can also run specific recipes at any time. When we change user permissions, such as adding an SSH key, OpsWorks executes the built-in recipes on all instances in the stack.
- We can use a recipe to pass a database connection string to our application. We could do it ourselves by hand, but we’d like to automate it and ensure repeatability. So we write a recipe. The recipe would be brittle if we hard coded information like the username and database name, so we define metadata and pass it into the recipes. Chef takes the metadata and plugs it into the recipe. We can see for example that deploy-myphpapp-database-username is defined as root. That becomes –uroot in the command below.
- AWS OpsWorks lets you define template configurations for your entire environment in a format that you can maintain and version just like your application source code. You can reproduce the software configuration on new instances and apply changes to all running instances, ensuring consistent configuration at any time. You can deploy your application in the configuration you choose on Amazon Linux and Ubuntu. AWS OpsWorks lets you model your application with layers. Layers define how to configure a set of resources that are managed together. For example, you might define a web layer for your application that consists of Amazon EC2 instances, Amazon EBS volumes including RAID configuration and mount points, and Elastic IP addresses. You can also define the software configuration for each layer, including installation scripts and initialization tasks. When an instance is added to a layer, AWS OpsWorks automatically applies the specified configuration. AWS OpsWorks provides pre-defined layers for common technologies such as Ruby, PHP, HAProxy, Memcached, and MySQL. AWS OpsWorks promotes conventions but is flexible enough to let you customize any aspect of your environment. You can extend or modify pre-defined layers, or create your own from scratch. Because AWS OpsWorks supports Chef recipes (see What is Chef and how does AWS OpsWorks use it for details), you can leverage hundreds of community-built configurations such as PostgreSQL, Nginx, and Solr. For example, you can create an application that consists of multiple Python apps installed on Django connected to a CouchDB database.