Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Deploying Ruby/Rails Apps to AWS

Deploying Ruby/Rails Apps to AWS

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

Avatar for Mike Danko

Mike Danko

April 21, 2014
Tweet

More Decks by Mike Danko

Other Decks in Programming

Transcript

  1. 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
  2. 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
  3. 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.
  4. Regions, AZ’s and your App. • Think like Craigslist: Regional

    Subdomains. • If you see the need, abstract your authentication ASAP.
  5. 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?
  6. 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.
  7. 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
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.