DiUS Computing Lca Rails Final


Published on

The presentation I did for LinuxConf.au around rails in the enterprise.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

DiUS Computing Lca Rails Final

  1. 1. Rails Deployment in the Enterprise: Transmitting a Little Experience Robert Postill
  2. 2. What Can He Say About This? Who is this bloke? The end of Java as we know it The Rails you need to know The use of some cool tools Summary Questions Page #
  3. 3. Who am I? Solaris SA who crossed over to development Spent time doing Java then Rails Lots of integration projects and then greenfields development Spent a lot of time working with infrastructure departments Page #
  4. 4. Windows is badly broken Page #
  5. 5. Why Linux? Performance, you will notice the difference (so long as you don't use the Ubuntu-supplied ruby!) Because you can easily get supporting tools (e.g. Apache, Postgres, git) Because some gems require C to be compiled (bless the gcc) Because of the community Page #
  6. 6. The end of Java: How we got here When we were young we thought things could be simple: <ul><ul><li>One language could be used for everything
  7. 7. Vendors could help
  8. 8. We could still be flexible </li></ul></ul>What went wrong? <ul><ul><li>The learning curve :(
  9. 9. How expensive is this?
  10. 10. This is so slowwww to develop </li></ul></ul>Page #
  11. 11. PHP – More harmful than bird flu
  12. 12. The end of Java: What's happening now? Fragmentation <ul><ul><li>Ruby and scripting languages
  13. 13. Groovy (JVM variants)
  14. 14. PHP
  15. 15. Haskell and functional languages </li></ul></ul>Polyglot solutions Web Services become a reality Page #
  16. 16. The end of Java: What did we learn? Partitioning our infrastructure Not everyone is our friend Databases are a facade for storage Blowing business logic across the platform is a recipe for disaster Turns out open source rocks :) Page #
  17. 17. Rant:Who are we employing? We need to find a question we can answer by saying “employ a small number of smart people” How do we get junior infrastructure guys to become senior guys? Why aren't there patterns for deploying applications? Why is infrastructure so driven by development? Page #
  18. 18. So sell me this rails stuff Web Development is quick – my guess is a 3x development speed improvement for a 3 month project Good patterns of development are enforced by being baked into the framework Ruby is a great object-oriented language with a lot of perl-ish goodness Jruby is an excellent gateway drug ;) REST is encouraged Page #
  19. 19. REST – I'm Excited! It's an architecture of development conceived by Roy Fielding – one of the founders of the Apache Software Foundation and the HTTP specification RESTful applications try to model themselves on the web, which means: <ul><ul><ul><li>Applications are modeled around resources
  20. 20. You can put caches at multiple levels </li></ul></ul></ul>Page #
  21. 21. The basics of Rails: Structure Every project is contained in a directory: <ul><li>tmp – holds temporary files
  22. 22. log holds logs
  23. 23. public – static files like images, CSS and like
  24. 24. script – commands for starting and stopping the application
  25. 25. config – holds database credentials and performance settings mostly
  26. 26. app – the source code lives here </li></ul>Page #
  27. 27. The basics of Rails: Deployment Three deployment options: <ul><li>Webrick – I wouldn't with yours :)
  28. 28. Mongrel – most analogous to Tomcat, a specialised daemon written in Ruby and C
  29. 29. mod_rails/passenger – the new kid on the block. Apache module with some cute tricks in it. </li></ul>My attitude is that Mongrel is the safe option for right now. However mod_rails is shaping up to be ace Page #
  30. 30. Pitfalls of Rails Speed of execution: <ul><li>Scaling rails is not going to work the Java way
  31. 31. Rails and Ruby are not the answer for large batch operations </li></ul>Rails apps leak memory It's the best AJAX integration that I know of: <ul><li>We haven't had The Great AJAX Security Disaster yet but we will
  32. 32. Clients of AJAX applications (I'm looking at you Firefox...) leak memory, lots of it. </li></ul>Page #
  33. 33. How slow is Ruby vs Perl? Page #
  34. 34. How slow is it? Here's Sun's Widefinder project results: Name Language Elapsed LoC wf10 C++ 00:04:41 537 WFII.java Java (Kolja) 00:13:26 126 (Report) + 2000 (WFII Framework) stats_irumiha.pl Perl 00:19:56 292 parallel_2.py Python 00:22:37 124 stats.rb Ruby 25:24:41 78 Page #
  35. 35. Pitfalls of Rails Speed of execution: <ul><li>Scaling rails is not going to work the Java way
  36. 36. Rails and Ruby are not the answer for large batch operations </li></ul>Rails apps leak memory It's the best AJAX integration that I know of: <ul><li>We haven't had The Great AJAX Security Disaster yet but we will
  37. 37. Clients of AJAX applications (I'm looking at you Firefox...) leak memory, lots of it. </li></ul>Page #
  38. 38. Scaling Rails Rails doesn't need a bigger box it needs another instance (possibly on another box) Rails apps don't share state Databases are slow (especially remote databases) Caching assets Action, page and fragment caching Memcached Indexing engines versus RDBMS Page #
  39. 39. Securing Rails Wrapping Rails in your onion: <ul><li>Front Rails with Apache or something else
  40. 40. Proxy requests (push for RESTful apps to help with this)
  41. 41. config/database.yml stores your db credentials so protect it (maybe move it out of source control?).
  42. 42. mod_rewrite can be dangerous
  43. 43. Never ever use in_place editor </li></ul>Page #
  44. 44. Are we ever going to talk deployment? Page #
  45. 45. Deployment Architecture Page #
  46. 46. Hang on a minute! Page #
  47. 47. Deployment Architecture Page #
  48. 48. Deployment Architecture Page #
  49. 49. Deployment Tips Deploy to a common location – I like /var/webapps Push towards Postgresql/MySQL they're the most tested drivers Rails apps that use more than 150MB of mem probably need killing Budget on roughly 100MB of memory per process The log directory can get full fast, so use logrotate with a truncate strategy Cache gems on a server, all you need is Apache! Page #
  50. 50. Deployment Tools A couple of really helpful deployment aids that come right out of the ruby and rails community: <ul><li>Capistrano – a tool for simultaneous execution of commands on an SSH server
  51. 51. Deprec and Sprinkle – tools that use Capistrano as their base.
  52. 52. Puppet – a configuration management tool, so cunning you could cast it in Blackadder </li></ul>Page #
  53. 53. Puppet, more than just fun... Page #
  54. 54. Deployment: Puppet You need a machine for the puppetmaster daemon Each client has a little daemon that talks to the server Puppet works with your OS package management so you use pbuilder or erm the rpm thingy... Puppet allows you to take control of large populations of machines Puppet has files called manifests Page #
  55. 55. Deployment: Puppet - Example class sudo { package { sudo: ensure => latest } file { &quot;/etc/sudoers&quot;: owner => root, group => root, mode => 440, source => &quot;puppet:///sudo/sudoers&quot;, require => Package[&quot;sudo&quot;], } } Page #
  56. 56. Deployment: Puppet - Review Upsides: <ul><li>Works in a heterogeneous environment
  57. 57. Check out the recipes... nice
  58. 58. Puppet makes provision for config of files and apps
  59. 59. Puppet works continuously </li></ul>Downsides: <ul><li>There's only one puppetmaster supported.
  60. 60. The recipe syntax is not as powerful as it could bez </li></ul>Page #
  61. 61. Deployment: Capistrano Capistrano is closely aligned to Rails, but its use is much broader than that Capistrano applies commands to sets of servers Capistrano also has recipes that it applies The syntax is Ruby-based You can call shell commands and inspect the results Page #
  62. 62. Deployment:Capistrano - Example task :search_libs, :hosts => &quot;www.capify.org&quot; do run &quot;ls -x1 /usr/lib | grep -i xml&quot; end task :as_root, :hosts => &quot;r.postill.com&quot; do sudo &quot;useradd robert&quot; end Page #
  63. 63. Deployment:Capistrano - Rails Capistrano was basically developed to deploy rails apps like basecamp and highrise so it knows rails capify will create config/deploy.rb and Capfile in your rails project cap deploy Capistrano will take a copy of what's in your source control and push it onto the server Page #
  64. 64. Deployment: Capistrano - Review Upsides: <ul><li>Knows Rails intimately
  65. 65. Is sudo-aware </li></ul>Downsides: <ul><li>Is much more project focussed
  66. 66. The documentation is not so good
  67. 67. Can be difficult to debug </li></ul>Page #
  68. 68. Touchy Feely Ahoy! Page #
  69. 69. Deployment Attitude Stop being a victim of development: <ul><li>Set expectations for metrics like code coverage
  70. 70. Make a link between Continuous Integration tools (e.g. CC.rb or Hudson) and deployment. For example don't allow broken builds to be deployed
  71. 71. Try and make the deployment an output of the build process. </li></ul>Page #
  72. 72. Deployment:Development Interface Get into the habit of being part of the project ceremony. Particularly in XP teams be a part of: <ul><li>Iteration open and close
  73. 73. Retrospectives
  74. 74. Showcases
  75. 75. Stand-ups (for practitioners) </li></ul>Put resources into the development team, in particular: <ul><li>Get a System Admin and DBA in early and don't let them leave
  76. 76. Build test environments with load balancers/proxies </li></ul>Page #
  77. 77. Where Next? We need to improve post deployment: <ul><li>Dynamic provisioning, can we scale like Amazon?
  78. 78. SNMP integration </li></ul>We should assume that the One Language To Rule Them All is a bad idea Ruby needs to stomp on those memory leaks (watch for Ruby 2/1.9/Rubinius) Page #
  79. 79. So what do I need to remember? Page #
  80. 80. Summary Ruby and Rails are ace :) Try and use a simple three-tier architecture Push the REST ideas, they benefit everyone Use mongrel to host the apps and monit to control the mongrels Use Capistrano or Puppet, to push the Rails apps to production, you'd be mad not to Integrate with the development teams Page #
  81. 81. Photo credits All photos courtesy of flickr's creative commons: nathansnostalgia, broken windows, page 4 - http://www.flickr.com/photos/nathansnostalgia/2098210283/ kaymoshusband, chicken sign , page 8- http://www.flickr.com/photos/thegaffneys/365119725/ big loggy missus, sleepy guy, page 21 - http://www.flickr.com/photos/natsgrant/501293610/ pt, puppet, page 28- http://www.flickr.com/photos/pmtorrone/9845799/ dunechaser, pirate attitude, page 36 - http://www.flickr.com/photos/dunechaser/253066484/ tyla75, new year resolutions, page 40 - http://www.flickr.com/photos/tyla/3159840057/ Page #
  82. 82. Questions? Page #
  83. 83. Links Language comparisons: http://wikis.sun.com/display/WideFinder/Results http://shootout.alioth.debian.org/u32/ruby.php REST: http://en.wikipedia.org/wiki/Representational_State_Transfer Puppet: http://reductivelabs.com/trac/puppet Capistrano: http://www.capify.org Mongrel: http://mongrel.rubyforge.org/ mod_rails/passenger: http://www.modrails.com Monit: http://mmonit.com/monit/ Page #
  84. 84. Contact I'll be here all week :) But just in case: [email_address] Page #