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.
20. 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
21. 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
22. 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
23. Hardware Failures
“You don’t need to worry about failures”
!
!
• everything managed
• fault tolerant setup example:
2 dynos + premium DB (psql)
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
41. 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
44. Continuous Deployment
• keep deploys cheap
• automate deploy
• easy deployment trigger
• good test coverage - use CI
• use rolling / zero downtime deploy
52. 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
53. 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)
54. 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
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
62. Getting Support
• forums for everything
• access to tickets only available if
certain health checks fail
63. Getting Support
• tickets for everything
• provides even hosting related help on
application level
• “extension of your team”
64. 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