advanced topics - session 2 - introducing aws opsworks
Post on 08-May-2015
2.145 Views
Preview:
DESCRIPTION
TRANSCRIPT
Thomas Metschke
Introducing AWS OpsWorks
Technical Program Manager
Once upon a time…
Making Donuts
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)
Source: http://www.mixph.com/2008/10/how-to-make-donuts-food-business.html
Recipes + Automation
Eric Joyner ericjoyner.com
Introducing AWS OpsWorks
• Integrated application management solution for ops-
minded developers and IT admins
• Model, control and automate applications of nearly any
scale and complexity
• AWS Management Console, SDKs, or CLI
• No additional cost
Why Use AWS OpsWorks?
SIMPLE
Easy to use, quick to get started and productive
PRODUCTIVE
Reduces errors with conventions and scripted configuration
FLEXIBLE
Simplifies deployments of any scale and complexity
POWERFUL
Reduces cost and time with automation
SECURE
Enables control with fine grained permissions
Improve productivity
• Scalable infrastructure
• Flexible architecture
• Deploy often
• Staging environments
AWS OpsWorks gives us the tools we need to automate operations. We can scale Monster World, one of the largest Facebook games, to millions of users without ever needing more than two backend developers.
Jesper Richter-Reichhelm head of engineering
Rik Heywood
CTO at WorkFu
Basic Layers
• HAProxy
– Minor config changes as our site uses https for everything
• PHP App Server
– Customized Apache config and PHP.ini using template overrides
• MySQL
– We also install scripts to backup the database via custom recipes.
Additional layers that share App instances
• Memcached Layer
– Allows us to deploy memcached onto any instance
– We auto install it on all PHP instances to use spare memory
• Queue Worker Layer
– Processes messages in our background task queue.
– Again, we install one worker worker on all PHP instances.
– Helps to scale queue throughput as traffic increases
– We can still deploy dedicated queue worker instances if we need to
Layers sharing database instance
• RabbitMQ Layer
– We queue up a lot of background tasks, such as querying the Twitter API, rebuilding
the search database, sending out notifications to users etc.
• Sphinx Layer
– A full text search engine.
• Both services place very little load on the instance.
– If load on either of these, or MySQL, gets too high, we can easily migrate them to
dedicated instances.
Other features we depend on…
• Simple one click deployment
– Could be automated on push via API, but we prefer manual control of this.
• A realistic staging / testing environment
– Cloned our stack to create an identical duplicate of it
– Same cluster and config on Production and Staging
– We can leave Staging switched off most of the time, saving cash.
• No long complicated out of date documents explaining how to set up server
instances - it's all automated and in our git repository.
AWS Application Management Services
Elastic Beanstalk OpsWorks CloudFormation EC2
Convenience Control
Higher-level Services Do it yourself
The heart of AWS OpsWorks
14
Agent on each EC2 instance
OpsWorks talks with
The heart of AWS OpsWorks
15
understands a set of commands that are triggered by OpsWorks. The agent then runs a Chef solo run.
Agent on each EC2 instance
Instance lifecycle commands
Enough talking
DEMO TIME
Improve reliability
Git
Code
Jenkins
Build Test
OpsWorks
Provision Deploy Monitor
What’s next for AWS OpsWorks?
• Deeper integration with AWS resources (e.g., ELB)
• More built-in layers
• Advanced VPC integration (beyond today’s support for the
default VPC)
• And more!
• Please give us your feedback in the OpsWorks forums.
Thank You!
For more information, please visit us at
https://aws.amazon.com/opsworks
Thomas Metschke
@tmetschke
top related