Hosting Ruby Web Apps

960 views

Published on

The options for hosting ruby web application are plentiful, all with different advantages and disadvantages, options, limitations. How to start, how to grow, what are the pitfalls?

With this talk I’d first like to give a short overview of several cloud hosting alternatives such as plain VPS, AWS, EngineYard, Heroku, and provide some insights based on my experience with them – beyond just somehow getting it to run, but also how to handle continuous deployment, how to maintain and scale them.

While Rails already comes with many best practices build in, there are still plenty enough traps for you. We definitely had our fair share, and I’d like to share some of them for your entertainment and learning.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
960
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Hosting Ruby Web Apps

  1. 1. Hosting Ruby Web Apps Lessons learned from 8 years of
  2. 2. Overview • System architecture • Initial setup & deploy • Keep it running and moving forward
  3. 3. Michael Reinsch michael@doorkeeper.jp @mreinsch
  4. 4. Next Weekend! startupweekend.jp/swtokyo-personal-cloud/
  5. 5. Michael Reinsch michael@doorkeeper.jp @mreinsch
  6. 6. Build a community through your events.
  7. 7. DB (psql) memcache nginx unicorn unicornRails App (unicorn) job worker MTA (postfix)
  8. 8. Contenders
  9. 9. Contenders
  10. 10. Contenders
  11. 11. Contenders
  12. 12. Contenders
  13. 13. Please Note • Not an exhaustive list of all hosting providers
 (it’s not even everyone we’ve been using) • Moving targets
  14. 14. Choosing Server Size www.flickr.com/photos/jonrb/7864016624
  15. 15. Choosing Server Size • good CPU performance • choose 2GB RAM or more
  16. 16. Choosing Server Size • 1 ECU/core is a bit frustrating • 2 ECU/core is OK • >2 ECU/core is better
  17. 17. Choosing Server Size • 3 different sizes • choose standard size if you don’t have specific requirements
  18. 18. Hardware Failures How can we make things robust? www.flickr.com/photos/doegox/4551458930
  19. 19. Hardware Failures “We’re trying to prevent failures, please make backups for worst case” ! • provides load balancer • fault tolerant setup example:
 2 web instances + 2 DB instances • need to configure DB replication and failover yourself
  20. 20. Hardware Failures “Failures will happen, build your infrastructure so they won’t impact you” • provides load balancer (ELB) • provides managed DB instances (RDS) • replication support (not for psql yet) • DB snapshots (can’t download though) • fault tolerant setup example: 
 2 web instances + multi-AZ RDS
  21. 21. Hardware Failures “Failures will happen, let us help you build an infrastructure so they won’t impact you” • HA proxy on web instances • one-click setup for DB (mysql/psql) • replication support • DB snapshots (downloadable) • fault tolerant setup example:
 2 web instances + 2 DB instances
  22. 22. Hardware Failures “You don’t need to worry about failures” ! ! • everything managed • fault tolerant setup example:
 2 dynos + premium DB (psql)
  23. 23. Initial Setup & Deploy www.flickr.com/photos/thedailyenglishshow/6013713229
  24. 24. Initial Setup & Deploy • manual setup feasible: • install OS, ruby (rvm), libs, DB • setup nginx
  25. 25. Initial Setup & Deploy • let’s choose Capistrano for deploying • Capistrano config goes into source repository • Initial deploy: cap deploy:setup
 cap deploy:cold
  26. 26. Initial Setup & Deploy • let’s choose OpsWorks • based on chef, provides predefined set of recipes • more high level than Cloud Formation, more flexible than Elastic Beanstalk
  27. 27. Initial Setup & Deploy • initial deploy: • create stack • define layers • create instances • create app • deploy
  28. 28. Initial Setup & Deploy • define base layer • assign it to all instances • use it for any common recipes like creating swap, NewRelic, ... Tip
  29. 29. Initial Setup & Deploy • you need to handle asset compilation • use deploy hook: Tip # deploy/before_migrate.rb ! rails_env = new_resource.environment["RAILS_ENV"] Chef::Log.info("Precompiling assets for RAILS_ENV=#{rails_env}...") ! execute "rake assets:precompile" do cwd release_path command "bundle exec rake assets:precompile" environment "RAILS_ENV" => rails_env end ! !
  30. 30. Initial Setup & Deploy • provides toolchain based on chef • initial deploy: • create an application • select environment layout • add plugins (NewRelic, ...) • deploy
  31. 31. Initial Setup & Deploy Heroku comes with its’ own toolchain: heroku create my-awesome-app
 heroku addons:add …
 git remote add heroku …
 git push heroku master
  32. 32. What you’ll probably also need • App configuration 
 (for secrets and endpoints) • Sending email • Job queue
  33. 33. App Configuration • no predefined way: DIY • put settings.yml into shared config dir • link it into app when deploying
  34. 34. App Configuration • uses environment variables heroku config:add MY_SECRET=topsecret
 heroku config • in your code: ENV[‘MY_SECRET’]
  35. 35. Sending Email • use an email sending service
 (SendGrid, AWS SNS) • EY and Heroku provide plugins for easy installation
  36. 36. Sending Email Yourself • reverse IP lookup • port 25 is restricted • make sure your IP isn’t blacklisted
  37. 37. Job Queue • DIY • define custom layer in OpsWorks, need to get 3rd party recipe
  38. 38. Job Queue • sample recipes are provided • worker instances
  39. 39. Job Queue • provides worker dynos • requires setup in Procfile
  40. 40. Background mailer • use database transaction to atomically create mailer job and related data • rollback if something goes wrong • reduces request response time • job can retry sending email Tip
  41. 41. Up and running :-)
  42. 42. Continuous Deployment www.flickr.com/photos/layos/3743880081
  43. 43. Continuous Deployment • keep deploys cheap • automate deploy • easy deployment trigger • good test coverage - use CI • use rolling / zero downtime deploy
  44. 44. Continuous Deployment • deploy command: git pull
 cap deploy • unicorn for rolling deploy
  45. 45. Continuous Deployment • unicorn is configured for rolling deploys • deploy command: aws --region=‘us-east-1’
 opsworks create-deployment
 --stack-id=‘<STACK_UUID>’
 --app-id=‘<APP_UUID>’
 --instance-ids=‘[“<INSTANCE_UUID>”]’
 --command='{"Name": "deploy"}
  46. 46. Continuous Deployment gem 'aws-sdk' gem 'parseconfig' ! PRODUCTION_APP_ID = "09afbde1-322b-4816-a1e9-xxxxxxxxxxxx" ! config = ParseConfig.new(File.expand_path("~/.aws/config")) AWS.config( :access_key_id => config['default']['aws_access_key_id'], :secret_access_key => config['default']['aws_secret_access_key']) ! @ops = AWS::OpsWorks.new.client @ops_app = @ops.describe_apps(app_ids: [PRODUCTION_APP_ID])[:apps].first @ops_stack = @ops.describe_stack_summary(stack_id: @ops_app[:stack_id])[:stack_summary] @ops_inst = @ops.describe_instances(stack_id: @ops_app[:stack_id])[:instances] @ops_inst_ids = @ops_instances.map do |instance| instance[:instance_id] if instance[:status] == 'online' end.compact ! puts "Deploying #{@ops_app[:name]} to #{@ops_stack[:name]}" ! deploy_options = { command: { name:' deploy' }, comment: "deploy from #{Socket.gethostname}", stack_id: @ops_app[:stack_id], app_id: @ops_app[:app_id], instance_ids: @ops_inst_ids } @ops.create_deployment deploy_options ! ! or some simple ruby script:
  47. 47. Continuous Deployment • deploy command: ey deploy • in config/ey.yml: maintenance_on_migrate: false
  48. 48. Continuous Deployment • deploy command: git pull
 git push heroku master • no-downtime deploys experimental: heroku labs:enable -a myapp preboot
  49. 49. Continuous Deployment • “fork” in code • on/off switch for features • slow rollout of new features Tip
  50. 50. Rolling Deploys with! Database Migrations www.flickr.com/photos/edwardshousemovers/6704586649
  51. 51. Rolling Deploys with Database Migrations orchestrated deployment flow: 1. copy code, keep old version 2. run migrations 3. switch to new code ➜ one-step deployments
  52. 52. Rolling Deploys with Database Migrations • asynchronous deployment flow • two-step deployment 1. deploy old code + DB migrations
 (one instance only) 2. deploy new code
 (all instances)
  53. 53. Rolling Deploys with Database Migrations • migrations are run via: heroku run rake db:migrate • two-step deployment 1. deploy old code + DB migrations 2. deploy new code
  54. 54. Down for! Maintenance www.flickr.com/photos/metrolibraryarchive/4128611963
  55. 55. Down for Maintenance • Maintenance page done right: • include contact and progress info
 (use 3rd party service like Twitter) • serve page with 503 error code • use asset host or inline all assets Tip
  56. 56. Down for Maintenance • add ‘capistrano-maintenance’ gem • configure nginx • then: cap maintenance:enable server { // nginx server config ! location @maintenance { rewrite ^(.*)$ /system/maintenance.html last; break; } if (-f $document_root/system/maintenance.html) { return 503; } ! error_page 503 @maintenance;
  57. 57. Down for Maintenance • Need custom recipe / script • Can use similar approach as with Capistrano • 503 won’t pass ELB health check! • Alternative: use Route53 to fail over to instance serving maintenance page
  58. 58. Down for Maintenance • Part of the platform: ey web disable heroku maintenance:on
  59. 59. Getting Support
  60. 60. Getting Support • provides ticket system for any platform related issues • forum for anything else
  61. 61. Getting Support • forums for everything • access to tickets only available if certain health checks fail
  62. 62. Getting Support • tickets for everything • provides even hosting related help on application level • “extension of your team”
  63. 63. Conclusion • there is no silver bullet • a lot depends on your app • be ready to get your hands dirty • your production environment is your app • balance ops / dev
  64. 64. Thank you! Contact: Michael Reinsch
 michael@doorkeeper.jp
 @mreinsch Questions? More awesome events: • ijaws.doorkeeper.jp • Startup Weekend Tokyo Personal Cloud

×