Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Continuous deployment of Rails apps on AWS OpsWorks
Similar a Continuous deployment of Rails apps on AWS OpsWorks (20)
Último
Último (20)
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
- 20. Questions?