Deploying Ruby/Rails Apps to AWS

It's complicated. Let's make it simple.

Transcript

1. MITT DARKO BRUTAL ENGINEERING Deploying to AWS It’s what business people crave
2. MITT DARKO BRUTAL ENGINEERING What the Heck is it? Really.
3. It’s the systematic abuse of JSON to manipulate resources.
4. Let’s Start Simply.
5. Computers • Almost everything is an EC2 instance • Instances come in many shapes and sizes • They can be ephemeral (instance store) or permanent (elastic block store) • They can be paravirtual (PV) or hardware assisted virtualization (HVM) instances • We will pick our types later
6. Concept: Regions • AWS Regions are isolated from each other and are geographically dispersed. • Since there’s isolation, you have to duplicate infrastructure in different regions if you operate in several regions. • Regions has_many: :availability_zones
7. Concept: Availability Zones • Think of them like data centers with low latency links between each other. Because that’s what they are. • Also think about them like one big data center. Because that’s what the low latency links make it. • Example: You can migrate instances between availability zones.
8. Regions, AZ’s and your App. • Think like Craigslist: Regional Subdomains. • If you see the need, abstract your authentication ASAP.
9. Services • Still, mostly EC2 instances • Again, many shapes and sizes • Services of interest…
10. Route-53: DNS • Latency-based Routing: Route customers to the closest Region • Failover: When everything 500’s, route users somewhere else. • ELB integration. What’s an ELB?
11. ELB: Elastic Load Balancer • Probably the most important concept. • They’re not real. They’re rules on routers that forward traffic to ports. • The rules work within regions, so distribute your instances across many AZ’s. • They include service checks. If your predefined check for say “/login” isn’t working, that node won’t be added to the ELB. Use Route 53 failover for when everything is broken.
12. RDS • Again, EC2 instances. • Again, many shapes and sizes • MySQL, PostgreSQL, Oracle * Edition, MS SQL Server * Edition • For Ruby people, MySQL is the best supported option. Sorry. • Can be setup standalone or Multi-AZ. • Will heal itself if nodes die, thanks Xen/EC2
13. ElastiCache • Again, EC2 instances. • Again, many shapes and sizes • Redis & Memcached. • Redis has a Multi-AZ Option (this is recent) • Will heal itself if nodes die, thanks again Xen/EC2
14. S3/CloudFront • Not EC2 instances. Sorta. • S3: Storage buckets with fun HTTP headers for objects. • CloudFront: Amazon’s Global CDN. Way cheaper than going straight to your bucket. Respects your bucket headers. • If you’re mega-scale, front your whole site through CloudFront and use ESI to handle non-public pages.
15. ESI?
16. Partials on Steroids
17. Automating your Infrastructure • Primary reason to use AWS • It also solves the mother’s day problem. • Use their tools, your own, a third party’s, or a combination of all of those.
18. The Hard Part: Picking Where to Start
19. AWS Tool #1: CloudFormation • It’s a template for your AWS resources. A bunch of JSON defining how everything interconnects and autoscales. • On its own, it is disgusting. It involves weird programming within JSON. I’d never seen John Andrews more angry than when he had to deal with this. • It’s the way to go, unfortunately. There is a way out however. More on that later.
20. ElasticBeanstalk • Completely terrible if you go with this on its own. • You through a wizard that lets you pick really outdated software to roll with and it autoscales your stuff based on load or other user defined events. Yippee! • Fun Fact: This is just easy mode CloudFormation as it just uses it to create templates for your Rails app.
21. OpsWorks • A pretty good option. Based on Chef Solo. • Stacks, layers, instances, apps, and deployments. • Time and/or load based auto scaling. • Metrics on everything. • Use your own Chef recipes • opsworks_custom_env is your friend.
22. OpsWorks, Continued • OpsWorks will put like instances (layers) behind ELB’s if you choose to do so. • Layers can have their own auto-scale rules. All of a sudden have a bigger need for elasticsearch? It’s handled. • Use AWS’s predefined Chef recipes for layers (HAProxy, Rails, etc) or roll your own. You can also add your own recipes to the pre-defined layers. • Con: Building servers and deploying is slow. • Best option for AWS tool only deploys: Use CloudFormation to define your OpsWorks template. Build Staging, QA, etc environments off one template.
23. Third Party Option #1: Asgard • It’s a Grails app from Netflix. • You build an image, it handles launching the instances based off that image and switching your live app to the new build. Rollback is easy. • PROTIP: If you go this route, have your CI build images with Packer upon successful master builds.
24. Third Party Option #2: The First Party • Amazon has a gem for its services. • Use it to interface with any/all AWS services. • It’s not really “ruby”, but it gets the job done.
25. Third Party Option #3: Cloud Management Tools • Scalr, RightScale, Canonical Juju. • Pro: Abstraction of all the concepts in this presentation to work on any cloud provider. • Con: Yet something else to learn.
26. Questions?