Your SlideShare is downloading. ×
0
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Mag rails 2011   web application deployment for small teams
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Mag rails 2011 web application deployment for small teams

893

Published on

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

No Downloads
Views
Total Views
893
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Understanding and designing web application deployment for small teams. Lee Hambley lee.hambley@gmail.com github.com/leehambley twitter.com/codebeakerSunday, October 16, 11
  • 2. WHY DO WE DEPLOY?Sunday, October 16, 11
  • 3. WHY DO WE DEPLOY? • Fundamentally, because we’ve done some work, and we want to share itSunday, October 16, 11
  • 4. WHY DO WE DEPLOY? • Fundamentally, because we’ve done some work, and we want to share it • firstly with stakeholders, second with usersSunday, October 16, 11
  • 5. WHY DO WE DEPLOY? • Fundamentally, because we’ve done some work, and we want to share it • firstly with stakeholders, second with users • because we’ve fixed bugs and need to make the improved code availableSunday, October 16, 11
  • 6. WHY DO WE DEPLOY? • Fundamentally, because we’ve done some work, and we want to share it • firstly with stakeholders, second with users • because we’ve fixed bugs and need to make the improved code available • because the business interest needs new featuresSunday, October 16, 11
  • 7. WHY DO WE DEPLOY? • Fundamentally, because we’ve done some work, and we want to share it • firstly with stakeholders, second with users • because we’ve fixed bugs and need to make the improved code available • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 8. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • firstly with stakeholders, second with users • because we’ve fixed bugs and need to make the improved code available • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 9. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we’ve fixed bugs and need to make the improved code available • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 10. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to make the improved code available • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 11. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to • because we prefer to be available to our customers make the improved code available • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 12. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to • because we prefer to be available to our customers make the improved code available • because we prefer to be accountable to the business people • because the business interest needs new features • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 13. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to • because we prefer to be available to our customers make the improved code available • because we prefer to be accountable to the business people • because the business interest needs new features • because we have things like migrations, seed tasks, background workers and all the rest • because we need to test something privately in a production-like environmentSunday, October 16, 11
  • 14. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to • because we prefer to be available to our customers make the improved code available • because we prefer to be accountable to the business people • because the business interest needs new features • because we have things like migrations, seed tasks, background workers and all the rest • because we need to test something privately in a production-like • because there’s usually more than one machine environmentSunday, October 16, 11
  • 15. WHY DO WE DEPLOY? • Fundamentally, because we’ve done • because we’re professionals some work, and we want to share it • because interpreters like to load files into memory for performance (& other good reasons) • firstly with stakeholders, second with users • because we like to think about software in “versions” • because we’ve fixed bugs and need to • because we prefer to be available to our customers make the improved code available • because we prefer to be accountable to the business people • because the business interest needs new features • because we have things like migrations, seed tasks, background workers and all the rest • because we need to test something privately in a production-like • because there’s usually more than one machine environment • because very often there’s more than one moving piece has changed. (code & database, code & configuration, etc)Sunday, October 16, 11
  • 16. WHAT SHOULD WE DEPLOY? • How do we decide if a project really needs deployment? • How do we decide what to deploy? • Where does infrastructure end, and the application begin? • How can the what change depending on the application? • What don’t we deploy? • Uploaded assets, the database, the system packages, the Ruby Gems, your own log files.Sunday, October 16, 11
  • 17. INFRASTRUCTURE VS. APPLICATION operating system rubygems.org SSL Certificates github.com SSH keys logrotate configuration nginx virtual hosts configuration scheduled jobs application code log files cache configuration database configuration Infrastructure ApplicationSunday, October 16, 11
  • 18. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration • User comments • Requests • RSS feed • Notifications • Daily posts • Non-technical writing teamSunday, October 16, 11
  • 19. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration PostgreSQL • User comments • Requests • RSS feed • Notifications Memcache • Daily posts • Non-technical writing teamSunday, October 16, 11
  • 20. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration PostgreSQL • User comments • Requests • RSS feed • Notifications Memcache • Daily posts • Non-technical writing teamSunday, October 16, 11
  • 21. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration PostgreSQL • User comments • Requests • RSS feed • Notifications Memcache • Daily posts • Non-technical writing team MRI v1.8.7Sunday, October 16, 11
  • 22. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration PostgreSQL • User comments • Requests • RSS feed • Notifications Memcache • Daily posts • Non-technical writing team MRI v1.8.7 UnicornSunday, October 16, 11
  • 23. BENCHMARK gadget-showdown.co.uk Comparing the latest gadgets in ultimate- fighting style reviews, ending with a “Will it blend?” teardown. Request your own review of any two devices, and we’ll get right on it! • User registration PostgreSQL • User comments • Requests • RSS feed • Notifications Memcache • Daily posts • Non-technical writing team MRI v1.8.7 UnicornSunday, October 16, 11
  • 24. WHO? Our hypothetical, inexperienced team. Unlike us, they are not misunderstood masters of the forbidden and subtle arts. They’re not Jedi top-gun warlocks, like we are either, they’re just regular job people, and they’re never going to win a Nobel prize for their deployment efforts, and further more, they probably don’t even care.Sunday, October 16, 11
  • 25. WHO? Our hypothetical, inexperienced team. Unlike us, they are not misunderstood masters of the forbidden and subtle arts. They’re not Jedi top-gun warlocks, like we are either, they’re just regular job people, and they’re never going to win a Nobel prize for their deployment efforts, and further more, they probably don’t even care.Sunday, October 16, 11
  • 26. WHO? Our hypothetical, inexperienced team. Unlike us, they are not misunderstood masters of the forbidden and subtle arts. They’re not Jedi top-gun warlocks, like we are either, they’re just regular job people, and they’re never going to win a Nobel prize for their deployment efforts, and further more, they probably don’t even care. • Three person development team • No dedicated “ops” • No deployment experience • No Unix experienceSunday, October 16, 11
  • 27. WHO? Our hypothetical, inexperienced team. Unlike us, they are not misunderstood masters of the forbidden and subtle arts. They’re not Jedi top-gun warlocks, like we are either, they’re just regular job people, and they’re never going to win a Nobel prize for their deployment efforts, and further more, they probably don’t even care. • Three person development team • No dedicated “ops” • No deployment experience • No Unix experience • They want fast, reliable deployments • They don’t want phone calls at 3am because the servers are choking • They don’t want to have to learn about unix to do their job • They want it to be impossible to break something accidentally • They don’t want to have to deal with passwords • They expect things to “Just Work” because they’re hipster macbook using nancy boys.Sunday, October 16, 11
  • 28. WHERE DO WE DEPLOY? ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 29. WHERE DO WE DEPLOY? • Almost certainly to VPS ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 30. WHERE DO WE DEPLOY? • Almost certainly to VPS • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 31. WHERE DO WE DEPLOY? • Almost certainly to VPS • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 32. WHERE DO WE DEPLOY? • Almost certainly to VPS • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) • Probably to a VPS provider in the USA ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 33. WHERE DO WE DEPLOY? • Almost certainly to VPS • Probablyto a 32 bit operating system • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) • Probably to a VPS provider in the USA ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 34. WHERE DO WE DEPLOY? • Almost certainly to VPS • Probablyto a 32 bit operating system • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Probably to more than one machine • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) • Probably to a VPS provider in the USA ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 35. WHERE DO WE DEPLOY? • Almost certainly to VPS • Probablyto a 32 bit operating system • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Probably to more than one machine • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) • Probably using something • Probably from AWS, because it’s hip to a VPS provider in the USA ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 36. WHERE DO WE DEPLOY? • Almost certainly to VPS • Probablyto a 32 bit operating system • Almost certainly, not to EC2 (that is, at least not in a way that makes the most of the elastic infrastructure) • Probably to more than one machine • Almost certainly to Ubuntu ✝ (because it has a convenient package manager) • Probably using something • Probably from AWS, because it’s hip to a VPS provider in the USA • Probably not using a CDN ✝ That’s not a condonation, just an observationSunday, October 16, 11
  • 37. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy Secure Accessible Transactional Accountable Parallell HookableSunday, October 16, 11
  • 38. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy Secure Accessible Transactional Accountable Parallel HookableSunday, October 16, 11
  • 39. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •Fast starting •Fail fast Secure •Using a fast protocol (SSH, with keys) •Not wasting bandwidth or capacity Accessible •Not relying on passwords Transactional Accountable Parallel HookableSunday, October 16, 11
  • 40. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •Using a secure protocol •Using a secure, trustworthy source Secure •Secure from workstation to server •Secure deployment result by design Accessible •No shared sign-ons Transactional •Robust Accountable •Resilient Parallel •No .rc~ files HookableSunday, October 16, 11
  • 41. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •Any member of the dev’ team can deploy •They can do it without using root (or other) passwords Secure •Secure from workstation to server •Secure deployment result by design Accessible Transactional Accountable Parallel HookableSunday, October 16, 11
  • 42. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •When a deploy fails on one machine, we fail it across the board •We know when a deploy starts, is in progress, and ends Secure •We can inform our customers that there’s a deploy in progress, without falling back to a maintenance page. Accessible •We can recover from errors. Transactional Accountable Parallel HookableSunday, October 16, 11
  • 43. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •We know who deployed what, and when •We know exactly what happened during the deployment Secure •We know which version of the code is in production Accessible •We know how many servers are online Transactional Accountable Parallel HookableSunday, October 16, 11
  • 44. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •We need to operate on our machines in parallel •Except when we don’t Secure •Sequential parallel deployment Accessible Transactional Accountable Parallel HookableSunday, October 16, 11
  • 45. A SHORTLIST OF REQUIREMENTS FOR A SANE DEPLOYMENT Speedy •We need to know how it worked out •We often need to share that information Secure •with business people •with automated systems (issue tracker, status board, monitoring) Accessible Transactional Accountable Parallel HookableSunday, October 16, 11
  • 46. THAT’S A LONG LISTSunday, October 16, 11
  • 47. AND NOBODY DOES EVERYTHINGSunday, October 16, 11
  • 48. SO WHERE DO WE BEGIN?Sunday, October 16, 11
  • 49. $ CAP PRODUCTION DEPLOYSunday, October 16, 11
  • 50. # > touch /tmp/some-file $ > touch /tmp/some-fileSunday, October 16, 11
  • 51. $ > su someotheruser $ > su - someotheruserSunday, October 16, 11
  • 52. The Dreyfus ModelSunday, October 16, 11
  • 53. UNIX 101Sunday, October 16, 11
  • 54. USERS AND GROUPSSunday, October 16, 11
  • 55. $ CAP PRODUCTION PERMISSIONS:FIXSunday, October 16, 11
  • 56. $ CAP PRODUCTION PERMISSIONS:FIX desc “fix permissions” task :fix, :roles => [:web, :app] do run “chown nobody:apache /var/www/otb/“ run “chmod -R 666 #{current_release}” run “chmod -R 777 #{current_release}/ bin/” endSunday, October 16, 11
  • 57. Sunday, October 16, 11
  • 58. $ whoamiSunday, October 16, 11
  • 59. $ whoami codebeakerSunday, October 16, 11
  • 60. $ whoami codebeaker $ groupsSunday, October 16, 11
  • 61. $ whoami codebeaker $ groups codebeaker staff deploy sudoSunday, October 16, 11
  • 62. $ whoami codebeaker $ groups codebeaker staff deploy sudo $ echo $PATHSunday, October 16, 11
  • 63. $ whoami codebeaker $ groups codebeaker staff deploy sudo $ echo $PATH /usr/bin:/bin:/usr/sbinSunday, October 16, 11
  • 64. Sunday, October 16, 11
  • 65. $ idSunday, October 16, 11
  • 66. $ id uid=501(codebeaker) gid=20(staff) groups=20(staff)12(everyone), 33(_appstore),80(admin), 204(_developer)Sunday, October 16, 11
  • 67. Sunday, October 16, 11
  • 68. $ idSunday, October 16, 11
  • 69. $ id uid=1000(codebeaker) gid=1000(codebeaker) groups=60(staff)90(deploy),50(sudo)Sunday, October 16, 11
  • 70. $ id uid=1000(codebeaker) gid=1000(codebeaker) groups=60(staff)90(deploy),50(sudo) $ touch exampleSunday, October 16, 11
  • 71. $ id uid=1000(codebeaker) gid=1000(codebeaker) groups=60(staff)90(deploy),50(sudo) $ touch example $ newgrp -l deploySunday, October 16, 11
  • 72. I/OSunday, October 16, 11
  • 73. PROCESSESSunday, October 16, 11
  • 74. PERMISSIONSSunday, October 16, 11
  • 75. 37SIGNALSSunday, October 16, 11
  • 76. SHELLS, LOGIN AND NON-LOGINSunday, October 16, 11
  • 77. ENVIRONMENTAL VARIABLESSunday, October 16, 11
  • 78. SSHSunday, October 16, 11
  • 79. SOURCES OF TRUTHSunday, October 16, 11
  • 80. DISTRIBUTION OF RESOURCESSunday, October 16, 11
  • 81. HOW? There isn’t any software on the planet for doing this correctly.Sunday, October 16, 11
  • 82. HELP ME WRITE IT…Sunday, October 16, 11
  • 83. I’M @CODEBEAKER Thanks for your time and attention, any questions?Sunday, October 16, 11

×