Download to read offline
![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
!
!](https://image.slidesharecdn.com/rubyhosting-140317005729-phpapp02/85/Hosting-Ruby-Web-Apps-30-320.jpg)
![App Configuration
• uses environment variables
heroku config:add MY_SECRET=topsecret
heroku config
• in your code:
ENV[‘MY_SECRET’]](https://image.slidesharecdn.com/rubyhosting-140317005729-phpapp02/85/Hosting-Ruby-Web-Apps-35-320.jpg)
![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"}](https://image.slidesharecdn.com/rubyhosting-140317005729-phpapp02/85/Hosting-Ruby-Web-Apps-46-320.jpg)
![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:](https://image.slidesharecdn.com/rubyhosting-140317005729-phpapp02/85/Hosting-Ruby-Web-Apps-47-320.jpg)
Uploaded byMichael Reinsch
Hosting Ruby Web Apps
The document discusses lessons learned from eight years of hosting Ruby web applications, covering system architecture, deployment strategies, and maintaining production environments. It emphasizes the importance of robust infrastructure to handle hardware failures, continuous deployment practices, and effective application configurations using tools like Capistrano and OpsWorks. The conclusion stresses that there is no one-size-fits-all solution, and success requires practical engagement and a balance between operations and development.
More Related Content
Hosting Ruby Web Apps
- 1. Hosting Ruby Web Apps Lessonslearned from 8 years of
- 2. Overview • System architecture •Initial setup & deploy • Keep it running and moving forward
- 3.
- 4.
- 5.
- 6. Build a communitythrough your events.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. Please Note • Notan exhaustive list of all hosting providers (it’s not even everyone we’ve been using) • Moving targets
- 15.
- 16. Choosing Server Size •good CPU performance • choose 2GB RAM or more
- 17. Choosing Server Size •1 ECU/core is a bit frustrating • 2 ECU/core is OK • >2 ECU/core is better
- 18. Choosing Server Size •3 different sizes • choose standard size if you don’t have specific requirements
- 19. Hardware Failures How canwe make things robust? www.flickr.com/photos/doegox/4551458930
- 20. Hardware Failures “We’re tryingto 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
- 21. Hardware Failures “Failures willhappen, 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
- 22. Hardware Failures “Failures willhappen, 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
- 23. Hardware Failures “You don’tneed to worry about failures” ! ! • everything managed • fault tolerant setup example: 2 dynos + premium DB (psql)
- 24. Initial Setup &Deploy www.flickr.com/photos/thedailyenglishshow/6013713229
- 25. Initial Setup &Deploy • manual setup feasible: • install OS, ruby (rvm), libs, DB • setup nginx
- 26. Initial Setup &Deploy • let’s choose Capistrano for deploying • Capistrano config goes into source repository • Initial deploy: cap deploy:setup cap deploy:cold
- 27. 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
- 28. Initial Setup &Deploy • initial deploy: • create stack • define layers • create instances • create app • deploy
- 29. Initial Setup &Deploy • define base layer • assign it to all instances • use it for any common recipes like creating swap, NewRelic, ... Tip
- 30. 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 ! !
- 31. Initial Setup &Deploy • provides toolchain based on chef • initial deploy: • create an application • select environment layout • add plugins (NewRelic, ...) • deploy
- 32. 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
- 33. What you’ll probablyalso need • App configuration (for secrets and endpoints) • Sending email • Job queue
- 34. App Configuration • nopredefined way: DIY • put settings.yml into shared config dir • link it into app when deploying
- 35. App Configuration • usesenvironment variables heroku config:add MY_SECRET=topsecret heroku config • in your code: ENV[‘MY_SECRET’]
- 36. Sending Email • usean email sending service (SendGrid, AWS SNS) • EY and Heroku provide plugins for easy installation
- 37. Sending Email Yourself •reverse IP lookup • port 25 is restricted • make sure your IP isn’t blacklisted
- 38. Job Queue • DIY •define custom layer in OpsWorks, need to get 3rd party recipe
- 39. Job Queue • samplerecipes are provided • worker instances
- 40. Job Queue • providesworker dynos • requires setup in Procfile
- 41. Background mailer • use databasetransaction to atomically create mailer job and related data • rollback if something goes wrong • reduces request response time • job can retry sending email Tip
- 42.
- 43.
- 44. Continuous Deployment • keepdeploys cheap • automate deploy • easy deployment trigger • good test coverage - use CI • use rolling / zero downtime deploy
- 45. Continuous Deployment • deploycommand: git pull cap deploy • unicorn for rolling deploy
- 46. Continuous Deployment • unicornis 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"}
- 47. 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:
- 48. Continuous Deployment • deploycommand: ey deploy • in config/ey.yml: maintenance_on_migrate: false
- 49. Continuous Deployment • deploycommand: git pull git push heroku master • no-downtime deploys experimental: heroku labs:enable -a myapp preboot
- 50. Continuous Deployment • “fork”in code • on/off switch for features • slow rollout of new features Tip
- 51. Rolling Deploys with! DatabaseMigrations www.flickr.com/photos/edwardshousemovers/6704586649
- 52. Rolling Deploys with DatabaseMigrations orchestrated deployment flow: 1. copy code, keep old version 2. run migrations 3. switch to new code ➜ one-step deployments
- 53. Rolling Deploys with DatabaseMigrations • asynchronous deployment flow • two-step deployment 1. deploy old code + DB migrations (one instance only) 2. deploy new code (all instances)
- 54. Rolling Deploys with DatabaseMigrations • migrations are run via: heroku run rake db:migrate • two-step deployment 1. deploy old code + DB migrations 2. deploy new code
- 55.
- 56. 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
- 57. 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;
- 58. 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
- 59. Down for Maintenance •Part of the platform: ey web disable heroku maintenance:on
- 60.
- 61. Getting Support • providesticket system for any platform related issues • forum for anything else
- 62. Getting Support • forumsfor everything • access to tickets only available if certain health checks fail
- 63. Getting Support • ticketsfor everything • provides even hosting related help on application level • “extension of your team”
- 64. Conclusion • there isno silver bullet • a lot depends on your app • be ready to get your hands dirty • your production environment is your app • balance ops / dev
- 65. Thank you! Contact: Michael Reinsch michael@doorkeeper.jp @mreinsch Questions? Moreawesome events: • ijaws.doorkeeper.jp • Startup Weekend Tokyo Personal Cloud