狠狠撸

狠狠撸Share a Scribd company logo

Continuous deployment of Rails apps on AWS OpsWorks

?Download as PPTX, PDF?
?
T
Toma? Zaman

This document discusses continuous deployment of Rails applications on AWS OpsWorks. It begins with introductions and then covers: - Using SCRUM methodology for development - Git workflow with feature branches and pull requests - Tools for monitoring gems (Gemnasium) and code quality (CodeClimate, Travis CI) - An overview of AWS OpsWorks including stacks, layers, apps, and using Chef for automation - How OpsWorks deployments work by pulling from GitHub and running deployment hooks - Other AWS services that can be used like RDS, ElastiCache, S3 - Logging to external services like Loggly - Approaches for running background jobs like Sidekiq -

1 of 20
Downloaded 11 times
Continuous deployment of Rails apps on AWS OpsWorks Slovenia Ruby User group meetup Monday, June 23rd, 2014
Text $ whoami Toma? Zaman, founder of Codeable, @TomazZaman, http://zaman.io Geek, father of four, skydiver
SCRUM FTW! Sprints (14 days) Dailys (15 min each day) User stories (1:1:1) Only way to do CI!
Git workflow Master -> Staging Master -> Feature Feature -> Staging Feature -> Master (pull request, once feature done) Master always deployable!
Gemnasium One simple task: Report outdated gems via email
CodeClimate Automated code review HipChat + Emails Foreman (Uncle Bob, cleancoders.com) SOLID + other principles recommendations on refactoring
Travis CI .travis.yml - Instructions how to build a testing instance, how to run tests, matrices,… HipChat webhook Email web hook Deploys to staging env. pings CodeClimate A bit expensive
Text AWS OpsWorks Makin’ it easy to deploy stuff
How it compares to Heroku A bit more work to get started more moving parts you’re responsible for similar pricing Much more control (with great power comes great responsibility, Peter) More complex CLI Same integration with other services Documentation is overly complex, lacking examples Having all services under the same roof can be good or bad Doesn’t enforce 12 factors, but not hard to follow them on your own Primary elements:
Text Stacks A primary entity in OpsWorks, holding all other like Layers, Apps
Text Layers Layer is a “box” for ordinary EC2 instances that perform the same role, such as host Rails apps.
Text Apps Represent an individual app which is also a repo on GitHub
Chef Your worst nightmare. But it’s awesome! Written in Ruby, it’s an “automation platform”
Deployments (how they work) A set of instructions to be ran on CLI or Webhook call All application instances pull application from GitHub Chef takes over to call deployment hooks (even custom ones) Unicorn forks without downtime If any step of the deployment goes wrong, the old app keeps being served (again, no downtime!) deploy/before_restart.rb & co.
Other AWS tools Amazon RDS ElastiCache Route 53 Virtual Cloud Elastic IPs Elastic Load Balancers (with health checking) S3
Text Logging Need to use external service such as Loggly, Papertrail, so logs need to go into Syslog (not 100% mandatory, but easier)
Async Many possibilities to solve this OpsWorks doesn’t have a dedicated Worker layer Possibility: Custom Chef recipe Solution: Rake tasks + deployment hook bundle exec rake sidekiq:start
Configuration Can be tricky, many possible approaches Hook into Stack JSON and create a YML file on deployment, via deployment hook (tutorial: http://zaman.io)
Recap merge into staging triggers Travis and Gemnasium Travis runs tests, reports green or red Travis reports to HipChat, CodeClimate Manually run deployment rake task which initiates deployment via CLI OpsWorks pulls latest master on servers in the layer that app is being deployed to If no errors, Unicorn forks itself and runs rake tasks that restart async (Sidekiq) workers Everything visible on Papertrail
Questions?

More Related Content

Continuous deployment of Rails apps on AWS OpsWorks

  • 1. Continuous deployment of Rails apps on AWS OpsWorks Slovenia Ruby User group meetup Monday, June 23rd, 2014
  • 2. Text $ whoami Toma? Zaman, founder of Codeable, @TomazZaman, http://zaman.io Geek, father of four, skydiver
  • 3. SCRUM FTW! Sprints (14 days) Dailys (15 min each day) User stories (1:1:1) Only way to do CI!
  • 4. Git workflow Master -> Staging Master -> Feature Feature -> Staging Feature -> Master (pull request, once feature done) Master always deployable!
  • 5. Gemnasium One simple task: Report outdated gems via email
  • 6. CodeClimate Automated code review HipChat + Emails Foreman (Uncle Bob, cleancoders.com) SOLID + other principles recommendations on refactoring
  • 7. Travis CI .travis.yml - Instructions how to build a testing instance, how to run tests, matrices,… HipChat webhook Email web hook Deploys to staging env. pings CodeClimate A bit expensive
  • 8. Text AWS OpsWorks Makin’ it easy to deploy stuff
  • 9. How it compares to Heroku A bit more work to get started more moving parts you’re responsible for similar pricing Much more control (with great power comes great responsibility, Peter) More complex CLI Same integration with other services Documentation is overly complex, lacking examples Having all services under the same roof can be good or bad Doesn’t enforce 12 factors, but not hard to follow them on your own Primary elements:
  • 10. Text Stacks A primary entity in OpsWorks, holding all other like Layers, Apps
  • 11. Text Layers Layer is a “box” for ordinary EC2 instances that perform the same role, such as host Rails apps.
  • 12. Text Apps Represent an individual app which is also a repo on GitHub
  • 13. Chef Your worst nightmare. But it’s awesome! Written in Ruby, it’s an “automation platform”
  • 14. Deployments (how they work) A set of instructions to be ran on CLI or Webhook call All application instances pull application from GitHub Chef takes over to call deployment hooks (even custom ones) Unicorn forks without downtime If any step of the deployment goes wrong, the old app keeps being served (again, no downtime!) deploy/before_restart.rb & co.
  • 15. Other AWS tools Amazon RDS ElastiCache Route 53 Virtual Cloud Elastic IPs Elastic Load Balancers (with health checking) S3
  • 16. Text Logging Need to use external service such as Loggly, Papertrail, so logs need to go into Syslog (not 100% mandatory, but easier)
  • 17. Async Many possibilities to solve this OpsWorks doesn’t have a dedicated Worker layer Possibility: Custom Chef recipe Solution: Rake tasks + deployment hook bundle exec rake sidekiq:start
  • 18. Configuration Can be tricky, many possible approaches Hook into Stack JSON and create a YML file on deployment, via deployment hook (tutorial: http://zaman.io)
  • 19. Recap merge into staging triggers Travis and Gemnasium Travis runs tests, reports green or red Travis reports to HipChat, CodeClimate Manually run deployment rake task which initiates deployment via CLI OpsWorks pulls latest master on servers in the layer that app is being deployed to If no errors, Unicorn forks itself and runs rake tasks that restart async (Sidekiq) workers Everything visible on Papertrail
AboutCopyright
? 2025 狠狠撸